Date: Wed, 1 Mar 2017 11:16:12 -0800 From: Kees Cook <keescook@...omium.org> To: Daniel Micay <danielmicay@...il.com> Cc: Kaiwan N Billimoria <kaiwan@...wantech.com>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com> Subject: Re: [RFC] mm: enable sanitizing via CONFIG On Sat, Feb 25, 2017 at 12:36 AM, Daniel Micay <danielmicay@...il.com> wrote: > On Fri, 2017-02-24 at 16:32 -0800, Kees Cook wrote: >> This enables page and slab poisoning by default under >> CONFIG_MEMORY_SANITIZE. >> Based on work by Kaiwan N Billimoria. >> >> Signed-off-by: Kees Cook <keescook@...omium.org> >> --- >> This is more what I had in mind. This is based on the latest patch, >> but >> handles slab and slub. I tested slub with lkdtm's READ_AFTER_FREE and >> READ_BUDDY_AFTER_FREE which both trip the poisoning tests. >> >> While doing this, I noticed one major issue with slub/slab poisoning: >> it performs poisoning both on alloc and free, which is a rather large >> performance hit, so the next step is likely to find a way to split the >> poisoning into alloc and free halves so that CONFIG_MEMORY_SANITIZE >> poisoning will only happen on the free. > > It also still fills with a value that will make pointers point to > userspace, right? Rather than a better value or zeroing (and relying on > mmap_min_addr, although that's pretty small and easy to index past). Correct. We have to get there in pieces, though I continue to think it would still be easier to make the sanitization feature separate from debugging. In PaX, the poison value on x86_64 is 0xfe (to make addresses aim into the noncanonical range), otherwise 0xff (to point at the top of memory). > It also verifies the poisoning is still there, which can be wanted but > is more expensive. It increases allocations by the size of a pointer > which PaX doesn't do anymore, and there's the whole losing the fast path > which seems to mean losing CPU caching too since it's just hitting the > global stuff. The debug infrastructure could also be a risk, that would > not be present in normal builds up to this point. Gathering the reasons against this being part of the debug path would be a nice thing to collect; it might be convincing to the allocator maintainers. > I would like to be able to use upstream features but I think case it > seems that anyone not willing to unnecessarily lose performance and > security properties will need to keep carrying ~15 line of code out of > tree or using the PaX features. The simple form (without the SLAB_NO_SANITIZE) is alarmingly small. :) > Is there a path to doing it properly from here? I really don't see the > point in it being upstreaming if it's such a hack. It's frustrating... > > Not to mention that real allocator hardening like not having inline free > lists and being able to reliably detect double-free would be nice. Maybe > there should just be a security-oriented slab allocator, freeing it from > needing to avoid stepping on other people's toes. It just needs to pick > a performance target and then the design can shift away from the current > one within that target over time. *shrug* I'd love to see someone step up and create this for upstream. I think it'd make a lot of sense instead of trying to shoe-horn things into SLUB... -Kees -- Kees Cook Pixel 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.