Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 17 Dec 2015 12:27:30 -0800
From: Kees Cook <>
To: "" <>
Subject: Re: Looking at PAX_MEMORY_SANITIZE

On Thu, Dec 17, 2015 at 12:15 PM, Laura Abbott <> wrote:
> On 12/16/15 5:29 PM, Kees Cook wrote:
>> On Wed, Dec 16, 2015 at 10:46 AM, Laura Abbott <
>> <>> 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?

Yeah, I meant features, but I'm sure we'll need to produce performance
details too.

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



Kees Cook
Chrome OS & Brillo Security

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.