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

> > On Fri, Nov 20, 2020 at 12:03 AM Andy Lutomirski <luto@...nel.org> wrote:

> We may want to taint the kernel if one of these flags is used

I agree with Andy.
I can imagine a distro would want to see the taint bit set if a user
overrides the default that they ship and support.

Chang,
Please taint when the enable flag is used -- Thanks!

> because,
> frankly, Intel’s track record is poor. Suppose we get a new feature
> with PKRU-like semantics -- switching it blindly using
> XSAVE(C,S,OPT,whatever) would simply incorrect.

A valid concern.
To mitigate, there is a new CPUID bit on the way to tell us explicitly
which features are simple (require just XSAVE), versus which
features are not simple and require more complex support.n t
When that bit is locked down, we will add that sanity check here.

> And XFD itself has
> problems — supposedly it’s difficult or impossible to virtualize. It
> wouldn’t utterly shock me if Intel were to drop IA32_XFD_ERR and
> replace it with a new mechanism that’s less janky.
>
> So this whole thing makes me quite nervous.
>
> (I'm not a virtualization expert, but AIUI IA32_XFD_ERR has some
> issues.  If it's too late to fix those issues, Intel could probably
> get away with completely dropping IA32_XFD_ERR from the spec -- OSes
> can handle AMX just fine without it.  Then the next XFD-able feature
> could introduce a new improved way of reporting which feature
> triggered #NM.)

I don't follow the XFD concern.

There are a couple of cases.

If the hypervisor isn't aware of XFD, it neither uses it, or shows it
to the guests.

If the hypervisor is aware of XFD and supports TMUL, it allocates its
own context
switch buffers at boot time, and does not use the XFD optimization to
save space inside the hypervisor.  It can expose XFD to the guests,
(and context switch it when guests switch on/off physical CPUs)

The guest sees two cases, either XFD exists or it doesn't, just like
on real hardware.

thanks,
Len Brown, Intel Open Source Technology Center