[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1904180129000.3174@nanos.tec.linutronix.de>
Date: Thu, 18 Apr 2019 01:42:26 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Linus Torvalds <torvalds@...ux-foundation.org>
cc: Nadav Amit <nadav.amit@...il.com>, Ingo Molnar <mingo@...nel.org>,
Khalid Aziz <khalid.aziz@...cle.com>, juergh@...il.com,
Tycho Andersen <tycho@...ho.ws>, jsteckli@...zon.de,
keescook@...gle.com,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Juerg Haefliger <juerg.haefliger@...onical.com>,
deepa.srinivasan@...cle.com, chris.hyser@...cle.com,
tyhicks@...onical.com, David Woodhouse <dwmw@...zon.co.uk>,
Andrew Cooper <andrew.cooper3@...rix.com>, jcm@...hat.com,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
iommu <iommu@...ts.linux-foundation.org>,
X86 ML <x86@...nel.org>, linux-arm-kernel@...ts.infradead.org,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
Linux-MM <linux-mm@...ck.org>,
LSM List <linux-security-module@...r.kernel.org>,
Khalid Aziz <khalid@...ehiking.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Andy Lutomirski <luto@...nel.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Dave Hansen <dave@...1.net>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>,
Arjan van de Ven <arjan@...radead.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame
Ownership (XPFO)
On Wed, 17 Apr 2019, Linus Torvalds wrote:
> On Wed, Apr 17, 2019, 14:20 Thomas Gleixner <tglx@...utronix.de> wrote:
>
> >
> > It's not necessarily a W+X issue. The user space text is mapped in the
> > kernel as well and even if it is mapped RX then this can happen. So any
> > kernel mappings of user space text need to be mapped NX!
>
> 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.
>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:)
Thanks,
tglx
Powered by blists - more mailing lists