[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <567317E1.9050000@labbott.name>
Date: Thu, 17 Dec 2015 12:15:29 -0800
From: Laura Abbott <laura@...bott.name>
To: kernel-hardening@...ts.openwall.com
Subject: Re: Looking at PAX_MEMORY_SANITIZE
On 12/16/15 5:29 PM, Kees Cook wrote:
>
>
> On Wed, Dec 16, 2015 at 10:46 AM, Laura Abbott <laura@...bott.name <mailto:laura@...bott.name>> wrote:
>
> Hi,
>
> I started looking at PAX_MEMORY_SANITIZE for bringing into the kernel. I thought
> I would give a short update on what I've found so far for feedback and the like.
>
> PAX_MEMORY_SANITIZE is used for clearing both the SL*B allocators and the
> buddy allocator on free. Arguably, similar behavior exists already as debug
> features (SLUB_DEBUG poison, DEBUG_PAGEALLOC for some arches). Given what we're
> already finding with features like DEBUG_RODATA though, the sanitization really
> needs to be a separate Kconfig not tied to debugging. I debated trying to make
> those Kconfigs non-debug but they were tied to other features besides poison/
> sanitization.
>
>
> Sounds great! As for CONFIGs, one thing that was request was that we ultimately put all
>the hardening configs under a common Kconfig heading so they can be found easily. I view
>this as a late-stage tweak, and mostly we just need to worry about functionality first.
>
Sure. I was going to put the Kconfig somewhere I think is reasonable and see if
there are better suggestions.
> For upstreaming, we'll need a comparison between PAX_MEMORY_SANITIZE and the existing
>upstream things that overlap with it.
What kind of comparison are you thinking of? Just a list of what differs featurewise
or performance characteristics or something else?
>
> I've been focusing my efforts on the SL*B allocators. As it stands, the feature
> is fairly self-contained and mostly just needs some refactoring. I plan on
> expanding the command line option to give a bit more control on where the
> sanitization happens. The sanitization currently always happens on the fast path
> so my thought was to allow the option of sanitizing only on the slow path.
>
>
> Seems like it should happen on all paths to be a true always-on hardening feature, though?
The existing PaX code has an option to skip caches marked with SLAB_NO_SANITIZE.
I was thinking skipping on the fast path might be a similar expansion of that.
There is still a boot commandline option for full sanitization.
I'm going to profile before I send anything out to get a better idea if this
option would make a difference.
>
> The existing PaX code also disables cache merging. It's not clear if this is an
> additional security measure but the sanitization as written doesn't work with
> merging. For at least the first version, slab merging will be disabled when
> sanitization is enabled on a slab.
>
>
> That seems fine to me. These trade-offs are to be expected.
>
> Another thing we should call attention to are past bugs and exploits or exploit methods
> that would have been hampered or eliminated with this feature. e.g. How does this
>play with classic use-after-free, etc?
Good point. I'll find some examples.
>
> I'm hoping to post actual patches before I go on vacation for the holidays next
> week. Early feedback is appreciated as well if I missed anything.
>
>
> Fantastic! I look forward to testing it. Which gets to a third piece: adding an lkdtm
> test for the feature so it's easy to test the kernel's reaction to the state that is
>being protected.
I'll look into this as well.
Thanks,
Laura
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.
