linux-kernel - Re: [RFC PATCH v2 2/3] x86/mm/tlb: Defer PTI flushes

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: <CALCETrX91RqYsetbTjfrsMHH8LhTW=YMPuatHuo0bdTJeejP=Q@mail.gmail.com>
Date:   Tue, 27 Aug 2019 16:13:02 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     Nadav Amit <namit@...are.com>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>
Subject: Re: [RFC PATCH v2 2/3] x86/mm/tlb: Defer PTI flushes

On Fri, Aug 23, 2019 at 11:13 PM Nadav Amit <namit@...are.com> wrote:
>
> INVPCID is considerably slower than INVLPG of a single PTE. Using it to
> flush the user page-tables when PTI is enabled therefore introduces
> significant overhead.
>
> Instead, unless page-tables are released, it is possible to defer the
> flushing of the user page-tables until the time the code returns to
> userspace. These page tables are not in use, so deferring them is not a
> security hazard.

I agree and, in fact, I argued against ever using INVPCID in the
original PTI code.

However, I don't see what freeing page tables has to do with this.  If
the CPU can actually do speculative page walks based on the contents
of non-current-PCID TLB entries, then we have major problems, since we
don't actively flush the TLB for non-running mms at all.

I suppose that, if we free a page table, then we can't activate the
PCID by writing to CR3 before flushing things.  But we can still defer
the flush and just set the flush bit when we write to CR3.

--Andy