Date: Wed, 9 Dec 2015 16:41:04 -0800 From: Kees Cook <keescook@...omium.org> To: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com> Subject: Re: Self Introduction On Wed, Dec 9, 2015 at 4:26 PM, David Brown <david.brown@...aro.org> wrote: > On Wed, Dec 09, 2015 at 04:14:20PM -0800, Kees Cook wrote: > >> Great! It might be valuable to read through this mailing lists's >> threads over the last month. We discuss a few of the features and some >> work has been started. > > > Reading through stuff now. Looks like the list got quite a boost in > November. > >>> I suspect part of the challenge is going to be clearly describing the >>> various features along with specific examples of already-discovered >>> exploits that the feature would have mitigated. >> >> >> Yes indeed. :) That's why I've arranged the wiki the way I did: >> classes and methods first, with potential solutions listed under them. >> We want to start with problem descriptions and work from actual >> exploits when possible. >> >> This is why the recent x86 VDSO attack was very timely: it >> demonstrates cleanly why we want __ro_after_init (née __read_only) in >> upstream. (As well as the constification plugin.) > > > Which also seems like this will be quite useful on ARM as well. Do > you know any efforts to do this? I've not seen any yet. If you get it written, I can include it in my __ro_after_init series on the next revision. >>> Most recently, I backported ARM PAN support to the Linaro stable >>> kernels (3.18 and 4.1). >> >> >> Excellent! Yes, I did a port to Brillo's v4.1 tree as well. It's very >> nice to have a UDEREF-like feature on arm. It's too bad this doesn't >> exist for Intel yet, but I'm hoping they'll step up. >> >> For 3.18, is this the right place to be looking? >> >> https://git.linaro.org/gitweb?p=kernel/linux-linaro-stable.git;a=shortlog;h=refs/heads/linux-linaro-lsk-v3.18 > > > It will be once it gets through testing. > https://git.linaro.org/kernel/linux-linaro-stable.git/shortlog/refs/heads/v3.18/topic/PAN > to peek before then. There's also > https://git.linaro.org/kernel/linux-linaro-stable.git/shortlog/refs/heads/v4.1/topic/PAN > for the 4.1 tree. Oh! I see now. You meant hardware PAN support. Yes, also good to get in for the arm64 devices. I meant the CONFIG_CPU_SW_DOMAIN_PAN support. I've backported that from 4.3 to 4.1 since then all arm devices would gain PAN-like support too. > Should I CC kernel-hardening when sending patches for the Linaro > stable kernels? Probably not for stable backports. I think upstream development things probably should be, and we can certainly discuss stuff that looks like it'd be good to backport, but I wouldn't want to bore people with patch for old kernels. :) >> I'd love to see CONFIG_CPU_SW_DOMAIN_PAN into the AOSP 3.18 android kernel >> too. > > I'll put this on my list to investigate. Sadly, it looks like there > is a bit of a window of ARM CPUs where neither solution will work; > Basically the pre V8.1 64-bit. The LPAE support for PAN emulation exists in grsecurity, if someone wanted to look at how to extract it and add it to CONFIG_CPU_SW_DOMAIN_PAN (or similar). > In fact, I don't have any hardware yet that supports PAN. I've done > all of the testing in emulation. Heh, yeah, that's how the x86 SMAP stuff is too. ;) -Kees -- 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.