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 th= ought
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 w= e're
already finding with features like DEBUG_RODATA though, the sanitization re= ally
needs to be a separate Kconfig not tied to debugging. I debated trying to m= ake
those Kconfigs non-debug but they were tied to other features besides poiso= n/
sanitization.

Sounds great! As for CONF= IGs, one thing that was request was that we ultimately put all the hardenin= g configs under a common Kconfig heading so they can be found easily. I vie= w this as a late-stage tweak, and mostly we just need to worry about functi= onality first.

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

=C2=A0

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<= br> 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.<= br>

Seems like it should happen on all path= s to be a true always-on hardening feature, though?

=C2=A0

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> The existing PaX code also disables cache merging. It's not clear if th= is is an
additional security measure but the sanitization as written doesn't wor= k 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 fe= ature. 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 holid= ays next
week. Early feedback is appreciated as well if I missed anything.

Fantastic! I look forward to testing it. Which g= ets 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

--001a1140f36a66097f05270df397--