linux-kernel - Re: Candidate Linux ABI for Intel AMX and hypothetical new related features

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]

Message-ID: <CAJvTdKkw-ZUHmH3_ctmpXV0gLjR2GnmgDCRxaUZ+kZN9Ti7X5g@mail.gmail.com>
Date:   Fri, 21 May 2021 12:26:25 -0400
From:   Len Brown <lenb@...nel.org>
To:     Florian Weimer <fweimer@...hat.com>
Cc:     Dave Hansen <dave.hansen@...el.com>,
        Dave Hansen via Libc-alpha <libc-alpha@...rceware.org>,
        Rich Felker <dalias@...c.org>,
        Linux API <linux-api@...r.kernel.org>,
        "Bae, Chang Seok" <chang.seok.bae@...el.com>,
        X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
        Kyle Huey <me@...ehuey.com>, Borislav Petkov <bp@...en8.de>,
        Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Keno Fischer <keno@...iacomputing.com>,
        Arjan van de Ven <arjan@...ux.intel.com>,
        Willy Tarreau <w@....eu>
Subject: Re: Candidate Linux ABI for Intel AMX and hypothetical new related features

On Fri, May 21, 2021 at 12:19 PM Florian Weimer <fweimer@...hat.com> wrote:

> I see.  So essentially the hardware wants to offer transparent
> initialize-on-use, but Linux does not seem to want to implement it this
> way.

That is a reasonable summary.

> Is there still a chance to bring the hardware and Linux into alignment?

The hardware was done some time ago, so this is a Linux decision.

The current trajectory is that for user space to use TMUL it must
1. query CPUID to see if the instructions exist
2. query xgetbv(XCR0) to see if the OS supports the state
3. Tell Linux that this thread wants to use the state.

The original proposal required just #1 and #2.
It is clear that Linux can not support that, and so #3 is being added.

Of course, if #2 is false, then Linux will return failure for #3,
so technically you could skip that check and just make this new syscall.
Probably user-space will still need to query CPUID for the instructions,
since there will be a many-to-one mapping of instructions to state.

Len Brown, Intel Open Source Technology Center