Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210730145957.7927-1-chang.seok.bae@intel.com>
 <20210730145957.7927-13-chang.seok.bae@intel.com> <YR00U19168BGoRB9@zn.tnic>
 <3181031.RqgVF4sTRC@tjmaciei-mobl5> <YR1HYRRN0HMTxXrw@zn.tnic>
 <BCC327C2-CF9F-4910-B626-315E515E9A3A@intel.com> <YR14zq2LaExjhFR+@zn.tnic>
In-Reply-To: <YR14zq2LaExjhFR+@zn.tnic>
From:   Len Brown <lenb@kernel.org>
Date:   Tue, 24 Aug 2021 19:22:18 -0400
Message-ID: <CAJvTdKnhn8rOKUJ0VKvM08sFYkvmEsSWBsH2ynncxH9_z49bxA@mail.gmail.com>
Subject: Re: [PATCH v9 12/26] x86/fpu/xstate: Use feature disable (XFD) to
 protect dynamic user state
To:     Borislav Petkov <bp@alien8.de>
Cc:     "Bae, Chang Seok" <chang.seok.bae@intel.com>,
        "Macieira, Thiago" <thiago.macieira@intel.com>,
        "Lutomirski, Andy" <luto@kernel.org>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "mingo@kernel.org" <mingo@kernel.org>,
        "x86@kernel.org" <x86@kernel.org>,
        "Brown, Len" <len.brown@intel.com>,
        "Hansen, Dave" <dave.hansen@intel.com>,
        "Liu, Jing2" <jing2.liu@intel.com>,
        "Shankar, Ravi V" <ravi.v.shankar@intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Precedence: bulk

On Wed, Aug 18, 2021 at 5:16 PM Borislav Petkov <bp@alien8.de> wrote:
>
> On Wed, Aug 18, 2021 at 08:43:50PM +0000, Bae, Chang Seok wrote:
> > Maybe I’m missing something, but I wonder what’s the difference
> > from reading XCR0.
>
> Wny, because adding another prctl() is too damn hard?

Adding complexity is easy.  Removing it is the hard part. ;-)

Programmers today know what CPUID and xgetbv(XCR0) mean:
1. feature exists in the HW
2. OS has ability to handle state

This is true for all features.

We are forced to complicate their life for AMX (and subsequent features)
because of the legacy Linux signal ABI.
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.

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.

Programmers don't like this, but it nobody has figured out a more
programmer-friendly way
to meet these requirements.
And so if they want to use AMX on Linux, they *must* use this new SET syscall.
Since Linux enforces that they use it, they will use it if they want
AMX (or subsequent features).

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

Sure, if the hardware is re-designed, and Linux is re-designed, and XCR0
can then change at run-time during the lifetime of a program, we have additional
challenges.  (such as legacy code that doesn't expect XCR0 to change
at run-time).
I don't think that this additional system call even begins to address
that theoretical
new world.

But this discussion moot.  If it has no use, it will not get used.
--
Len Brown, Intel Open Source Technology Center