linux-kernel - RE: [RFC PATCH 22/22] x86/fpu/xstate: Introduce boot-parameters for control some state component 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, 13 Oct 2020 23:38:33 +0000
From:   "Brown, Len" <len.brown@...el.com>
To:     Andy Lutomirski <luto@...nel.org>,
        "Bae, Chang Seok" <chang.seok.bae@...el.com>
CC:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...e.de>,
        X86 ML <x86@...nel.org>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        "Liu, Jing2" <jing2.liu@...el.com>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>
Subject: RE: [RFC PATCH 22/22] x86/fpu/xstate: Introduce boot-parameters for
 control some state component support

> From: Andy Lutomirski <luto@...nel.org> 

> On Thu, Oct 1, 2020 at 1:43 PM Chang S. Bae <chang.seok.bae@...el.com> wrote:

> > "xstate.disable=0x6000" will disable AMX on a system that has AMX 
> > compiled into XFEATURE_MASK_USER_SUPPORTED.

> Can we please use words for this?  Perhaps:

> xstate.disable=amx,zmm

Yes, I think it is reasonable to add support for keywords for the features that
are both supported by the hardware and known by the kernel.

However, we need to continue to support numerical state-component bitmap format.
Otherwise, it would not be possible to coerce a legacy kernel (eg. a distro kernel)
to enable a feature on a new machine until it has been updated to know that keyword.

> and maybe add a list in /proc/cpuinfo or somewhere in /proc or /sys that shows all the currently enabled xsave states.

Agreed, if we invent keywords, the list of supported+known keywords should be available on the system.

I do not advocate /proc/cpuinfo -- which is already an out of control parsing mess.

We could add the keywords to dmesg, since we already print the supported XSAVE BV:

[    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating  point registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'

Or maybe a sysfs attribute or a modparam that simply lists them all.

We wouldn't be able to dynamically  _write_ to that attribute, since the cmdline is boot-time only.

> > "xstate.enable=0x6000" will enable AMX on a system that does NOT have 
> > AMX compiled into XFEATURE_MASK_USER_SUPPORTED (assuming the kernel is 
> > new enough to support this feature).
>
> This sounds like it will be quite confusing to anyone reading the kernel code to discover that a feature that is not "SUPPORTED" is nonetheless enabled.

Right now, this cmdline will only allow a new kernel to enable/disable kernel support for AMX
on hardware that also supports AMX.  But we hope to re-use this XSTATE code -- unchanged --
for future features that require just this simple state management support from the kernel.

We anticipate a future hardware enumeration mechanism to identify such qualified features
to assist the kernel in deciding whether to support a feature or not, by default.
The kernel can use the combination of its build-time config with advice from this boot-time
enumeration to decide if it wants to enable a particular feature or not.
And at the end, a user is empowered to override that default using this cmdline.

Thanks,
-Len