linux-kernel - RE: [patch 0/6] x86/fpu: Preparatory changes for guest AMX support

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:   Tue, 14 Dec 2021 07:54:05 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     "Liu, Jing2" <jing2.liu@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>
CC:     "Zhong, Yang" <yang.zhong@...el.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "Christopherson,, Sean" <seanjc@...gle.com>,
        "Nakajima, Jun" <jun.nakajima@...el.com>
Subject: RE: [patch 0/6] x86/fpu: Preparatory changes for guest AMX support

> From: Liu, Jing2 <jing2.liu@...ux.intel.com>
> Sent: Tuesday, December 14, 2021 2:52 PM
> 
> On 12/14/2021 10:50 AM, Thomas Gleixner wrote:
> >       If MSR write emulation is disabled because the buffer size is
> >       sufficient for all use cases, i.e.:
> >
> >       		guest_fpu::xfeatures == guest_fpu::perm
> >
> The buffer size can be sufficient once one of the features is requested
> since
> kernel fpu realloc full size (permitted). And I think we don't want to
> disable
> interception until all the features are detected e.g., one by one.
> 
> Thus it can be guest_fpu::xfeatures != guest_fpu::perm.
> 

There are two options to handle multiple xfd features.

a) a conservative approach as Thomas suggested, i.e. don't disable emulation
   until all the features in guest_fpu::perm are requested by the guest. This
   definitely has poor performance if the guest only wants to use a subset of
   perm features. But functionally p.o.v it just works.

   Given we only have one xfeature today, let's just use this simple check which
   has ZERO negative impact.

b) an optimized approach by dynamically enabling/disabling emulation. e.g.
   we can disable emulation after the 1st xfd feature is enabled and then 
   reenable it in #NM vmexit handler when XFD_ERR includes a bit which is 
   not in guest_fpu::xfeatures, sort of like:

	--xfd trapped, perm has two xfd features--
	(G) access xfd_feature1;
	(H) trap #NM (XFD_ERR = xfd_feature1) and inject #NM;
	(G) WRMSR(IA32_XFD, (-1ULL) & ~xfd_feature1);
	(H) reallocate fpstate and disable write emulation for XFD;

	--xfd passed through--
	(G) do something...
	(G) access xfd_feature2;
	(H) trap #NM (XFD_ERR = xfd_feature2), enable emulation, inject #NM;

	--xfd trapped--
	(G) WRMSR(IA32_XFD, (-1ULL) & ~(xfd_feature1 | xfd_feature2));
	(H) reallocate fpstate and disable write emulation for XFD;

	--xfd passed through--
	(G) do something...

Thanks
Kevin