linux-kernel - Re: [PATCH] x86/amd: Work around Erratum 1386

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] [day] [month] [year] [list]

Message-ID: <ada3e064-fdb3-afc5-8c0c-bff54a591189@intel.com>
Date:   Tue, 14 Mar 2023 09:01:18 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Andrew Cooper <andrew.cooper3@...rix.com>,
        Borislav Petkov <bp@...en8.de>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Tavis Ormandy <taviso@...il.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>,
        Alexander Monakov <amonakov@...ras.ru>
Subject: Re: [PATCH] x86/amd: Work around Erratum 1386 - XSAVES malfunction on
 context switch

On 3/7/23 12:01, Andrew Cooper wrote:
> On 07/03/2023 6:56 pm, Borislav Petkov wrote:
>> On Tue, Mar 07, 2023 at 06:22:01PM +0000, Andrew Cooper wrote:
>>> Well yes - more and more reports of impacted systems.
>>>
>>> Having the full list of affected models is great and all, but how is it
>>> going to change this patch as a workaround ?
>> We don't have to clear the feature flag on those systems which have
>> a fix.
> Sure, but why is that helpful?
> 
> XSAVES and XSAVEC are functionally identical on Zen1/2 because these
> CPUs don't advertise any supervisor XSAVE states.

On Intel at least, XSAVES uses the modified optimization and XSAVEC does
not.  I'm not sure if you include this in your definition of
"functionally identical", but it is one of those little XSAVE
architecture oddities that's bitten me a time or two.

The AMD docs don't talk about the modified optimization verbatim, but I
think this nugget is alluding to the same behavior:

> 4. XRSTOR loads an internal state value XRSTOR_INFO that can be used to further optimize a
> subsequent XSAVEOPT or XSAVES. This reflects the current privilege level and virtualization
> mode as well as the save area's base address and XCOMP_BV field.