On 1/5/16 4:09 PM, Kees Cook wrote:
On Tue, Dec 22, 2015 at 12:04 PM, Laura Abbott <laura@xxxxxxxxxxxx> wrote:
On 12/22/15 8:08 AM, Christoph Lameter wrote:
On Mon, 21 Dec 2015, Laura Abbott wrote:
The biggest change from PAX_MEMORY_SANTIIZE is that this feature
sanitizes
the SL[AOU]B allocators only. My plan is to work on the buddy allocator
santization after this series gets picked up. A side effect of this is
that allocations which go directly to the buddy allocator (i.e. large
allocations) aren't sanitized. I'd like feedback about whether it's worth
it to add sanitization on that path directly or just use the page
allocator sanitization when that comes in.
This looks great! I love the added lkdtm tests, too. Very cool.
I am not sure what the point of this patchset is. We have a similar effect
to sanitization already in the allocators through two mechanisms:
1. Slab poisoning
2. Allocation with GFP_ZERO
I do not think we need a third one. You could accomplish your goals much
easier without this code churn by either
1. Improve the existing poisoning mechanism. Ensure that there are no
gaps. Security sensitive kernel slab caches can then be created with
the POISONING flag set. Maybe add a Kconfig flag that enables
POISONING for each cache? What was the issue when you tried using
posining for sanitization?
The existing poisoning does work for sanitization but it's still a debug
feature. It seemed more appropriate to keep debug features and non-debug
features separate hence the separate option and configuration.
What stuff is intertwined in the existing poisoning that makes it
incompatible/orthogonal?
It's not the poisoning per se that's incompatible, it's how the poisoning is
set up. At least for slub, the current poisoning is part of SLUB_DEBUG which
enables other consistency checks on the allocator. Trying to pull out just
the poisoning for use when SLUB_DEBUG isn't on would result in roughly what
would be here anyway. I looked at trying to reuse some of the existing poisoning
and came to the conclusion it was less intrusive to the allocator to keep it
separate.
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>