On Fri, Sep 30, 2016 at 9:41 AM, Mark Rutland <mark.rutl...@arm.com> wrote: > On Fri, Sep 30, 2016 at 09:25:45AM -0700, Kees Cook wrote: >> On Fri, Sep 30, 2016 at 8:58 AM, Mark Rutland <mark.rutl...@arm.com> wrote: > >> > Would it be worth verifying that all kernel mappings are UXN, too? >> > >> > ARMv8 allows execute-only mappings, and a !UXN mapping could result in an >> > info >> > leak (e.g. pointers in MOVZ+MOVK sequences), or potential asynchronous >> > issues >> > (e.g. user instruction fetches accessing read-destructive device >> > registers). >> > All kernel mappings *should* be UXN. >> >> I love this idea, but based on what came up with hardened usercopy, >> there are a lot of readers of kernel memory still. I think the >> expectations around UXN need to be clarified so we can reason about >> things like perf that want to read the kernel text. > > The UXN (User eXecute Never) bit only controls whether userspace can execute a > page, not whether the kernel can read it. The RW permissions come from the AP > bits regardless.
Ah! Sorry, I misunderstood. Yeah, UXN checking makes sense there then. :) > We already try to ensure that all kernel memory is UXN by construction, so > this > would just be a sanity check, as with the rest of the W^X checks. > > The MOVZ+MOVK case above is where a sequence of 16-bit immediate MOVs are used > to encode a pointer. If a kernel mapping lacked UXN, userspace could execute > it > (unprivileged), and extract the pointer generated into a GPR. > > Having kernel exec-only memory is a different story entirely, though I agree > it's something to look into. Yeah, this'll need to get sorted out for x86 too. -Kees -- Kees Cook Nexus Security