linux-kernel - Re: [RFC PATCH v2 11/12] x86/mm/tlb: Use async and inline messages for flushing

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: <90a891a2-6be4-bfa2-5de1-5e36d1bc0b48@intel.com>
Date:   Fri, 31 May 2019 14:06:11 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     Nadav Amit <namit@...are.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Borislav Petkov <bp@...en8.de>, Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>
Subject: Re: [RFC PATCH v2 11/12] x86/mm/tlb: Use async and inline messages
 for flushing

On 5/31/19 1:37 PM, Andy Lutomirski wrote:
>> Modulo bugs^Werrata...  No.  What actually happens is that a
>> try-to-set-dirty-bit page table walk acts just like a TLB miss.  The old
>> contents of the TLB are discarded and only the in-memory contents matter
>> for forward progress.  If Present=0 when the PTE is reached, you'll get
>> a normal Present=0 page fault.
> Wait, does that mean that you can do a lock cmpxchg or similar to
> clear the dirty and writable bits together and, if the dirty bit was
> clear, skip the TLB flush?

Yeah, in the case that you're going from R/W->R/O, you can be assured
that no writable TLB entries were established if D=0.

Is it totally safe against other things?  Hell if I know. :)

I'd want to go look very closely at software things like GUP-for-write
before we went and actually did this.  But I can't think of any hardware
reasons off the top of my head why it wouldn't work.

A quick perusal of the SDM didn't have any slam dunks do support doing
this.  It's a bit cagey about exactly what can be cached and when.  The
supporting reasoning might have escaped my quick scan, though.

> If so, nifty!  Modulo errata, of course. And I seem to remember some
> exceptions relating to CET shadow stack involving the dirty bit being
> set on not-present pages.

Yeah: "no processor that supports CET will ever set the dirty flag in a
paging-structure entry in which the R/W flag is 0"

> https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf

Which probably means that the things we were saying above are
technically only architectural on CET-enabled processors.  I think the
behavior is actually much more widespread than that, though.