Message-ID: <CAJvTdKnXy9D=CWHhYEC=W8=+O=ebD9katC5uKXLYCoErAYMQvw@mail.gmail.com>
Date:   Thu, 16 Sep 2021 23:48:28 -0400
From:   Len Brown <lenb@...nel.org>
To:     Borislav Petkov <bp@...en8.de>
Cc:     "Bae, Chang Seok" <chang.seok.bae@...el.com>,
        "Macieira, Thiago" <thiago.macieira@...el.com>,
        "Lutomirski, Andy" <luto@...nel.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...nel.org" <mingo@...nel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "Brown, Len" <len.brown@...el.com>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        "Liu, Jing2" <jing2.liu@...el.com>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v9 12/26] x86/fpu/xstate: Use feature disable (XFD) to
 protect dynamic user state

On Mon, Aug 30, 2021 at 1:31 PM Borislav Petkov <bp@...en8.de> wrote:
>
> 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.

Years ago, somebody, other than you or I, decided to use uncompacted
XSTATE on the Linux signal stack.

Years ago, somebody else, also other than you or I, decided that AMX should
be implemented using XSTATE.

Today, we are all working together to deal with this collision, in as
graceful a manner as possible.  Yes?

> > 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.

While not as huge, AVX-512 has the  same XSTATE bloat issue as AMX --
including the demonstrated ability to overflow the signal stack and kill apps.

The silver lining is that due to the AMX enabling effort, we updated
the glibc ABI
to comprehend variable sigstacksize.  So glibc 2.34, which released Aug 1st,
comprehends whatever the current hardware supports.

> > 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.

[expletive deleted]

> 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.

The application people I talk to are not asking for more system calls.
They would prefer zero system calls (which was our initial proposal).

> 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!

Sorry, I don't recall seeing that previous note -- maybe it flew past
when I was out.

I have no problem with the quest to develop a universal ABI
to layer over or otherwise replace CPUID and XCR0 and allow kernel override etc.

My point is simply that I haven't seen a case where somebody wanting to use AMX
would need it, and so I don't think developing such an ABI should gate
AMX support.

thanks,
Len Brown, Intel Open Source Technology Center

Powered by blists - more mailing lists