Date: Tue, 16 Apr 2019 18:01:38 +0200 From: Alexander Potapenko <glider@...gle.com> To: Christopher Lameter <cl@...ux.com> Cc: Andrew Morton <akpm@...ux-foundation.org>, linux-security-module <linux-security-module@...r.kernel.org>, Linux Memory Management List <linux-mm@...ck.org>, Nick Desaulniers <ndesaulniers@...gle.com>, Kostya Serebryany <kcc@...gle.com>, Dmitriy Vyukov <dvyukov@...gle.com>, Kees Cook <keescook@...omium.org>, Sandeep Patil <sspatil@...roid.com>, Laura Abbott <labbott@...hat.com>, Kernel Hardening <kernel-hardening@...ts.openwall.com> Subject: Re: [PATCH] mm: security: introduce CONFIG_INIT_HEAP_ALL On Tue, Apr 16, 2019 at 5:32 PM Christopher Lameter <cl@...ux.com> wrote: > > On Fri, 12 Apr 2019, Alexander Potapenko wrote: > > > diff --git a/mm/slab.h b/mm/slab.h > > index 43ac818b8592..4bb10af0031b 100644 > > --- a/mm/slab.h > > +++ b/mm/slab.h > > @@ -167,6 +167,16 @@ static inline slab_flags_t kmem_cache_flags(unsigned int object_size, > > SLAB_TEMPORARY | \ > > SLAB_ACCOUNT) > > > > +/* > > + * Do we need to initialize this allocation? > > + * Always true for __GFP_ZERO, CONFIG_INIT_HEAP_ALL enforces initialization > > + * of caches without constructors and RCU. > > + */ > > +#define SLAB_WANT_INIT(cache, gfp_flags) \ > > + ((GFP_INIT_ALWAYS_ON && !(cache)->ctor && \ > > + !((cache)->flags & SLAB_TYPESAFE_BY_RCU)) || \ > > + (gfp_flags & __GFP_ZERO)) > > This is another complex thing to maintain when adding flags to the slab > allocator. > > > +config INIT_HEAP_ALL > > + bool "Initialize kernel heap allocations" > > "Zero pages and objects allocated in the kernel" > > > + default n > > + help > > + Enforce initialization of pages allocated from page allocator > > + and objects returned by kmalloc and friends. > > + Allocated memory is initialized with zeroes, preventing possible > > + information leaks and making the control-flow bugs that depend > > + on uninitialized values more deterministic. > > Hmmm... But we already have debugging options that poison objects and > pages? Laura Abbott mentioned in one of the previous threads (https://marc.info/?l=kernel-hardening&m=155474181528491&w=2) that: """ I've looked at doing something similar in the past (failing to find the thread this morning...) and while this will work, it has pretty serious performance issues. It's not actually the poisoning which is expensive but that turning on debugging removes the cpu slab which has significant performance penalties. I'd rather go back to the proposal of just poisoning the slab at alloc/free without using SLAB_POISON. """ , so slab poisoning is probably off the table. -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg
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.