linux-kernel - Re: [RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

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]

Date:   Tue, 10 Oct 2017 10:22:57 +0200
From:   Markus Trippelsdorf <markus@...ppelsdorf.de>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org,
        Borislav Petkov <bp@...en8.de>,
        Adam Borowski <kilobyte@...band.pl>,
        Brian Gerst <brgerst@...il.com>
Subject: Re: [RFC PATCH] x86/mm: Flush more aggressively in lazy TLB mode

On 2017.10.09 at 09:50 -0700, Andy Lutomirski wrote:
> Since commit 94b1b03b519b, x86's lazy TLB mode has been all the way
> lazy: when running a kernel thread (including the idle thread), the
> kernel keeps using the last user mm's page tables without attempting
> to maintain user TLB coherence at all.  From a pure semantic
> perspective, this is fine -- kernel threads won't attempt to access
> user pages, so having stale TLB entries doesn't matter.
> 
> Unfortunately, I forgot about a subtlety.  By skipping TLB flushes,
> we also allow any paging-structure caches that may exist on the CPU
> to become incoherent.  This means that we can have a
> paging-structure cache entry that references a freed page table, and
> the CPU is within its rights to do a speculative page walk starting
> at the freed page table.
> 
> I can imagine this causing two different problems:
> 
>  - A speculative page walk starting from a bogus page table could read
>    IO addresses.  I haven't seen any reports of this causing problems.
> 
>  - A speculative page walk that involves a bogus page table can install
>    garbage in the TLB.  Such garbage would always be at a user VA, but
>    some AMD CPUs have logic that triggers a machine check when it notices
>    these bogus entries.  I've seen a couple reports of this.
> 
> Reinstate TLB coherence in lazy mode.  With this patch applied, we
> do it in one of two ways.  If we have PCID, we simply switch back to
> init_mm's page tables when we enter a kernel thread -- this seems to
> be quite cheap except for the cost of serializing the CPU.  If we
> don't have PCID, then we set a flag and switch to init_mm the first
> time we would otherwise need to flush the TLB.

Your patch fixes the problem. (I've stressed my AMD machine in various
ways since yesterday. No issues thus far.) 
Thanks.

-- 
Markus