[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1488011791.1141.1.camel@gmail.com>
Date: Sat, 25 Feb 2017 03:36:31 -0500
From: Daniel Micay <danielmicay@...il.com>
To: Kees Cook <keescook@...omium.org>, Kaiwan N Billimoria
<kaiwan@...wantech.com>
Cc: kernel-hardening@...ts.openwall.com
Subject: Re: [RFC] mm: enable sanitizing via CONFIG
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@...omium.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*
Download attachment "signature.asc" of type "application/pgp-signature" (867 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
