linux-kernel - Re: [GIT PULL] x86/mm changes for v4.21

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: <22E08A6D-5180-42F1-B94B-6B6DB832F953@amacapital.net>
Date:   Thu, 7 Feb 2019 12:24:18 -0800
From:   Andy Lutomirski <luto@...capital.net>
To:     "Luck, Tony" <tony.luck@...el.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Ingo Molnar <mingo@...nel.org>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Andy Lutomirski <luto@...nel.org>,
        Borislav Petkov <bp@...en8.de>,
        Thomas Gleixner <tglx@...utronix.de>,
        Rik van Riel <riel@...riel.com>
Subject: Re: [GIT PULL] x86/mm changes for v4.21



> On Feb 7, 2019, at 10:46 AM, Luck, Tony <tony.luck@...el.com> wrote:
> 
>> On Thu, Feb 07, 2019 at 10:07:28AM -0800, Andy Lutomirski wrote:
>> Joining this thread late...
>> 
>> This is all IMO rather crazy.  How about we fiddle with CR0 to turn off
>> the cache, then fiddle with page tables, then turn caching on?  Or, heck,
>> see if there’s some chicken bit we can set to improve the situation
>> while we’re in the MCE handler.
> 
>> Also, since I don’t really want
>> to dig into the code to answer this, how exactly do we do a broadcast TLB
>> flush from MCE context?  We’re super-duper-atomic, and locks might be
>> held on various CPUs.  Shouldn’t we be telling the cpa code to skip
>> the flush and then just have the MCE code do a full flush manually?
>> The MCE code has already taken over all CPUs on non-LMCE systems.
> 
> MCE code doesn't do this while still in MCE context. You helped
> restructure this code so the recovery bits happen after we call
> 
>    ist_begin_non_atomic(regs);
> 
> on just the CPU that hit the error (in the broadcast case we've
> let the other out of MCE jail by this point).
> 
> So there is a small window where we know the broken page is still
> mapped WB in the kernel 1:1 map. But we just live dangerously for
> a few more microseconds until we can fix the map.

Hmm.

How bad would it be to set CR0.CD while fiddling with the page tables rather than masking the address?

> 
>> Or, better yet, get Intel to fix the hardware. A failed speculative
>> access while already in MCE context should just be ignored.
> 
> Good idea.
> 
> -Tony