linux-kernel - Re: [RFC PATCH v7 00/16] Add support for eXclusive Page Frame Ownership

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALCETrVWjdo6C53eFz8Gc99q4HFsGpwf4kDXR5OG8E96t-gSLw@mail.gmail.com>
Date:   Thu, 10 Jan 2019 16:44:36 -0800
From:   Andy Lutomirski <luto@...nel.org>
To:     Kees Cook <keescook@...omium.org>
Cc:     Khalid Aziz <khalid.aziz@...cle.com>,
        Andy Lutomirski <luto@...nel.org>,
        Dave Hansen <dave.hansen@...el.com>,
        Ingo Molnar <mingo@...nel.org>,
        Juerg Haefliger <juergh@...il.com>,
        Tycho Andersen <tycho@...ho.ws>, jsteckli@...zon.de,
        Andi Kleen <ak@...ux.intel.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        liran.alon@...cle.com,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        deepa.srinivasan@...cle.com, chris hyser <chris.hyser@...cle.com>,
        Tyler Hicks <tyhicks@...onical.com>,
        "Woodhouse, David" <dwmw@...zon.co.uk>,
        Andrew Cooper <andrew.cooper3@...rix.com>,
        Jon Masters <jcm@...hat.com>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        kanth.ghatraju@...cle.com,
        Joao Martins <joao.m.martins@...cle.com>,
        Jim Mattson <jmattson@...gle.com>, pradeep.vincent@...cle.com,
        John Haxby <john.haxby@...cle.com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Christoph Hellwig <hch@....de>, steven.sistare@...cle.com,
        Kernel Hardening <kernel-hardening@...ts.openwall.com>,
        Linux-MM <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC PATCH v7 00/16] Add support for eXclusive Page Frame Ownership

On Thu, Jan 10, 2019 at 3:07 PM Kees Cook <keescook@...omium.org> wrote:
>
> On Thu, Jan 10, 2019 at 1:10 PM Khalid Aziz <khalid.aziz@...cle.com> wrote:
> > I implemented a solution to reduce performance penalty and
> > that has had large impact. When XPFO code flushes stale TLB entries,
> > it does so for all CPUs on the system which may include CPUs that
> > may not have any matching TLB entries or may never be scheduled to
> > run the userspace task causing TLB flush. Problem is made worse by
> > the fact that if number of entries being flushed exceeds
> > tlb_single_page_flush_ceiling, it results in a full TLB flush on
> > every CPU. A rogue process can launch a ret2dir attack only from a
> > CPU that has dual mapping for its pages in physmap in its TLB. We
> > can hence defer TLB flush on a CPU until a process that would have
> > caused a TLB flush is scheduled on that CPU. I have added a cpumask
> > to task_struct which is then used to post pending TLB flush on CPUs
> > other than the one a process is running on. This cpumask is checked
> > when a process migrates to a new CPU and TLB is flushed at that
> > time. I measured system time for parallel make with unmodified 4.20
> > kernel, 4.20 with XPFO patches before this optimization and then
> > again after applying this optimization. Here are the results:

I wasn't cc'd on the patch, so I don't know the exact details.

I'm assuming that "ret2dir" means that you corrupt the kernel into
using a direct-map page as its stack.  If so, then I don't see why the
task in whose context the attack is launched needs to be the same
process as the one that has the page mapped for user access.

My advice would be to attempt an entirely different optimization: try
to avoid putting pages *back* into the direct map when they're freed
until there is an actual need to use them for kernel purposes.

How are you handing page cache?  Presumably MAP_SHARED PROT_WRITE
pages are still in the direct map so that IO works.