[RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO)
luto at kernel.org
Thu Apr 18 04:41:33 UTC 2019
On Wed, Apr 17, 2019 at 5:00 PM Linus Torvalds
<torvalds at linux-foundation.org> wrote:
> On Wed, Apr 17, 2019 at 4:42 PM Thomas Gleixner <tglx at linutronix.de> wrote:
> > On Wed, 17 Apr 2019, Linus Torvalds wrote:
> > > With SMEP, user space pages are always NX.
> > We talk past each other. The user space page in the ring3 valid virtual
> > address space (non negative) is of course protected by SMEP.
> > The attack utilizes the kernel linear mapping of the physical
> > memory. I.e. user space address 0x43210 has a kernel equivalent at
> > 0xfxxxxxxxxxx. So if the attack manages to trick the kernel to that valid
> > kernel address and that is mapped X --> game over. SMEP does not help
> > there.
> Oh, agreed.
> But that would simply be a kernel bug. We should only map kernel pages
> executable when we have kernel code in them, and we should certainly
> not allow those pages to be mapped writably in user space.
> That kind of "executable in kernel, writable in user" would be a
> horrendous and major bug.
> So i think it's a non-issue.
> > From the top of my head I'd say this is a non issue as those kernel address
> > space mappings _should_ be NX, but we got bitten by _should_ in the past:)
> I do agree that bugs can happen, obviously, and we might have missed something.
> But in the context of XPFO, I would argue (*very* strongly) that the
> likelihood of the above kind of bug is absolutely *miniscule* compared
> to the likelihood that we'd have something wrong in the software
> implementation of XPFO.
> So if the argument is "we might have bugs in software", then I think
> that's an argument _against_ XPFO rather than for it.
I don't think this type of NX goof was ever the argument for XPFO.
The main argument I've heard is that a malicious user program writes a
ROP payload into user memory (regular anonymous user memory) and then
gets the kernel to erroneously set RSP (*not* RIP) to point there.
I find this argument fairly weak for a couple reasons. First, if
we're worried about this, let's do in-kernel CFI, not XPFO, to
mitigate it. Second, I don't see why the exact same attack can't be
done using, say, page cache, and unless I'm missing something, XPFO
doesn't protect page cache. Or network buffers, or pipe buffers, etc.
More information about the Linux-security-module-archive