Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1302291 > unrolled thread
| Started by | Kees Cook <keescook@chromium.org> |
|---|---|
| First post | 2016-01-06 01:30 +0100 |
| Last post | 2016-01-06 03:20 +0100 |
| Articles | 2 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [RFC][PATCH 5/7] mm: Mark several cases as SLAB_NO_SANITIZE Kees Cook <keescook@chromium.org> - 2016-01-06 01:30 +0100
Re: [RFC][PATCH 5/7] mm: Mark several cases as SLAB_NO_SANITIZE Laura Abbott <laura@labbott.name> - 2016-01-06 03:20 +0100
| From | Kees Cook <keescook@chromium.org> |
|---|---|
| Date | 2016-01-06 01:30 +0100 |
| Subject | Re: [RFC][PATCH 5/7] mm: Mark several cases as SLAB_NO_SANITIZE |
| Message-ID | <qNK9c-1YP-9@gated-at.bofh.it> |
On Mon, Dec 21, 2015 at 7:40 PM, Laura Abbott <laura@labbott.name> wrote:
>
> Sanitization is useful for security but comes at the cost of performance
> in clearing on free. Mark select caches as SLAB_NO_SANITIZE so
> sanitization will not happen under the default configuration. The
Can you describe why these were selected?
> kernel may be booted with the proper command line option to allow these
> caches to be sanitized.
Might be good to specifically mention the command line used to
sanitize even these caches.
-Kees
>
> All credit for the original work should be given to Brad Spengler and
> the PaX Team.
>
> Signed-off-by: Laura Abbott <laura@labbott.name>
> ---
> This is the initial set of excludes that the grsecurity patches had.
> More may need to be added/removed as the series is tested.
> ---
> fs/buffer.c | 2 +-
> fs/dcache.c | 2 +-
> kernel/fork.c | 2 +-
> mm/rmap.c | 4 ++--
> mm/slab.h | 2 +-
> net/core/skbuff.c | 16 ++++++++--------
> 6 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/fs/buffer.c b/fs/buffer.c
> index 4f4cd95..f19e4ab 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
> @@ -3417,7 +3417,7 @@ void __init buffer_init(void)
> bh_cachep = kmem_cache_create("buffer_head",
> sizeof(struct buffer_head), 0,
> (SLAB_RECLAIM_ACCOUNT|SLAB_PANIC|
> - SLAB_MEM_SPREAD),
> + SLAB_MEM_SPREAD|SLAB_NO_SANITIZE),
> NULL);
>
> /*
> diff --git a/fs/dcache.c b/fs/dcache.c
> index 5c33aeb..470f6be 100644
> --- a/fs/dcache.c
> +++ b/fs/dcache.c
> @@ -3451,7 +3451,7 @@ void __init vfs_caches_init_early(void)
> void __init vfs_caches_init(void)
> {
> names_cachep = kmem_cache_create("names_cache", PATH_MAX, 0,
> - SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
> + SLAB_NO_SANITIZE|SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
>
> dcache_init();
> inode_init();
> diff --git a/kernel/fork.c b/kernel/fork.c
> index fce002e..35db9c3 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -1868,7 +1868,7 @@ void __init proc_caches_init(void)
> mm_cachep = kmem_cache_create("mm_struct",
> sizeof(struct mm_struct), ARCH_MIN_MMSTRUCT_ALIGN,
> SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_NOTRACK, NULL);
> - vm_area_cachep = KMEM_CACHE(vm_area_struct, SLAB_PANIC);
> + vm_area_cachep = KMEM_CACHE(vm_area_struct, SLAB_PANIC|SLAB_NO_SANITIZE);
> mmap_init();
> nsproxy_cache_init();
> }
> diff --git a/mm/rmap.c b/mm/rmap.c
> index b577fbb..74296d9 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -428,8 +428,8 @@ static void anon_vma_ctor(void *data)
> void __init anon_vma_init(void)
> {
> anon_vma_cachep = kmem_cache_create("anon_vma", sizeof(struct anon_vma),
> - 0, SLAB_DESTROY_BY_RCU|SLAB_PANIC, anon_vma_ctor);
> - anon_vma_chain_cachep = KMEM_CACHE(anon_vma_chain, SLAB_PANIC);
> + 0, SLAB_DESTROY_BY_RCU|SLAB_PANIC|SLAB_NO_SANITIZE, anon_vma_ctor);
> + anon_vma_chain_cachep = KMEM_CACHE(anon_vma_chain, SLAB_PANIC|SLAB_NO_SANITIZE);
> }
>
> /*
> diff --git a/mm/slab.h b/mm/slab.h
> index b54b636..6de99da 100644
> --- a/mm/slab.h
> +++ b/mm/slab.h
> @@ -137,7 +137,7 @@ static inline unsigned long kmem_cache_flags(unsigned long object_size,
>
> /* Legal flag mask for kmem_cache_create(), for various configurations */
> #define SLAB_CORE_FLAGS (SLAB_HWCACHE_ALIGN | SLAB_CACHE_DMA | SLAB_PANIC | \
> - SLAB_DESTROY_BY_RCU | SLAB_DEBUG_OBJECTS )
> + SLAB_DESTROY_BY_RCU | SLAB_DEBUG_OBJECTS | SLAB_NO_SANITIZE)
>
> #if defined(CONFIG_DEBUG_SLAB)
> #define SLAB_DEBUG_FLAGS (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER)
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index b2df375..1d499ea 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -3316,15 +3316,15 @@ done:
> void __init skb_init(void)
> {
> skbuff_head_cache = kmem_cache_create("skbuff_head_cache",
> - sizeof(struct sk_buff),
> - 0,
> - SLAB_HWCACHE_ALIGN|SLAB_PANIC,
> - NULL);
> + sizeof(struct sk_buff),
> + 0,
> + SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_NO_SANITIZE,
> + NULL);
> skbuff_fclone_cache = kmem_cache_create("skbuff_fclone_cache",
> - sizeof(struct sk_buff_fclones),
> - 0,
> - SLAB_HWCACHE_ALIGN|SLAB_PANIC,
> - NULL);
> + sizeof(struct sk_buff_fclones),
> + 0,
> + SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_NO_SANITIZE,
> + NULL);
> }
>
> /**
> --
> 2.5.0
>
--
Kees Cook
Chrome OS & Brillo Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Laura Abbott <laura@labbott.name> |
|---|---|
| Date | 2016-01-06 03:20 +0100 |
| Message-ID | <qNLRE-39V-3@gated-at.bofh.it> |
| In reply to | #1302291 |
On 1/5/16 4:21 PM, Kees Cook wrote:
> On Mon, Dec 21, 2015 at 7:40 PM, Laura Abbott <laura@labbott.name> wrote:
>>
>> Sanitization is useful for security but comes at the cost of performance
>> in clearing on free. Mark select caches as SLAB_NO_SANITIZE so
>> sanitization will not happen under the default configuration. The
>
> Can you describe why these were selected?
>
These were the cases that existed in grsecurity. From looking, these seem
to be performance critical caches that have a relatively lower risk. I'll
adjust the commit text.
>> kernel may be booted with the proper command line option to allow these
>> caches to be sanitized.
>
> Might be good to specifically mention the command line used to
> sanitize even these caches.
Sure.
>
> -Kees
Thanks,
Laura
>
>>
>> All credit for the original work should be given to Brad Spengler and
>> the PaX Team.
>>
>> Signed-off-by: Laura Abbott <laura@labbott.name>
>> ---
>> This is the initial set of excludes that the grsecurity patches had.
>> More may need to be added/removed as the series is tested.
>> ---
>> fs/buffer.c | 2 +-
>> fs/dcache.c | 2 +-
>> kernel/fork.c | 2 +-
>> mm/rmap.c | 4 ++--
>> mm/slab.h | 2 +-
>> net/core/skbuff.c | 16 ++++++++--------
>> 6 files changed, 14 insertions(+), 14 deletions(-)
>>
>> diff --git a/fs/buffer.c b/fs/buffer.c
>> index 4f4cd95..f19e4ab 100644
>> --- a/fs/buffer.c
>> +++ b/fs/buffer.c
>> @@ -3417,7 +3417,7 @@ void __init buffer_init(void)
>> bh_cachep = kmem_cache_create("buffer_head",
>> sizeof(struct buffer_head), 0,
>> (SLAB_RECLAIM_ACCOUNT|SLAB_PANIC|
>> - SLAB_MEM_SPREAD),
>> + SLAB_MEM_SPREAD|SLAB_NO_SANITIZE),
>> NULL);
>>
>> /*
>> diff --git a/fs/dcache.c b/fs/dcache.c
>> index 5c33aeb..470f6be 100644
>> --- a/fs/dcache.c
>> +++ b/fs/dcache.c
>> @@ -3451,7 +3451,7 @@ void __init vfs_caches_init_early(void)
>> void __init vfs_caches_init(void)
>> {
>> names_cachep = kmem_cache_create("names_cache", PATH_MAX, 0,
>> - SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
>> + SLAB_NO_SANITIZE|SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
>>
>> dcache_init();
>> inode_init();
>> diff --git a/kernel/fork.c b/kernel/fork.c
>> index fce002e..35db9c3 100644
>> --- a/kernel/fork.c
>> +++ b/kernel/fork.c
>> @@ -1868,7 +1868,7 @@ void __init proc_caches_init(void)
>> mm_cachep = kmem_cache_create("mm_struct",
>> sizeof(struct mm_struct), ARCH_MIN_MMSTRUCT_ALIGN,
>> SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_NOTRACK, NULL);
>> - vm_area_cachep = KMEM_CACHE(vm_area_struct, SLAB_PANIC);
>> + vm_area_cachep = KMEM_CACHE(vm_area_struct, SLAB_PANIC|SLAB_NO_SANITIZE);
>> mmap_init();
>> nsproxy_cache_init();
>> }
>> diff --git a/mm/rmap.c b/mm/rmap.c
>> index b577fbb..74296d9 100644
>> --- a/mm/rmap.c
>> +++ b/mm/rmap.c
>> @@ -428,8 +428,8 @@ static void anon_vma_ctor(void *data)
>> void __init anon_vma_init(void)
>> {
>> anon_vma_cachep = kmem_cache_create("anon_vma", sizeof(struct anon_vma),
>> - 0, SLAB_DESTROY_BY_RCU|SLAB_PANIC, anon_vma_ctor);
>> - anon_vma_chain_cachep = KMEM_CACHE(anon_vma_chain, SLAB_PANIC);
>> + 0, SLAB_DESTROY_BY_RCU|SLAB_PANIC|SLAB_NO_SANITIZE, anon_vma_ctor);
>> + anon_vma_chain_cachep = KMEM_CACHE(anon_vma_chain, SLAB_PANIC|SLAB_NO_SANITIZE);
>> }
>>
>> /*
>> diff --git a/mm/slab.h b/mm/slab.h
>> index b54b636..6de99da 100644
>> --- a/mm/slab.h
>> +++ b/mm/slab.h
>> @@ -137,7 +137,7 @@ static inline unsigned long kmem_cache_flags(unsigned long object_size,
>>
>> /* Legal flag mask for kmem_cache_create(), for various configurations */
>> #define SLAB_CORE_FLAGS (SLAB_HWCACHE_ALIGN | SLAB_CACHE_DMA | SLAB_PANIC | \
>> - SLAB_DESTROY_BY_RCU | SLAB_DEBUG_OBJECTS )
>> + SLAB_DESTROY_BY_RCU | SLAB_DEBUG_OBJECTS | SLAB_NO_SANITIZE)
>>
>> #if defined(CONFIG_DEBUG_SLAB)
>> #define SLAB_DEBUG_FLAGS (SLAB_RED_ZONE | SLAB_POISON | SLAB_STORE_USER)
>> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
>> index b2df375..1d499ea 100644
>> --- a/net/core/skbuff.c
>> +++ b/net/core/skbuff.c
>> @@ -3316,15 +3316,15 @@ done:
>> void __init skb_init(void)
>> {
>> skbuff_head_cache = kmem_cache_create("skbuff_head_cache",
>> - sizeof(struct sk_buff),
>> - 0,
>> - SLAB_HWCACHE_ALIGN|SLAB_PANIC,
>> - NULL);
>> + sizeof(struct sk_buff),
>> + 0,
>> + SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_NO_SANITIZE,
>> + NULL);
>> skbuff_fclone_cache = kmem_cache_create("skbuff_fclone_cache",
>> - sizeof(struct sk_buff_fclones),
>> - 0,
>> - SLAB_HWCACHE_ALIGN|SLAB_PANIC,
>> - NULL);
>> + sizeof(struct sk_buff_fclones),
>> + 0,
>> + SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_NO_SANITIZE,
>> + NULL);
>> }
>>
>> /**
>> --
>> 2.5.0
>>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web