On 1/5/16 4:29 PM, Kees Cook wrote:
On Tue, Dec 22, 2015 at 11:13 AM, Laura Abbott <laura@xxxxxxxxxxxx> wrote:
On 12/22/15 10:19 AM, Dave Hansen wrote:
On 12/22/2015 10:08 AM, Christoph Lameter wrote:
On Tue, 22 Dec 2015, Dave Hansen wrote:
Why would you use zeros? The point is just to clear the information
right?
The regular poisoning does that.
It then allows you to avoid the zeroing at allocation time.
Well much of the code is expecting a zeroed object from the allocator and
its zeroed at that time. Zeroing makes the object cache hot which is an
important performance aspect.
Yes, modifying this behavior has a performance impact. It absolutely
needs to be evaluated, and I wouldn't want to speculate too much on how
good or bad any of the choices are.
Just to reiterate, I think we have 3 real choices here:
1. Zero at alloc, only when __GFP_ZERO
(behavior today)
2. Poison at free, also Zero at alloc (when __GFP_ZERO)
(this patch's proposed behavior, also what current poisoning does,
doubles writes)
3. Zero at free, *don't* Zero at alloc (when __GFP_ZERO)
(what I'm suggesting, possibly less perf impact vs. #2)
poisoning with non-zero memory makes it easier to determine that the error
came from accessing the sanitized memory vs. some other case. I don't think
the feature would be as strong if the memory was only zeroed vs. some other
data value.
I would tend to agree. If there are significant perf improvements for
"3" above, that should be easy to add on later as another choice.
I was looking at the sanitization for the buddy allocator that exists in
grsecurity and that does option #3 (zero at free, skip __GFP_ZERO).
I'm going to look into adding that as an option for the slab allocator
and see what the performance numbers show.
Thanks,
Laura
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>