Re: [PATCH v9 12/26] x86/fpu/xstate: Use feature disable (XFD) to protect dynamic user state

[Borislav Petkov]

On Tue, Aug 24, 2021 at 07:22:18PM -0400, Len Brown wrote:
> We are forced to complicate their life for AMX (and subsequent features)
> because of the legacy Linux signal ABI.

No, we need to design this interface properly because you folks went and
put this AMX thing in xstates. Where it doesn't belong at all.

> We require that new apps invoke a system call to tell us that they
> are not indeed a legacy program, but that they are a program that
> understands if they use an alt-sig-stack that it must be big enough to
> handle whatever current hardware requires.

Yes, because of the reason I gave above. If no additional 8K fat wasn't
an xstate, we wouldn't be having this conversation.

> The secondary motivation for the system call is the desire to give the
> kernel a hook so that it can refuse to give permission for some apps
> to use AMX, should the need arise.

Yes.

> > prctl(GET_FEATURES_WITH_KERNEL_ASSISTANCE);
>
> The problem is that it adds zero value over the currently used xgetbv(XCR0).
> As it adds no value, programmers will not use it.

Bullsh*t.

First of all, it is a new interface we're introducing and if it is
there from the get-go along with examples how to use it and proper
documentation, people will.

Secondly, from a previous email of mine: "What if this modus operandi of
features userspace can use with kernel assistance but need an explicit
request and are off otherwise, gets extended beyond XSAVE-managed
features?"

In that case you can xgetbv() all you want but the new fat feature is
not even in XCR0. So *then* you *have* to introduce a new prctl() to
query supported features. And right then and there you wish you would've
done that from the very beginning!

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette