Re: [kernel-hardening] [RFC] mm: enable sanitizing via CONFIG

[Daniel Micay <danielmicay@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]

On Fri, 2017-02-24 at 16:32 -0800, Kees Cook wrote:
> This enables page and slab poisoning by default under
> CONFIG_MEMORY_SANITIZE.
> Based on work by Kaiwan N Billimoria.
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> This is more what I had in mind. This is based on the latest patch,
> but
> handles slab and slub. I tested slub with lkdtm's READ_AFTER_FREE and
> READ_BUDDY_AFTER_FREE which both trip the poisoning tests.
> 
> While doing this, I noticed one major issue with slub/slab poisoning:
> it performs poisoning both on alloc and free, which is a rather large
> performance hit, so the next step is likely to find a way to split the
> poisoning into alloc and free halves so that CONFIG_MEMORY_SANITIZE
> poisoning will only happen on the free.

It also still fills with a value that will make pointers point to
userspace, right? Rather than a better value or zeroing (and relying on
mmap_min_addr, although that's pretty small and easy to index past).

It also verifies the poisoning is still there, which can be wanted but
is more expensive. It increases allocations by the size of a pointer
which PaX doesn't do anymore, and there's the whole losing the fast path
which seems to mean losing CPU caching too since it's just hitting the
global stuff. The debug infrastructure could also be a risk, that would
not be present in normal builds up to this point.

I would like to be able to use upstream features but I think case it
seems that anyone not willing to unnecessarily lose performance and
security properties will need to keep carrying ~15 line of code out of
tree or using the PaX features.

Is there a path to doing it properly from here? I really don't see the
point in it being upstreaming if it's such a hack. It's frustrating...

Not to mention that real allocator hardening like not having inline free
lists and being able to reliably detect double-free would be nice. Maybe
there should just be a security-oriented slab allocator, freeing it from
needing to avoid stepping on other people's toes. It just needs to pick
a performance target and then the design can shift away from the current
one within that target over time. *shrug*

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 866 bytes --]