Re: [kernel-hardening] Looking at PAX_MEMORY_SANITIZE

[Kees Cook <keescook@chromium.org>]

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

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

[-- Attachment #2: Type: text/html, Size: 3629 bytes --]