Re: [kernel-hardening] Looking at PAX_MEMORY_SANITIZE

[Laura Abbott <laura@labbott.name>]

On 12/16/15 5:29 PM, Kees Cook wrote:
>
>
> On Wed, Dec 16, 2015 at 10:46 AM, Laura Abbott <laura@labbott.name <mailto:laura@labbott.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