linux-kernel - RE: Thoughts of AMX KVM support based on latest kernel

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:   Wed, 17 Nov 2021 10:15:32 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     Paolo Bonzini <pbonzini@...hat.com>,
        "Nakajima, Jun" <jun.nakajima@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>
CC:     "Liu, Jing2" <jing2.liu@...el.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "Arjan van de Ven" <arjan@...ux.intel.com>,
        Jing Liu <jing2.liu@...ux.intel.com>,
        "seanjc@...gle.com" <seanjc@...gle.com>,
        "Cooper, Andrew" <andrew.cooper3@...rix.com>,
        "Bae, Chang Seok" <chang.seok.bae@...el.com>
Subject: RE: Thoughts of AMX KVM support based on latest kernel

> From: Paolo Bonzini <pbonzini@...hat.com>
> Sent: Wednesday, November 17, 2021 3:31 PM
> 
> On 11/17/21 05:52, Nakajima, Jun wrote:
> > If a (creative) guest wants to set XFD[AMX] = 1 for fun while keeping
> > AMX state alive without saving the AXM state, it may lose the state
> > after VM exit/entry.
> 
> I think this should not happen, unless you also document that other
> random events (hypothetically, it could be some other core using AMX?)
> can cause the loss of XTILEDATA if XFD[AMX]=1.  Virtualization should
> not be special, I'd prefer that the guest has the same behavior as bare
> metal in this respect.
> 

The state may be lost with the simple version suggested by Thomas,
because with XFD[AMX]=1 the AMX state won't be stored to 
guest_fpstate when the vcpu thread is preempted and then get lost
when restored. To emulate the hardware behavior this will need
additional trick to force XFD[AMX]=0 if XGETBV(1) is true (ignoring 
guest XFD) in fpu_update_guest_xfd_state(void). It also implies 
that the actual guest XFD needs to be saved in a place before forcing 
XFD[AMX] to 0 and recovered (after interrupt is disabled) before 
entering the guest.

We are not sure whether such trick is worthwhile, since a sane
guest shouldn't set XFD[AMX]=1 before storing the AMX state. This
is why we want to seek SDM change to mark out that the software
should not assume XTILEDATA is still valid when XFD[AMX]=1. 

Then KVM can make a simple assumption that once XFD[AMX]=1
it implies the guest doesn't care about the AMX state. Then the
simple version from Thomas can work perfectly.

Thanks
Kevin