Re: [PATCH 02/36] usercopy: Include offset in overflow report

2018-01-10 Thread Christopher Lameter
On Tue, 9 Jan 2018, Kees Cook wrote: > -static void report_usercopy(unsigned long len, bool to_user, const char > *type) > +int report_usercopy(const char *name, const char *detail, bool to_user, > + unsigned long offset, unsigned long len) > { > - pr_emerg("kernel memory %s

Re: [PATCH 05/36] usercopy: WARN() on slab cache usercopy region violations

2018-01-10 Thread Christopher Lameter
On Tue, 9 Jan 2018, Kees Cook wrote: > @@ -3823,11 +3825,9 @@ int __check_heap_object(const void *ptr, unsigned long > n, struct page *page, Could we do the check in mm_slab_common.c for all allocators and just have a small function in each allocators that give you the metadata needed for the ob

Re: [PATCH 04/36] usercopy: Prepare for usercopy whitelisting

2018-01-10 Thread Christopher Lameter
On Tue, 9 Jan 2018, Kees Cook wrote: > +struct kmem_cache *kmem_cache_create_usercopy(const char *name, > + size_t size, size_t align, slab_flags_t flags, > + size_t useroffset, size_t usersize, > + void (*ctor)(void *)); Hmmm... At some

Re: [PATCH 02/38] usercopy: Enhance and rename report_usercopy()

2018-01-11 Thread Christopher Lameter
On Wed, 10 Jan 2018, Kees Cook wrote: > diff --git a/mm/slab.h b/mm/slab.h > index ad657ffa44e5..7d29e69ac310 100644 > --- a/mm/slab.h > +++ b/mm/slab.h > @@ -526,4 +526,10 @@ static inline int cache_random_seq_create(struct > kmem_cache *cachep, > static inline void cache_random_seq_destroy(str

RE: [PATCH 04/36] usercopy: Prepare for usercopy whitelisting

2018-01-12 Thread Christopher Lameter
On Fri, 12 Jan 2018, David Laight wrote: > > Hmmm... At some point we should switch kmem_cache_create to pass a struct > > containing all the parameters. Otherwise the API will blow up with > > additional functions. > > Or add an extra function to 'configure' the kmem_cache with the > extra parame

kmem_cache_attr (was Re: [PATCH 04/36] usercopy: Prepare for usercopy whitelisting)

2018-01-16 Thread Christopher Lameter
On Sun, 14 Jan 2018, Matthew Wilcox wrote: > > Hmmm... At some point we should switch kmem_cache_create to pass a struct > > containing all the parameters. Otherwise the API will blow up with > > additional functions. > > Obviously I agree with you. I'm inclined to not let that delay Kees' > patc

Re: kmem_cache_attr (was Re: [PATCH 04/36] usercopy: Prepare for usercopy whitelisting)

2018-01-16 Thread Christopher Lameter
On Tue, 16 Jan 2018, Matthew Wilcox wrote: > I think that's a good thing! /proc/slabinfo really starts to get grotty > above 16 bytes. I'd like to chop off "_cache" from the name of every > single slab! If ext4_allocation_context has to become ext4_alloc_ctx, > I don't think we're going to lose

Re: kmem_cache_attr (was Re: [PATCH 04/36] usercopy: Prepare for usercopy whitelisting)

2018-01-16 Thread Christopher Lameter
On Tue, 16 Jan 2018, Matthew Wilcox wrote: > > Sure this data is never changed. It can be const. > > It's changed at initialisation. Look: > > kmem_cache_create(const char *name, size_t size, size_t align, > slab_flags_t flags, void (*ctor)(void *)) > s = create_cache(ca

Re: kmem_cache_attr (was Re: [PATCH 04/36] usercopy: Prepare for usercopy whitelisting)

2018-01-16 Thread Christopher Lameter
Draft patch of how the data structs could change. kmem_cache_attr is read only. Index: linux/include/linux/slab.h === --- linux.orig/include/linux/slab.h +++ linux/include/linux/slab.h @@ -135,9 +135,17 @@ struct mem_cgroup; void __i

Re: kmem_cache_attr (was Re: [PATCH 04/36] usercopy: Prepare for usercopy whitelisting)

2018-01-17 Thread Christopher Lameter
On Tue, 16 Jan 2018, Matthew Wilcox wrote: > On Tue, Jan 16, 2018 at 12:17:01PM -0600, Christopher Lameter wrote: > > Draft patch of how the data structs could change. kmem_cache_attr is read > > only. > > Looks good. Although I would add Kees' user feature: Sure I t

Re: [PATCH v3 02/31] usercopy: Enforce slab cache usercopy region boundaries

2017-09-21 Thread Christopher Lameter
On Wed, 20 Sep 2017, Kees Cook wrote: > diff --git a/mm/slab.c b/mm/slab.c > index 87b6e5e0cdaf..df268999cf02 100644 > --- a/mm/slab.c > +++ b/mm/slab.c > @@ -4408,7 +4408,9 @@ module_init(slab_proc_init); > > #ifdef CONFIG_HARDENED_USERCOPY > /* > - * Rejects objects that are incorrectly sized.

Re: [PATCH v3 01/31] usercopy: Prepare for usercopy whitelisting

2017-09-21 Thread Christopher Lameter
On Wed, 20 Sep 2017, Kees Cook wrote: > diff --git a/include/linux/stddef.h b/include/linux/stddef.h > index 9c61c7cda936..f00355086fb2 100644 > --- a/include/linux/stddef.h > +++ b/include/linux/stddef.h > @@ -18,6 +18,8 @@ enum { > #define offsetof(TYPE, MEMBER) ((size_t)&((TYPE *)0)->MEM

Re: [PATCH v3 03/31] usercopy: Mark kmalloc caches as usercopy caches

2017-09-21 Thread Christopher Lameter
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, > -

Re: [kernel-hardening] Re: [PATCH v3 03/31] usercopy: Mark kmalloc caches as usercopy caches

2017-09-21 Thread Christopher Lameter
On Thu, 21 Sep 2017, Kees Cook wrote: > > So what is the point of this patch? > > The DMA kmalloc caches are not whitelisted: The DMA kmalloc caches are pretty obsolete and mostly there for obscure drivers. ?? > >> kmalloc_dma_caches[i] = create_kmalloc_cache(n, > >> -

Re: BUG: unable to handle kernel NULL pointer dereference in setup_kmem_cache_node

2019-01-02 Thread Christopher Lameter
On Wed, 2 Jan 2019, Dmitry Vyukov wrote: > Am I missing something or __alloc_alien_cache misses check for > kmalloc_node result? > > static struct alien_cache *__alloc_alien_cache(int node, int entries, > int batch, gfp_t gfp) > { > size_t me