|
Message-ID: <alpine.DEB.2.20.1709211024120.14427@nuc-kabylake> Date: Thu, 21 Sep 2017 10:27:13 -0500 (CDT) From: Christopher Lameter <cl@...ux.com> To: Kees Cook <keescook@...omium.org> cc: linux-kernel@...r.kernel.org, David Windsor <dave@...lcore.net>, Pekka Enberg <penberg@...nel.org>, David Rientjes <rientjes@...gle.com>, Joonsoo Kim <iamjoonsoo.kim@....com>, Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org, linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org, netdev@...r.kernel.org, kernel-hardening@...ts.openwall.com Subject: Re: [PATCH v3 03/31] usercopy: Mark kmalloc caches as usercopy caches On Wed, 20 Sep 2017, Kees Cook wrote: > --- a/mm/slab.c > +++ b/mm/slab.c > @@ -1291,7 +1291,8 @@ void __init kmem_cache_init(void) > */ > kmalloc_caches[INDEX_NODE] = create_kmalloc_cache( > kmalloc_info[INDEX_NODE].name, > - kmalloc_size(INDEX_NODE), ARCH_KMALLOC_FLAGS); > + kmalloc_size(INDEX_NODE), ARCH_KMALLOC_FLAGS, > + 0, kmalloc_size(INDEX_NODE)); > slab_state = PARTIAL_NODE; > setup_kmalloc_cache_index_table(); Ok this presumes that at some point we will be able to restrict the number of bytes writeable and thus set the offset and size field to different values. Is that realistic? We already whitelist all kmalloc caches (see first patch). So what is the point of this patch?
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.