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

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, 24 Aug 2021 19:22:18 -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 Wed, Aug 18, 2021 at 5:16 PM Borislav Petkov <bp@...en8.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