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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 22 Apr 2019 13:30:41 -0600
From:   Khalid Aziz <>
To:     Kees Cook <>, Andy Lutomirski <>,
        Linus Torvalds <>
Cc:     Thomas Gleixner <>,
        Nadav Amit <>,
        Ingo Molnar <>,
        Juerg Haefliger <>,
        Tycho Andersen <>,
        Julian Stecklina <>,
        Konrad Rzeszutek Wilk <>,
        Juerg Haefliger <>,, chris hyser <>,
        Tyler Hicks <>,
        David Woodhouse <>,
        Andrew Cooper <>,
        Jon Masters <>,
        Boris Ostrovsky <>,
        iommu <>,
        X86 ML <>,
        "" <>,
        "open list:DOCUMENTATION" <>,
        Linux List Kernel Mailing <>,
        Linux-MM <>,
        LSM List <>,
        Khalid Aziz <>,
        Andrew Morton <>,
        Peter Zijlstra <>,
        Dave Hansen <>, Borislav Petkov <>,
        "H. Peter Anvin" <>,
        Arjan van de Ven <>,
        Greg Kroah-Hartman <>
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 <> 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.


Powered by blists - more mailing lists