Re: [RFC][PATCH] mm/slub.c: Allow poisoning to use the fast path

2017-08-08 Thread Kees Cook
On Tue, Aug 8, 2017 at 8:01 AM, Christopher Lameter wrote: > > On Mon, 7 Aug 2017, Kees Cook wrote: >> >> To clarify, this is desirable to kill exploitation of >> exposure-after-free flaws and some classes of use-after-free flaws, >> since the contents will have be wiped out after

Re: [RFC][PATCH] mm/slub.c: Allow poisoning to use the fast path

2017-08-08 Thread Kees Cook
On Tue, Aug 8, 2017 at 8:01 AM, Christopher Lameter wrote: > > On Mon, 7 Aug 2017, Kees Cook wrote: >> >> To clarify, this is desirable to kill exploitation of >> exposure-after-free flaws and some classes of use-after-free flaws, >> since the contents will have be wiped out after a free.

Re: [RFC][PATCH] mm/slub.c: Allow poisoning to use the fast path

2017-08-08 Thread Christopher Lameter
On Mon, 7 Aug 2017, Kees Cook wrote: > > To clarify, this is desirable to kill exploitation of > exposure-after-free flaws and some classes of use-after-free flaws, > since the contents will have be wiped out after a free. (Verification > of poison is nice, but is expensive compared to the

Re: [RFC][PATCH] mm/slub.c: Allow poisoning to use the fast path

2017-08-08 Thread Christopher Lameter
On Mon, 7 Aug 2017, Kees Cook wrote: > > To clarify, this is desirable to kill exploitation of > exposure-after-free flaws and some classes of use-after-free flaws, > since the contents will have be wiped out after a free. (Verification > of poison is nice, but is expensive compared to the

Re: [RFC][PATCH] mm/slub.c: Allow poisoning to use the fast path

2017-08-07 Thread Kees Cook
On Mon, Aug 7, 2017 at 3:00 PM, Laura Abbott wrote: > On 08/07/2017 11:03 AM, Christopher Lameter wrote: >> On Mon, 7 Aug 2017, Laura Abbott wrote: >> Ok I see that the objects are initialized with poisoning and redzoning but I do not see that there is fastpath code

Re: [RFC][PATCH] mm/slub.c: Allow poisoning to use the fast path

2017-08-07 Thread Kees Cook
On Mon, Aug 7, 2017 at 3:00 PM, Laura Abbott wrote: > On 08/07/2017 11:03 AM, Christopher Lameter wrote: >> On Mon, 7 Aug 2017, Laura Abbott wrote: >> Ok I see that the objects are initialized with poisoning and redzoning but I do not see that there is fastpath code to actually check

Re: [RFC][PATCH] mm/slub.c: Allow poisoning to use the fast path

2017-08-07 Thread Laura Abbott
On 08/07/2017 11:03 AM, Christopher Lameter wrote: > On Mon, 7 Aug 2017, Laura Abbott wrote: > >>> Ok I see that the objects are initialized with poisoning and redzoning but >>> I do not see that there is fastpath code to actually check the values >>> before the object is reinitialized. Is that

Re: [RFC][PATCH] mm/slub.c: Allow poisoning to use the fast path

2017-08-07 Thread Laura Abbott
On 08/07/2017 11:03 AM, Christopher Lameter wrote: > On Mon, 7 Aug 2017, Laura Abbott wrote: > >>> Ok I see that the objects are initialized with poisoning and redzoning but >>> I do not see that there is fastpath code to actually check the values >>> before the object is reinitialized. Is that

Re: [RFC][PATCH] mm/slub.c: Allow poisoning to use the fast path

2017-08-07 Thread Christopher Lameter
On Mon, 7 Aug 2017, Laura Abbott wrote: > > Ok I see that the objects are initialized with poisoning and redzoning but > > I do not see that there is fastpath code to actually check the values > > before the object is reinitialized. Is that intentional or am > > I missing something? > > Yes,

Re: [RFC][PATCH] mm/slub.c: Allow poisoning to use the fast path

2017-08-07 Thread Christopher Lameter
On Mon, 7 Aug 2017, Laura Abbott wrote: > > Ok I see that the objects are initialized with poisoning and redzoning but > > I do not see that there is fastpath code to actually check the values > > before the object is reinitialized. Is that intentional or am > > I missing something? > > Yes,

Re: [RFC][PATCH] mm/slub.c: Allow poisoning to use the fast path

2017-08-07 Thread Laura Abbott
On 08/07/2017 07:37 AM, Christopher Lameter wrote: > On Fri, 4 Aug 2017, Laura Abbott wrote: > >> All slub debug features currently disable the fast path completely. >> Some features such as consistency checks require this to allow taking of >> locks. Poisoning and red zoning don't require this

Re: [RFC][PATCH] mm/slub.c: Allow poisoning to use the fast path

2017-08-07 Thread Laura Abbott
On 08/07/2017 07:37 AM, Christopher Lameter wrote: > On Fri, 4 Aug 2017, Laura Abbott wrote: > >> All slub debug features currently disable the fast path completely. >> Some features such as consistency checks require this to allow taking of >> locks. Poisoning and red zoning don't require this

Re: [RFC][PATCH] mm/slub.c: Allow poisoning to use the fast path

2017-08-07 Thread Christopher Lameter
On Fri, 4 Aug 2017, Laura Abbott wrote: > All slub debug features currently disable the fast path completely. > Some features such as consistency checks require this to allow taking of > locks. Poisoning and red zoning don't require this and can safely use > the per-cpu fast path. Introduce a

Re: [RFC][PATCH] mm/slub.c: Allow poisoning to use the fast path

2017-08-07 Thread Christopher Lameter
On Fri, 4 Aug 2017, Laura Abbott wrote: > All slub debug features currently disable the fast path completely. > Some features such as consistency checks require this to allow taking of > locks. Poisoning and red zoning don't require this and can safely use > the per-cpu fast path. Introduce a

[RFC][PATCH] mm/slub.c: Allow poisoning to use the fast path

2017-08-04 Thread Laura Abbott
All slub debug features currently disable the fast path completely. Some features such as consistency checks require this to allow taking of locks. Poisoning and red zoning don't require this and can safely use the per-cpu fast path. Introduce a Kconfig to continue to use the fast path when 'fast'

[RFC][PATCH] mm/slub.c: Allow poisoning to use the fast path

2017-08-04 Thread Laura Abbott
All slub debug features currently disable the fast path completely. Some features such as consistency checks require this to allow taking of locks. Poisoning and red zoning don't require this and can safely use the per-cpu fast path. Introduce a Kconfig to continue to use the fast path when 'fast'