linux-kernel - Rewording of Setting IA32_XFD[18] (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, 8 Dec 2021 00:50:38 +0000
From:   "Nakajima, Jun" <jun.nakajima@...el.com>
To:     Thomas Gleixner <tglx@...utronix.de>
CC:     Paolo Bonzini <pbonzini@...hat.com>,
        "Tian, Kevin" <kevin.tian@...el.com>,
        "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: Rewording of Setting IA32_XFD[18] (Re: Thoughts of AMX KVM support
 based on latest kernel)



> On Nov 19, 2021, at 7:41 AM, Nakajima, Jun <jun.nakajima@...el.com> wrote:
> 
> Hi Thomas,
> 
>> On Nov 19, 2021, at 2:13 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
>> 
>> Jun,
>> 
>> On Thu, Nov 18 2021 at 23:17, Jun Nakajima wrote:
>>> On Nov 17, 2021, at 4:53 AM, Paolo Bonzini <pbonzini@...hat.com> wrote:
>>>> 
>>>> It doesn't have to happen in current processors, but it should be
>>>> architecturally valid behavior to clear the processor's state as soon
>>>> as a bit in XFD is set to 1.
>>> 
>>> 3.3 RECOMMENDATIONS FOR SYSTEM SOFTWARE
>>> 
>>> System software may disable use of Intel AMX by clearing XCR0[18:17],
>>> by clearing CR4.OSXSAVE, or by setting IA32_XFD[18]. It is recommended
>>> that system software initialize AMX state (e.g., by executing
>>> TILERELEASE) before doing so. This is because maintaining AMX state in
>>> a non-initialized state may have negative power and performance
>>> implications.
>>> 
>>> System software should not use XFD to implement a “lazy restore”
>>> approach to management of the XTILEDATA state component. This approach
>>> will not operate correctly for a variety of reasons. One is that the
>>> LDTILECFG and TILERELEASE instructions initialize XTILEDATA and do not
>>> cause an #NM exception. Another is that an execution of XSAVE by a
>>> user thread will save XTILEDATA as initialized instead of the data
>>> expected by the user thread.
>> 
>> Can this pretty please be reworded so that it says:
>> 
>> When setting IA32_XFD[18] the AMX register state is not guaranteed to
>> be preserved. The resulting register state depends on the
>> implementation.
>> 
>> Also it's a real design disaster that component 17 cannot be fenced off
>> via XFD. That's really inconsistent and leads exactly to this half
>> defined state.
>> 
> 
> I’ll work with the H/W team on those (i.e. rewording and the component 17 issue).
> 

The following is a possible documentation update that may convey the rewording you requested.
Does this (the last sentence, “In addition, “) work for you?


3.3 RECOMMENDATIONS FOR SYSTEM SOFTWARE

System software may disable use of Intel AMX by clearing XCR0[18:17], by clearing CR4.OSXSAVE, or by setting IA32_XFD[18]. System software should initialize AMX state (e.g., by executing TILERELEASE) when doing so because maintaining AMX state in a non-initialized state may have negative power and performance implications. In addition, software should not rely on the state of the tile data after setting IA32_XFD[18]; software should always reload or reinitialize the tile data after clearing IA32_XFD[18].

Thanks,
--- 
Jun