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: <CAJvTdKkwSxUzyUjTMKUUpaFRz49AoxtxTDYAPfAFPQtRmA_87w@mail.gmail.com>
Date:   Wed, 30 Jun 2021 11:20:47 -0400
From:   Len Brown <lenb@...nel.org>
To:     Arjan van de Ven <arjan@...ux.intel.com>
Cc:     "Enrico Weigelt, metux IT consult" <lkml@...ux.net>,
        Florian Weimer <fweimer@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Dave Hansen via Libc-alpha <libc-alpha@...rceware.org>,
        Dave Hansen <dave.hansen@...el.com>,
        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>,
        Willy Tarreau <w@....eu>
Subject: Re: Candidate Linux ABI for Intel AMX and hypothetical new related features

The latest proposal for kernel AMX support (updated today) is here:

https://lore.kernel.org/lkml/20210630060226.24652-1-chang.seok.bae@intel.com/

The main challenge for AMX is not context switch performance.
Hardware recognizes INIT state (the common case) and skips that data
transfer when it is not needed.

The main challenge for AMX is compatibility.  Specifically, user
signal stack growth.
The legacy ABI is that we put an uncompacted XSTATE image on the signal stack.
In the default stack case, this isn't a problem, but when a user
allocates an alternative signal stack,
the 8K of XSTATE growth that AMX can exceed what the user allocated.
The new system call tells the kernel that the application can handle it.
(it can do this by not using altsigstack, or by using the updated
stack size advertised
 by glibc 2.34 and later, or some other means)