* [RFC v1] mm: SLAB freelist randomization @ 2016-04-06 19:35 Thomas Garnier 2016-04-06 20:54 ` [kernel-hardening] " Greg KH 2016-04-06 21:45 ` Kees Cook 0 siblings, 2 replies; 9+ messages in thread From: Thomas Garnier @ 2016-04-06 19:35 UTC (permalink / raw) To: Christoph Lameter, Pekka Enberg, David Rientjes, Joonsoo Kim, Andrew Morton Cc: gthelen, keescook, kernel-hardening, linux-kernel, linux-mm, labbott, Thomas Garnier Provide an optional config (CONFIG_FREELIST_RANDOM) to randomize the SLAB freelist. This security feature reduces the predictability of the kernel slab allocator against heap overflows. Randomized lists are pre-computed using a Fisher-Yates shuffle and re-used on slab creation for performance. --- Based on next-20160405 --- init/Kconfig | 9 ++++ mm/slab.c | 155 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 164 insertions(+) diff --git a/init/Kconfig b/init/Kconfig index 0dfd09d..ee35418 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1742,6 +1742,15 @@ config SLOB endchoice +config FREELIST_RANDOM + default n + depends on SLAB + bool "SLAB freelist randomization" + help + Randomizes the freelist order used on creating new SLABs. This + security feature reduces the predictability of the kernel slab + allocator against heap overflows. + config SLUB_CPU_PARTIAL default y depends on SLUB && SMP diff --git a/mm/slab.c b/mm/slab.c index b70aabf..6f0d7be 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -1229,6 +1229,59 @@ static void __init set_up_node(struct kmem_cache *cachep, int index) } } +#ifdef CONFIG_FREELIST_RANDOM +/* + * Master lists are pre-computed random lists + * Lists of different sizes are used to optimize performance on different + * SLAB object sizes per pages. + */ +static freelist_idx_t master_list_2[2]; +static freelist_idx_t master_list_4[4]; +static freelist_idx_t master_list_8[8]; +static freelist_idx_t master_list_16[16]; +static freelist_idx_t master_list_32[32]; +static freelist_idx_t master_list_64[64]; +static freelist_idx_t master_list_128[128]; +static freelist_idx_t master_list_256[256]; +static struct m_list { + size_t count; + freelist_idx_t *list; +} master_lists[] = { + { ARRAY_SIZE(master_list_2), master_list_2 }, + { ARRAY_SIZE(master_list_4), master_list_4 }, + { ARRAY_SIZE(master_list_8), master_list_8 }, + { ARRAY_SIZE(master_list_16), master_list_16 }, + { ARRAY_SIZE(master_list_32), master_list_32 }, + { ARRAY_SIZE(master_list_64), master_list_64 }, + { ARRAY_SIZE(master_list_128), master_list_128 }, + { ARRAY_SIZE(master_list_256), master_list_256 }, +}; + +void __init freelist_random_init(void) +{ + unsigned int seed; + size_t z, i, rand; + struct rnd_state slab_rand; + + get_random_bytes_arch(&seed, sizeof(seed)); + prandom_seed_state(&slab_rand, seed); + + for (z = 0; z < ARRAY_SIZE(master_lists); z++) { + for (i = 0; i < master_lists[z].count; i++) + master_lists[z].list[i] = i; + + /* Fisher-Yates shuffle */ + for (i = master_lists[z].count - 1; i > 0; i--) { + rand = prandom_u32_state(&slab_rand); + rand %= (i + 1); + swap(master_lists[z].list[i], + master_lists[z].list[rand]); + } + } +} +#endif /* CONFIG_FREELIST_RANDOM */ + + /* * Initialisation. Called after the page allocator have been initialised and * before smp_init(). @@ -1255,6 +1308,10 @@ void __init kmem_cache_init(void) if (!slab_max_order_set && totalram_pages > (32 << 20) >> PAGE_SHIFT) slab_max_order = SLAB_MAX_ORDER_HI; +#ifdef CONFIG_FREELIST_RANDOM + freelist_random_init(); +#endif /* CONFIG_FREELIST_RANDOM */ + /* Bootstrap is tricky, because several objects are allocated * from caches that do not exist yet: * 1) initialize the kmem_cache cache: it contains the struct @@ -2442,6 +2499,98 @@ static void cache_init_objs_debug(struct kmem_cache *cachep, struct page *page) #endif } +#ifdef CONFIG_FREELIST_RANDOM +enum master_type { + match, + less, + more +}; + +struct random_mng { + unsigned int padding; + unsigned int pos; + unsigned int count; + struct m_list master_list; + unsigned int master_count; + enum master_type type; +}; + +static void random_mng_initialize(struct random_mng *mng, unsigned int count) +{ + unsigned int idx; + const unsigned int last_idx = ARRAY_SIZE(master_lists) - 1; + + memset(mng, 0, sizeof(*mng)); + mng->count = count; + mng->pos = 0; + /* count is >= 2 */ + idx = ilog2(count) - 1; + if (idx >= last_idx) + idx = last_idx; + else if (roundup_pow_of_two(idx + 1) != count) + idx++; + mng->master_list = master_lists[idx]; + if (mng->master_list.count == mng->count) + mng->type = match; + else if (mng->master_list.count > mng->count) + mng->type = more; + else + mng->type = less; +} + +static freelist_idx_t get_next_entry(struct random_mng *mng) +{ + if (mng->type == less && mng->pos == mng->master_list.count) { + mng->padding += mng->pos; + mng->pos = 0; + } + BUG_ON(mng->pos >= mng->master_list.count); + return mng->master_list.list[mng->pos++]; +} + +static freelist_idx_t next_random_slot(struct random_mng *mng) +{ + freelist_idx_t cur, entry; + + entry = get_next_entry(mng); + + if (mng->type != match) { + while ((entry + mng->padding) >= mng->count) + entry = get_next_entry(mng); + cur = entry + mng->padding; + BUG_ON(cur >= mng->count); + } else { + cur = entry; + } + + return cur; +} + +static void shuffle_freelist(struct kmem_cache *cachep, struct page *page, + unsigned int count) +{ + unsigned int i; + struct random_mng mng; + + if (count < 2) { + for (i = 0; i < count; i++) + set_free_obj(page, i, i); + return; + } + + /* Last chunk is used already in this case */ + if (OBJFREELIST_SLAB(cachep)) + count--; + + random_mng_initialize(&mng, count); + for (i = 0; i < count; i++) + set_free_obj(page, i, next_random_slot(&mng)); + + if (OBJFREELIST_SLAB(cachep)) + set_free_obj(page, i, i); +} +#endif /* CONFIG_FREELIST_RANDOM */ + static void cache_init_objs(struct kmem_cache *cachep, struct page *page) { @@ -2464,8 +2613,14 @@ static void cache_init_objs(struct kmem_cache *cachep, kasan_poison_object_data(cachep, objp); } +#ifndef CONFIG_FREELIST_RANDOM set_free_obj(page, i, i); +#endif /* CONFIG_FREELIST_RANDOM */ } + +#ifdef CONFIG_FREELIST_RANDOM + shuffle_freelist(cachep, page, cachep->num); +#endif /* CONFIG_FREELIST_RANDOM */ } static void kmem_flagcheck(struct kmem_cache *cachep, gfp_t flags) -- 2.8.0.rc3.226.g39d4020 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [kernel-hardening] [RFC v1] mm: SLAB freelist randomization 2016-04-06 19:35 [RFC v1] mm: SLAB freelist randomization Thomas Garnier @ 2016-04-06 20:54 ` Greg KH 2016-04-06 21:03 ` Thomas Garnier 2016-04-06 21:45 ` Kees Cook 1 sibling, 1 reply; 9+ messages in thread From: Greg KH @ 2016-04-06 20:54 UTC (permalink / raw) To: kernel-hardening Cc: Christoph Lameter, Pekka Enberg, David Rientjes, Joonsoo Kim, Andrew Morton, gthelen, keescook, linux-kernel, linux-mm, labbott, Thomas Garnier On Wed, Apr 06, 2016 at 12:35:48PM -0700, Thomas Garnier wrote: > Provide an optional config (CONFIG_FREELIST_RANDOM) to randomize the > SLAB freelist. This security feature reduces the predictability of > the kernel slab allocator against heap overflows. > > Randomized lists are pre-computed using a Fisher-Yates shuffle and > re-used on slab creation for performance. > --- > Based on next-20160405 > --- No signed-off-by:? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [kernel-hardening] [RFC v1] mm: SLAB freelist randomization 2016-04-06 20:54 ` [kernel-hardening] " Greg KH @ 2016-04-06 21:03 ` Thomas Garnier 0 siblings, 0 replies; 9+ messages in thread From: Thomas Garnier @ 2016-04-06 21:03 UTC (permalink / raw) To: Greg KH Cc: kernel-hardening, Christoph Lameter, Pekka Enberg, David Rientjes, Joonsoo Kim, Andrew Morton, Greg Thelen, Kees Cook, linux-kernel, linux-mm, labbott Yes, sorry about that. It will be in the next RFC or PATCH. On Wed, Apr 6, 2016 at 1:54 PM, Greg KH <gregkh@linuxfoundation.org> wrote: > On Wed, Apr 06, 2016 at 12:35:48PM -0700, Thomas Garnier wrote: >> Provide an optional config (CONFIG_FREELIST_RANDOM) to randomize the >> SLAB freelist. This security feature reduces the predictability of >> the kernel slab allocator against heap overflows. >> >> Randomized lists are pre-computed using a Fisher-Yates shuffle and >> re-used on slab creation for performance. >> --- >> Based on next-20160405 >> --- > > No signed-off-by:? > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC v1] mm: SLAB freelist randomization 2016-04-06 19:35 [RFC v1] mm: SLAB freelist randomization Thomas Garnier 2016-04-06 20:54 ` [kernel-hardening] " Greg KH @ 2016-04-06 21:45 ` Kees Cook 2016-04-07 15:28 ` Thomas Garnier ` (2 more replies) 1 sibling, 3 replies; 9+ messages in thread From: Kees Cook @ 2016-04-06 21:45 UTC (permalink / raw) To: Thomas Garnier Cc: Christoph Lameter, Pekka Enberg, David Rientjes, Joonsoo Kim, Andrew Morton, Greg Thelen, kernel-hardening, LKML, Linux-MM, Laura Abbott On Wed, Apr 6, 2016 at 12:35 PM, Thomas Garnier <thgarnie@google.com> wrote: > Provide an optional config (CONFIG_FREELIST_RANDOM) to randomize the > SLAB freelist. It may be useful to describe _how_ it randomizes it (i.e. a high-level description of what needed changing). > This security feature reduces the predictability of > the kernel slab allocator against heap overflows. I would add "... rendering attacks much less stable." And if you can find a specific example exploit that is foiled by this, I would refer to it. > Randomized lists are pre-computed using a Fisher-Yates shuffle and Should the use of Fisher-Yates (over other things) be justified? > re-used on slab creation for performance. I'd like to see some benchmark results for this so the Kconfig can include the performance characteristics. I recommend using hackbench and kernel build times with a before/after comparison. > --- > Based on next-20160405 > --- > init/Kconfig | 9 ++++ > mm/slab.c | 155 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 164 insertions(+) > > diff --git a/init/Kconfig b/init/Kconfig > index 0dfd09d..ee35418 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -1742,6 +1742,15 @@ config SLOB > > endchoice > > +config FREELIST_RANDOM I think I would name this "SLAB_FREELIST_RANDOM" since it's SLAB-specific, unless you think it could be extended to the other allocators in the future too? (If so, I'd mention the naming choice in the commit log.) > + default n > + depends on SLAB > + bool "SLAB freelist randomization" > + help > + Randomizes the freelist order used on creating new SLABs. This > + security feature reduces the predictability of the kernel slab > + allocator against heap overflows. > + > config SLUB_CPU_PARTIAL > default y > depends on SLUB && SMP > diff --git a/mm/slab.c b/mm/slab.c > index b70aabf..6f0d7be 100644 > --- a/mm/slab.c > +++ b/mm/slab.c > @@ -1229,6 +1229,59 @@ static void __init set_up_node(struct kmem_cache *cachep, int index) > } > } > > +#ifdef CONFIG_FREELIST_RANDOM > +/* > + * Master lists are pre-computed random lists > + * Lists of different sizes are used to optimize performance on different > + * SLAB object sizes per pages. > + */ > +static freelist_idx_t master_list_2[2]; > +static freelist_idx_t master_list_4[4]; > +static freelist_idx_t master_list_8[8]; > +static freelist_idx_t master_list_16[16]; > +static freelist_idx_t master_list_32[32]; > +static freelist_idx_t master_list_64[64]; > +static freelist_idx_t master_list_128[128]; > +static freelist_idx_t master_list_256[256]; > +static struct m_list { > + size_t count; > + freelist_idx_t *list; > +} master_lists[] = { > + { ARRAY_SIZE(master_list_2), master_list_2 }, > + { ARRAY_SIZE(master_list_4), master_list_4 }, > + { ARRAY_SIZE(master_list_8), master_list_8 }, > + { ARRAY_SIZE(master_list_16), master_list_16 }, > + { ARRAY_SIZE(master_list_32), master_list_32 }, > + { ARRAY_SIZE(master_list_64), master_list_64 }, > + { ARRAY_SIZE(master_list_128), master_list_128 }, > + { ARRAY_SIZE(master_list_256), master_list_256 }, > +}; > + > +void __init freelist_random_init(void) > +{ > + unsigned int seed; > + size_t z, i, rand; > + struct rnd_state slab_rand; > + > + get_random_bytes_arch(&seed, sizeof(seed)); > + prandom_seed_state(&slab_rand, seed); > + > + for (z = 0; z < ARRAY_SIZE(master_lists); z++) { > + for (i = 0; i < master_lists[z].count; i++) > + master_lists[z].list[i] = i; > + > + /* Fisher-Yates shuffle */ > + for (i = master_lists[z].count - 1; i > 0; i--) { > + rand = prandom_u32_state(&slab_rand); > + rand %= (i + 1); > + swap(master_lists[z].list[i], > + master_lists[z].list[rand]); > + } > + } > +} For below... #else static inline freelist_random_init(void) { } > +#endif /* CONFIG_FREELIST_RANDOM */ > + > + > /* > * Initialisation. Called after the page allocator have been initialised and > * before smp_init(). > @@ -1255,6 +1308,10 @@ void __init kmem_cache_init(void) > if (!slab_max_order_set && totalram_pages > (32 << 20) >> PAGE_SHIFT) > slab_max_order = SLAB_MAX_ORDER_HI; > > +#ifdef CONFIG_FREELIST_RANDOM > + freelist_random_init(); > +#endif /* CONFIG_FREELIST_RANDOM */ Rather than these embedded ifdefs, I would create stub function at the top, as above. > + > /* Bootstrap is tricky, because several objects are allocated > * from caches that do not exist yet: > * 1) initialize the kmem_cache cache: it contains the struct > @@ -2442,6 +2499,98 @@ static void cache_init_objs_debug(struct kmem_cache *cachep, struct page *page) > #endif > } > > +#ifdef CONFIG_FREELIST_RANDOM > +enum master_type { > + match, > + less, > + more > +}; > + > +struct random_mng { > + unsigned int padding; > + unsigned int pos; > + unsigned int count; > + struct m_list master_list; > + unsigned int master_count; > + enum master_type type; > +}; > + > +static void random_mng_initialize(struct random_mng *mng, unsigned int count) > +{ > + unsigned int idx; > + const unsigned int last_idx = ARRAY_SIZE(master_lists) - 1; > + > + memset(mng, 0, sizeof(*mng)); > + mng->count = count; > + mng->pos = 0; > + /* count is >= 2 */ > + idx = ilog2(count) - 1; > + if (idx >= last_idx) > + idx = last_idx; > + else if (roundup_pow_of_two(idx + 1) != count) > + idx++; > + mng->master_list = master_lists[idx]; > + if (mng->master_list.count == mng->count) > + mng->type = match; > + else if (mng->master_list.count > mng->count) > + mng->type = more; > + else > + mng->type = less; > +} > + > +static freelist_idx_t get_next_entry(struct random_mng *mng) > +{ > + if (mng->type == less && mng->pos == mng->master_list.count) { > + mng->padding += mng->pos; > + mng->pos = 0; > + } > + BUG_ON(mng->pos >= mng->master_list.count); > + return mng->master_list.list[mng->pos++]; > +} > + > +static freelist_idx_t next_random_slot(struct random_mng *mng) > +{ > + freelist_idx_t cur, entry; > + > + entry = get_next_entry(mng); > + > + if (mng->type != match) { > + while ((entry + mng->padding) >= mng->count) > + entry = get_next_entry(mng); > + cur = entry + mng->padding; > + BUG_ON(cur >= mng->count); > + } else { > + cur = entry; > + } > + > + return cur; > +} > + > +static void shuffle_freelist(struct kmem_cache *cachep, struct page *page, > + unsigned int count) > +{ > + unsigned int i; > + struct random_mng mng; > + > + if (count < 2) { > + for (i = 0; i < count; i++) > + set_free_obj(page, i, i); > + return; > + } > + > + /* Last chunk is used already in this case */ > + if (OBJFREELIST_SLAB(cachep)) > + count--; > + > + random_mng_initialize(&mng, count); > + for (i = 0; i < count; i++) > + set_free_obj(page, i, next_random_slot(&mng)); > + > + if (OBJFREELIST_SLAB(cachep)) > + set_free_obj(page, i, i); > +} Same thing here... #else static inline void set_free_obj(...) { } static inline void shuffle_freelist(struct kmem_cache *cachep, struct page *page, unsigned int count) { } > +#endif /* CONFIG_FREELIST_RANDOM */ > + > static void cache_init_objs(struct kmem_cache *cachep, > struct page *page) > { > @@ -2464,8 +2613,14 @@ static void cache_init_objs(struct kmem_cache *cachep, > kasan_poison_object_data(cachep, objp); > } > > +#ifndef CONFIG_FREELIST_RANDOM > set_free_obj(page, i, i); > +#endif /* CONFIG_FREELIST_RANDOM */ For this one, I'd use: if (config_enabled(CONFIG_FREELIST_RANDOM)) set_free_obj(page, i, i); > } > + > +#ifdef CONFIG_FREELIST_RANDOM > + shuffle_freelist(cachep, page, cachep->num); > +#endif /* CONFIG_FREELIST_RANDOM */ This one can drop the ifdef in favor of using the stub function too. > } > > static void kmem_flagcheck(struct kmem_cache *cachep, gfp_t flags) > -- > 2.8.0.rc3.226.g39d4020 > Exciting! -Kees -- Kees Cook Chrome OS & Brillo Security -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC v1] mm: SLAB freelist randomization 2016-04-06 21:45 ` Kees Cook @ 2016-04-07 15:28 ` Thomas Garnier 2016-04-07 16:17 ` [kernel-hardening] " Yves-Alexis Perez 2016-04-07 21:14 ` Jesper Dangaard Brouer 2 siblings, 0 replies; 9+ messages in thread From: Thomas Garnier @ 2016-04-07 15:28 UTC (permalink / raw) To: Kees Cook Cc: Christoph Lameter, Pekka Enberg, David Rientjes, Joonsoo Kim, Andrew Morton, Greg Thelen, kernel-hardening, LKML, Linux-MM, Laura Abbott Thanks for the feedback Kees. I am preparing another RFC version. For the config, I plan on creating an equivalent option for SLUB. Both can benefit from randomizing their freelist order. Thomas On Wed, Apr 6, 2016 at 2:45 PM Kees Cook <keescook@chromium.org> wrote: > > On Wed, Apr 6, 2016 at 12:35 PM, Thomas Garnier <thgarnie@google.com> wrote: > > Provide an optional config (CONFIG_FREELIST_RANDOM) to randomize the > > SLAB freelist. > > It may be useful to describe _how_ it randomizes it (i.e. a high-level > description of what needed changing). > > > This security feature reduces the predictability of > > the kernel slab allocator against heap overflows. > > I would add "... rendering attacks much less stable." And if you can > find a specific example exploit that is foiled by this, I would refer > to it. > > > Randomized lists are pre-computed using a Fisher-Yates shuffle and > > Should the use of Fisher-Yates (over other things) be justified? > > > re-used on slab creation for performance. > > I'd like to see some benchmark results for this so the Kconfig can > include the performance characteristics. I recommend using hackbench > and kernel build times with a before/after comparison. > > > --- > > Based on next-20160405 > > --- > > init/Kconfig | 9 ++++ > > mm/slab.c | 155 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > 2 files changed, 164 insertions(+) > > > > diff --git a/init/Kconfig b/init/Kconfig > > index 0dfd09d..ee35418 100644 > > --- a/init/Kconfig > > +++ b/init/Kconfig > > @@ -1742,6 +1742,15 @@ config SLOB > > > > endchoice > > > > +config FREELIST_RANDOM > > I think I would name this "SLAB_FREELIST_RANDOM" since it's > SLAB-specific, unless you think it could be extended to the other > allocators in the future too? (If so, I'd mention the naming choice in > the commit log.) > > > + default n > > + depends on SLAB > > + bool "SLAB freelist randomization" > > + help > > + Randomizes the freelist order used on creating new SLABs. This > > + security feature reduces the predictability of the kernel slab > > + allocator against heap overflows. > > + > > config SLUB_CPU_PARTIAL > > default y > > depends on SLUB && SMP > > diff --git a/mm/slab.c b/mm/slab.c > > index b70aabf..6f0d7be 100644 > > --- a/mm/slab.c > > +++ b/mm/slab.c > > @@ -1229,6 +1229,59 @@ static void __init set_up_node(struct kmem_cache *cachep, int index) > > } > > } > > > > +#ifdef CONFIG_FREELIST_RANDOM > > +/* > > + * Master lists are pre-computed random lists > > + * Lists of different sizes are used to optimize performance on different > > + * SLAB object sizes per pages. > > + */ > > +static freelist_idx_t master_list_2[2]; > > +static freelist_idx_t master_list_4[4]; > > +static freelist_idx_t master_list_8[8]; > > +static freelist_idx_t master_list_16[16]; > > +static freelist_idx_t master_list_32[32]; > > +static freelist_idx_t master_list_64[64]; > > +static freelist_idx_t master_list_128[128]; > > +static freelist_idx_t master_list_256[256]; > > +static struct m_list { > > + size_t count; > > + freelist_idx_t *list; > > +} master_lists[] = { > > + { ARRAY_SIZE(master_list_2), master_list_2 }, > > + { ARRAY_SIZE(master_list_4), master_list_4 }, > > + { ARRAY_SIZE(master_list_8), master_list_8 }, > > + { ARRAY_SIZE(master_list_16), master_list_16 }, > > + { ARRAY_SIZE(master_list_32), master_list_32 }, > > + { ARRAY_SIZE(master_list_64), master_list_64 }, > > + { ARRAY_SIZE(master_list_128), master_list_128 }, > > + { ARRAY_SIZE(master_list_256), master_list_256 }, > > +}; > > + > > +void __init freelist_random_init(void) > > +{ > > + unsigned int seed; > > + size_t z, i, rand; > > + struct rnd_state slab_rand; > > + > > + get_random_bytes_arch(&seed, sizeof(seed)); > > + prandom_seed_state(&slab_rand, seed); > > + > > + for (z = 0; z < ARRAY_SIZE(master_lists); z++) { > > + for (i = 0; i < master_lists[z].count; i++) > > + master_lists[z].list[i] = i; > > + > > + /* Fisher-Yates shuffle */ > > + for (i = master_lists[z].count - 1; i > 0; i--) { > > + rand = prandom_u32_state(&slab_rand); > > + rand %= (i + 1); > > + swap(master_lists[z].list[i], > > + master_lists[z].list[rand]); > > + } > > + } > > +} > > For below... > > #else > static inline freelist_random_init(void) { } > > > +#endif /* CONFIG_FREELIST_RANDOM */ > > + > > + > > /* > > * Initialisation. Called after the page allocator have been initialised and > > * before smp_init(). > > @@ -1255,6 +1308,10 @@ void __init kmem_cache_init(void) > > if (!slab_max_order_set && totalram_pages > (32 << 20) >> PAGE_SHIFT) > > slab_max_order = SLAB_MAX_ORDER_HI; > > > > +#ifdef CONFIG_FREELIST_RANDOM > > + freelist_random_init(); > > +#endif /* CONFIG_FREELIST_RANDOM */ > > Rather than these embedded ifdefs, I would create stub function at the > top, as above. > > > + > > /* Bootstrap is tricky, because several objects are allocated > > * from caches that do not exist yet: > > * 1) initialize the kmem_cache cache: it contains the struct > > @@ -2442,6 +2499,98 @@ static void cache_init_objs_debug(struct kmem_cache *cachep, struct page *page) > > #endif > > } > > > > +#ifdef CONFIG_FREELIST_RANDOM > > +enum master_type { > > + match, > > + less, > > + more > > +}; > > + > > +struct random_mng { > > + unsigned int padding; > > + unsigned int pos; > > + unsigned int count; > > + struct m_list master_list; > > + unsigned int master_count; > > + enum master_type type; > > +}; > > + > > +static void random_mng_initialize(struct random_mng *mng, unsigned int count) > > +{ > > + unsigned int idx; > > + const unsigned int last_idx = ARRAY_SIZE(master_lists) - 1; > > + > > + memset(mng, 0, sizeof(*mng)); > > + mng->count = count; > > + mng->pos = 0; > > + /* count is >= 2 */ > > + idx = ilog2(count) - 1; > > + if (idx >= last_idx) > > + idx = last_idx; > > + else if (roundup_pow_of_two(idx + 1) != count) > > + idx++; > > + mng->master_list = master_lists[idx]; > > + if (mng->master_list.count == mng->count) > > + mng->type = match; > > + else if (mng->master_list.count > mng->count) > > + mng->type = more; > > + else > > + mng->type = less; > > +} > > + > > +static freelist_idx_t get_next_entry(struct random_mng *mng) > > +{ > > + if (mng->type == less && mng->pos == mng->master_list.count) { > > + mng->padding += mng->pos; > > + mng->pos = 0; > > + } > > + BUG_ON(mng->pos >= mng->master_list.count); > > + return mng->master_list.list[mng->pos++]; > > +} > > + > > +static freelist_idx_t next_random_slot(struct random_mng *mng) > > +{ > > + freelist_idx_t cur, entry; > > + > > + entry = get_next_entry(mng); > > + > > + if (mng->type != match) { > > + while ((entry + mng->padding) >= mng->count) > > + entry = get_next_entry(mng); > > + cur = entry + mng->padding; > > + BUG_ON(cur >= mng->count); > > + } else { > > + cur = entry; > > + } > > + > > + return cur; > > +} > > + > > +static void shuffle_freelist(struct kmem_cache *cachep, struct page *page, > > + unsigned int count) > > +{ > > + unsigned int i; > > + struct random_mng mng; > > + > > + if (count < 2) { > > + for (i = 0; i < count; i++) > > + set_free_obj(page, i, i); > > + return; > > + } > > + > > + /* Last chunk is used already in this case */ > > + if (OBJFREELIST_SLAB(cachep)) > > + count--; > > + > > + random_mng_initialize(&mng, count); > > + for (i = 0; i < count; i++) > > + set_free_obj(page, i, next_random_slot(&mng)); > > + > > + if (OBJFREELIST_SLAB(cachep)) > > + set_free_obj(page, i, i); > > +} > > Same thing here... > > #else > static inline void set_free_obj(...) { } > static inline void shuffle_freelist(struct kmem_cache *cachep, > struct page *page, unsigned int count) { } > > > +#endif /* CONFIG_FREELIST_RANDOM */ > > + > > static void cache_init_objs(struct kmem_cache *cachep, > > struct page *page) > > { > > @@ -2464,8 +2613,14 @@ static void cache_init_objs(struct kmem_cache *cachep, > > kasan_poison_object_data(cachep, objp); > > } > > > > +#ifndef CONFIG_FREELIST_RANDOM > > set_free_obj(page, i, i); > > +#endif /* CONFIG_FREELIST_RANDOM */ > > For this one, I'd use: > > if (config_enabled(CONFIG_FREELIST_RANDOM)) > set_free_obj(page, i, i); > > > } > > + > > +#ifdef CONFIG_FREELIST_RANDOM > > + shuffle_freelist(cachep, page, cachep->num); > > +#endif /* CONFIG_FREELIST_RANDOM */ > > This one can drop the ifdef in favor of using the stub function too. > > > } > > > > static void kmem_flagcheck(struct kmem_cache *cachep, gfp_t flags) > > -- > > 2.8.0.rc3.226.g39d4020 > > > > Exciting! > > -Kees > > -- > Kees Cook > Chrome OS & Brillo Security -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [kernel-hardening] Re: [RFC v1] mm: SLAB freelist randomization 2016-04-06 21:45 ` Kees Cook 2016-04-07 15:28 ` Thomas Garnier @ 2016-04-07 16:17 ` Yves-Alexis Perez 2016-04-07 16:35 ` Thomas Garnier 2016-04-07 21:14 ` Jesper Dangaard Brouer 2 siblings, 1 reply; 9+ messages in thread From: Yves-Alexis Perez @ 2016-04-07 16:17 UTC (permalink / raw) To: kernel-hardening, Thomas Garnier Cc: Christoph Lameter, Pekka Enberg, David Rientjes, Joonsoo Kim, Andrew Morton, Greg Thelen, LKML, Linux-MM, Laura Abbott [-- Attachment #1: Type: text/plain, Size: 576 bytes --] On mer., 2016-04-06 at 14:45 -0700, Kees Cook wrote: > > This security feature reduces the predictability of > > the kernel slab allocator against heap overflows. > > I would add "... rendering attacks much less stable." And if you can > find a specific example exploit that is foiled by this, I would refer > to it. One good example might (or might not) be the keyring issue from earlier this year (CVE-2016-0728): http://perception-point.io/2016/01/14/analysis-and-exploitation-of-a-linux-ker nel-vulnerability-cve-2016-0728/ Regards, -- Yves-Alexis [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 473 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [kernel-hardening] Re: [RFC v1] mm: SLAB freelist randomization 2016-04-07 16:17 ` [kernel-hardening] " Yves-Alexis Perez @ 2016-04-07 16:35 ` Thomas Garnier 0 siblings, 0 replies; 9+ messages in thread From: Thomas Garnier @ 2016-04-07 16:35 UTC (permalink / raw) To: Yves-Alexis Perez Cc: kernel-hardening, Christoph Lameter, Pekka Enberg, David Rientjes, Joonsoo Kim, Andrew Morton, Greg Thelen, LKML, Linux-MM, Laura Abbott That's a use after free. The randomization of the freelist should not have much effect on that. I was going to quote this exploit that is applicable to SLAB as well: https://jon.oberheide.org/blog/2010/09/10/linux-kernel-can-slub-overflow Regards. Thomas On Thu, Apr 7, 2016 at 9:17 AM, Yves-Alexis Perez <corsac@debian.org> wrote: > On mer., 2016-04-06 at 14:45 -0700, Kees Cook wrote: >> > This security feature reduces the predictability of >> > the kernel slab allocator against heap overflows. >> >> I would add "... rendering attacks much less stable." And if you can >> find a specific example exploit that is foiled by this, I would refer >> to it. > > One good example might (or might not) be the keyring issue from earlier this > year (CVE-2016-0728): > > http://perception-point.io/2016/01/14/analysis-and-exploitation-of-a-linux-ker > nel-vulnerability-cve-2016-0728/ > > Regards, > -- > Yves-Alexis > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC v1] mm: SLAB freelist randomization 2016-04-06 21:45 ` Kees Cook 2016-04-07 15:28 ` Thomas Garnier 2016-04-07 16:17 ` [kernel-hardening] " Yves-Alexis Perez @ 2016-04-07 21:14 ` Jesper Dangaard Brouer 2016-04-08 2:31 ` Kees Cook 2 siblings, 1 reply; 9+ messages in thread From: Jesper Dangaard Brouer @ 2016-04-07 21:14 UTC (permalink / raw) To: Kees Cook Cc: brouer, Thomas Garnier, Christoph Lameter, Pekka Enberg, David Rientjes, Joonsoo Kim, Andrew Morton, Greg Thelen, kernel-hardening, LKML, Linux-MM, Laura Abbott On Wed, 6 Apr 2016 14:45:30 -0700 Kees Cook <keescook@chromium.org> wrote: > On Wed, Apr 6, 2016 at 12:35 PM, Thomas Garnier <thgarnie@google.com> wrote: [...] > > re-used on slab creation for performance. > > I'd like to see some benchmark results for this so the Kconfig can > include the performance characteristics. I recommend using hackbench > and kernel build times with a before/after comparison. > It looks like it only happens on init, right? (Thus must bench tools might not be the right choice). My slab tools for benchmarking the fastpath is here: https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/mm/slab_bulk_test01.c And I also carry a version of Christoph's slab bench tool: https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/mm/slab_test.c -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat Author of http://www.iptv-analyzer.org LinkedIn: http://www.linkedin.com/in/brouer -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC v1] mm: SLAB freelist randomization 2016-04-07 21:14 ` Jesper Dangaard Brouer @ 2016-04-08 2:31 ` Kees Cook 0 siblings, 0 replies; 9+ messages in thread From: Kees Cook @ 2016-04-08 2:31 UTC (permalink / raw) To: Jesper Dangaard Brouer Cc: Thomas Garnier, Christoph Lameter, Pekka Enberg, David Rientjes, Joonsoo Kim, Andrew Morton, Greg Thelen, kernel-hardening, LKML, Linux-MM, Laura Abbott On Thu, Apr 7, 2016 at 2:14 PM, Jesper Dangaard Brouer <brouer@redhat.com> wrote: > > On Wed, 6 Apr 2016 14:45:30 -0700 Kees Cook <keescook@chromium.org> wrote: > >> On Wed, Apr 6, 2016 at 12:35 PM, Thomas Garnier <thgarnie@google.com> wrote: > [...] >> > re-used on slab creation for performance. >> >> I'd like to see some benchmark results for this so the Kconfig can >> include the performance characteristics. I recommend using hackbench >> and kernel build times with a before/after comparison. >> > > It looks like it only happens on init, right? (Thus must bench tools > might not be the right choice). Oh! Yes, you're right. I entirely missed that detail. :) 0-cost randomization! Sounds good to me. :) -Kees > > My slab tools for benchmarking the fastpath is here: > https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/mm/slab_bulk_test01.c > > And I also carry a version of Christoph's slab bench tool: > https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/mm/slab_test.c > > -- > Best regards, > Jesper Dangaard Brouer > MSc.CS, Principal Kernel Engineer at Red Hat > Author of http://www.iptv-analyzer.org > LinkedIn: http://www.linkedin.com/in/brouer -- Kees Cook Chrome OS & Brillo Security -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2016-04-08 2:31 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-04-06 19:35 [RFC v1] mm: SLAB freelist randomization Thomas Garnier 2016-04-06 20:54 ` [kernel-hardening] " Greg KH 2016-04-06 21:03 ` Thomas Garnier 2016-04-06 21:45 ` Kees Cook 2016-04-07 15:28 ` Thomas Garnier 2016-04-07 16:17 ` [kernel-hardening] " Yves-Alexis Perez 2016-04-07 16:35 ` Thomas Garnier 2016-04-07 21:14 ` Jesper Dangaard Brouer 2016-04-08 2:31 ` Kees Cook
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox