Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Fri, Jul 7, 2017 at 10:06 AM, Christoph Lameter wrote: > On Fri, 7 Jul 2017, Kees Cook wrote: > >> If we also added a >0 offset, that would make things even less >> deterministic. Though I wonder if it would make the performance impact >> higher. The XOR patch right now is very

Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Fri, Jul 7, 2017 at 10:06 AM, Christoph Lameter wrote: > On Fri, 7 Jul 2017, Kees Cook wrote: > >> If we also added a >0 offset, that would make things even less >> deterministic. Though I wonder if it would make the performance impact >> higher. The XOR patch right now is very light. > >

Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Fri, 7 Jul 2017, Kees Cook wrote: > If we also added a >0 offset, that would make things even less > deterministic. Though I wonder if it would make the performance impact > higher. The XOR patch right now is very light. There would be barely any performance impact if you keep the offset

Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Fri, 7 Jul 2017, Kees Cook wrote: > If we also added a >0 offset, that would make things even less > deterministic. Though I wonder if it would make the performance impact > higher. The XOR patch right now is very light. There would be barely any performance impact if you keep the offset

Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Fri, Jul 7, 2017 at 6:50 AM, Christoph Lameter wrote: > On Thu, 6 Jul 2017, Kees Cook wrote: > >> Right. This is about blocking the escalation of attack capability. For >> slab object overflow flaws, there are mainly two exploitation methods: >> adjacent allocated object

Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Fri, Jul 7, 2017 at 6:50 AM, Christoph Lameter wrote: > On Thu, 6 Jul 2017, Kees Cook wrote: > >> Right. This is about blocking the escalation of attack capability. For >> slab object overflow flaws, there are mainly two exploitation methods: >> adjacent allocated object overwrite and adjacent

Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Thu, 6 Jul 2017, Kees Cook wrote: > Right. This is about blocking the escalation of attack capability. For > slab object overflow flaws, there are mainly two exploitation methods: > adjacent allocated object overwrite and adjacent freed object > overwrite (i.e. a freelist pointer overwrite).

Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Thu, 6 Jul 2017, Kees Cook wrote: > Right. This is about blocking the escalation of attack capability. For > slab object overflow flaws, there are mainly two exploitation methods: > adjacent allocated object overwrite and adjacent freed object > overwrite (i.e. a freelist pointer overwrite).

Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Thu, Jul 6, 2017 at 10:53 AM, Rik van Riel wrote: > On Thu, 2017-07-06 at 10:55 -0500, Christoph Lameter wrote: >> On Thu, 6 Jul 2017, Kees Cook wrote: >> > That requires a series of arbitrary reads. This is protecting >> > against >> > attacks that use an adjacent slab object

Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Thu, Jul 6, 2017 at 10:53 AM, Rik van Riel wrote: > On Thu, 2017-07-06 at 10:55 -0500, Christoph Lameter wrote: >> On Thu, 6 Jul 2017, Kees Cook wrote: >> > That requires a series of arbitrary reads. This is protecting >> > against >> > attacks that use an adjacent slab object write overflow

Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Thu, 2017-07-06 at 10:55 -0500, Christoph Lameter wrote: > On Thu, 6 Jul 2017, Kees Cook wrote: > > > On Thu, Jul 6, 2017 at 6:43 AM, Christoph Lameter > > wrote: > > > On Wed, 5 Jul 2017, Kees Cook wrote: > > > > > > > @@ -3536,6 +3565,9 @@ static int kmem_cache_open(struct

Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Thu, 2017-07-06 at 10:55 -0500, Christoph Lameter wrote: > On Thu, 6 Jul 2017, Kees Cook wrote: > > > On Thu, Jul 6, 2017 at 6:43 AM, Christoph Lameter > > wrote: > > > On Wed, 5 Jul 2017, Kees Cook wrote: > > > > > > > @@ -3536,6 +3565,9 @@ static int kmem_cache_open(struct > > > >

Re: [kernel-hardening] Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Thu, 2017-07-06 at 10:55 -0500, Christoph Lameter wrote: > On Thu, 6 Jul 2017, Kees Cook wrote: > > > On Thu, Jul 6, 2017 at 6:43 AM, Christoph Lameter > > wrote: > > > On Wed, 5 Jul 2017, Kees Cook wrote: > > > > > > > @@ -3536,6 +3565,9 @@ static int kmem_cache_open(struct

Re: [kernel-hardening] Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Thu, 2017-07-06 at 10:55 -0500, Christoph Lameter wrote: > On Thu, 6 Jul 2017, Kees Cook wrote: > > > On Thu, Jul 6, 2017 at 6:43 AM, Christoph Lameter > > wrote: > > > On Wed, 5 Jul 2017, Kees Cook wrote: > > > > > > > @@ -3536,6 +3565,9 @@ static int kmem_cache_open(struct > > > >

Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Thu, 6 Jul 2017, Kees Cook wrote: > On Thu, Jul 6, 2017 at 6:43 AM, Christoph Lameter wrote: > > On Wed, 5 Jul 2017, Kees Cook wrote: > > > >> @@ -3536,6 +3565,9 @@ static int kmem_cache_open(struct kmem_cache *s, > >> unsigned long flags) > >> { > >> s->flags =

Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Thu, 6 Jul 2017, Kees Cook wrote: > On Thu, Jul 6, 2017 at 6:43 AM, Christoph Lameter wrote: > > On Wed, 5 Jul 2017, Kees Cook wrote: > > > >> @@ -3536,6 +3565,9 @@ static int kmem_cache_open(struct kmem_cache *s, > >> unsigned long flags) > >> { > >> s->flags =

Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Thu, Jul 6, 2017 at 6:43 AM, Christoph Lameter wrote: > On Wed, 5 Jul 2017, Kees Cook wrote: > >> @@ -3536,6 +3565,9 @@ static int kmem_cache_open(struct kmem_cache *s, >> unsigned long flags) >> { >> s->flags = kmem_cache_flags(s->size, flags, s->name, s->ctor); >>

Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Thu, Jul 6, 2017 at 6:43 AM, Christoph Lameter wrote: > On Wed, 5 Jul 2017, Kees Cook wrote: > >> @@ -3536,6 +3565,9 @@ static int kmem_cache_open(struct kmem_cache *s, >> unsigned long flags) >> { >> s->flags = kmem_cache_flags(s->size, flags, s->name, s->ctor); >> s->reserved =

Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Wed, 5 Jul 2017, Kees Cook wrote: > @@ -3536,6 +3565,9 @@ static int kmem_cache_open(struct kmem_cache *s, > unsigned long flags) > { > s->flags = kmem_cache_flags(s->size, flags, s->name, s->ctor); > s->reserved = 0; > +#ifdef CONFIG_SLAB_FREELIST_HARDENED > + s->random =

Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Wed, 5 Jul 2017, Kees Cook wrote: > @@ -3536,6 +3565,9 @@ static int kmem_cache_open(struct kmem_cache *s, > unsigned long flags) > { > s->flags = kmem_cache_flags(s->size, flags, s->name, s->ctor); > s->reserved = 0; > +#ifdef CONFIG_SLAB_FREELIST_HARDENED > + s->random =

[PATCH v3] mm: Add SLUB free list pointer obfuscation

This SLUB free list pointer obfuscation code is modified from Brad Spengler/PaX Team's code in the last public patch of grsecurity/PaX based on my understanding of the code. Changes or omissions from the original code are mine and don't reflect the original grsecurity/PaX code. This adds a

[PATCH v3] mm: Add SLUB free list pointer obfuscation

This SLUB free list pointer obfuscation code is modified from Brad Spengler/PaX Team's code in the last public patch of grsecurity/PaX based on my understanding of the code. Changes or omissions from the original code are mine and don't reflect the original grsecurity/PaX code. This adds a