lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <302e3d5b-d2fd-3c25-335b-466ba83035c5@oracle.com> Date: Mon, 22 Apr 2019 13:30:41 -0600 From: Khalid Aziz <khalid.aziz@...cle.com> To: Kees Cook <keescook@...gle.com>, Andy Lutomirski <luto@...nel.org>, Linus Torvalds <torvalds@...ux-foundation.org> Cc: Thomas Gleixner <tglx@...utronix.de>, Nadav Amit <nadav.amit@...il.com>, Ingo Molnar <mingo@...nel.org>, Juerg Haefliger <juergh@...il.com>, Tycho Andersen <tycho@...ho.ws>, Julian Stecklina <jsteckli@...zon.de>, Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>, Juerg Haefliger <juerg.haefliger@...onical.com>, deepa.srinivasan@...cle.com, chris hyser <chris.hyser@...cle.com>, Tyler Hicks <tyhicks@...onical.com>, David Woodhouse <dwmw@...zon.co.uk>, Andrew Cooper <andrew.cooper3@...rix.com>, Jon Masters <jcm@...hat.com>, Boris Ostrovsky <boris.ostrovsky@...cle.com>, iommu <iommu@...ts.linux-foundation.org>, X86 ML <x86@...nel.org>, "linux-alpha@...r.kernel.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>, 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 4/18/19 8:34 AM, Khalid Aziz wrote: > On 4/17/19 11:41 PM, Kees Cook wrote: >> On Wed, Apr 17, 2019 at 11:41 PM Andy Lutomirski <luto@...nel.org> wrote: >>> 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. >> >> Well, more than just ROP. Any of the various attack primitives. The NX >> stuff is about moving RIP: SMEP-bypassing. But there is still basic >> SMAP-bypassing for putting a malicious structure in userspace and >> having the kernel access it via the linear mapping, etc. >> >>> 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 >> >> CFI is getting much closer. Getting the kernel happy under Clang, LTO, >> and CFI is under active development. (It's functional for arm64 >> already, and pieces have been getting upstreamed.) >> > > CFI theoretically offers protection with fairly low overhead. I have not > played much with CFI in clang. I agree with Linus that probability of > bugs in XPFO implementation itself is a cause of concern. If CFI in > Clang can provide us the same level of protection as XPFO does, I > wouldn't want to push for an expensive change like XPFO. > > If Clang/CFI can't get us there for extended period of time, does it > make sense to continue to poke at XPFO? Any feedback on continued effort on XPFO? If it makes sense to have XPFO available as a solution for ret2dir issue in case Clang/CFI does not work out, I will continue to refine it. -- Khalid
Powered by blists - more mailing lists