linux-kernel - Re: [tip:x86/pti] x86/cpu/AMD: Use LFENCE_RDTSC instead of MFENCE

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: <alpine.DEB.2.20.1801082155380.2253@nanos>
Date:   Mon, 8 Jan 2018 21:57:19 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Tom Lendacky <thomas.lendacky@....com>
cc:     Andrew Cooper <andrew.cooper3@...rix.com>, bp@...en8.de,
        dwmw@...zon.co.uk, gregkh@...ux-foundation.org, pjt@...gle.com,
        mingo@...nel.org, linux-kernel@...r.kernel.org, hpa@...or.com,
        tim.c.chen@...ux.intel.com, torvalds@...ux-foundation.org,
        peterz@...radead.org, dave.hansen@...el.com,
        linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/pti] x86/cpu/AMD: Use LFENCE_RDTSC instead of
 MFENCE_RDTSC

On Mon, 8 Jan 2018, Tom Lendacky wrote:
> So now I'm also concerned about setting the retpoline method and using
> LFENCE as the speculation barrier.  If we go back to the original
> statement:
> 
>   - the hypervisor did not set the LFENCE to serializing on the host
>   - the hypervisor does not allow writing MSR_AMD64_DE_CFG
> 
> It looks like I'll need to attempt to write MSR_AMD64_DE_CFG and then read
> it back checking for whether MSR_F10H_DECFG_LFENCE_SERIALIZE has been set.
> If the MSR can be read and the bit is set, then I can set RETPOLINE_AMD
> (once those patches go in) and LFENCE_RDTSC.  Otherwise, set (only)
> MFENCE_RDTSC.  This also means we need to use MFENCE as the speculation
> barrier instead of LFENCE in this situation (another alternative added to
> the __nospec_barrier() implementation).
> 
> Does that sound right?  Or does the "cannot prove that you run on bare
> metal" mess this all up?

I think that covers it. If the hypervisor would be trapping the read and
then lying on the bit being set while it's not, that's really nothing you
should care about at all.

Thanks,

	tglx