linux-kernel - Re: x86: AMD Zen2 ymm registers rolling back

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: <2eccf8e2-4aa3-dcda-064d-ca39d2295548@citrix.com>
Date:   Wed, 1 Mar 2023 00:23:01 +0000
From:   Andrew Cooper <andrew.cooper3@...rix.com>
To:     Alexander Monakov <amonakov@...ras.ru>,
        Borislav Petkov <bp@...en8.de>
Cc:     Tavis Ormandy <taviso@...il.com>, linux-kernel@...r.kernel.org,
        x86@...nel.org
Subject: Re: x86: AMD Zen2 ymm registers rolling back

On 28/02/2023 9:16 pm, Alexander Monakov wrote:
> On Tue, 28 Feb 2023, Borislav Petkov wrote:
>> On Tue, Feb 28, 2023 at 10:29:23PM +0300, Alexander Monakov wrote:
>>> That I can reproduce the bug even with the latest BIOS,
>> Can you reproduce if you boot with
>>
>> clearcpuid=xsaves
>>
>> ?
> No, with this option it is not reproducible.

Ok.

Given that AMD do appear to have screwed up here, and the exploit does
reliably work on modern versions of Linux and up-to-date firmware, the
next course of action is to clobber XSAVES by default.

So we need a table for all Zen2 parts of ucode revisions below which we
force hide XSAVES as the erratum workaround.

That, or we skip the table and just hide XSAVES unconditionally on all
Fam17/18h CPUs...  The Zen1/2 uarches have no supervisor states to
manage (AFAICT - the first supervisor states are CET in Zen3 I think),
and Linux already knows how to use XSAVEC (from virt usecases) which is
equivalent given no supervisor states.

Thoughts?

~Andrew