On Wed, Dec 16, 2015 at 10:46 AM, Laura Abbott <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.

For upstreaming, we'll need a comparison between PAX_MEMORY_SANITIZE and the existing upstream things that overlap with it.

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 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?

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.

Thanks for working on this!

-Kees

Kees Cook
Chrome OS & Brillo Security