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: <eebc971a-dc5f-6ae6-c5f7-d303e56212b2@kernel.org>
Date:   Wed, 19 May 2021 16:29:35 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     Len Brown <lenb@...nel.org>, Thomas Gleixner <tglx@...utronix.de>
Cc:     Borislav Petkov <bp@...en8.de>, Willy Tarreau <w@....eu>,
        Florian Weimer <fweimer@...hat.com>,
        "Bae, Chang Seok" <chang.seok.bae@...el.com>,
        Dave Hansen <dave.hansen@...el.com>, X86 ML <x86@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>, linux-abi@...r.kernel.org,
        "libc-alpha@...rceware.org" <libc-alpha@...rceware.org>,
        Rich Felker <dalias@...c.org>, Kyle Huey <me@...ehuey.com>,
        Keno Fischer <keno@...iacomputing.com>
Subject: Re: Candidate Linux ABI for Intel AMX and hypothetical new related
 features

On 5/18/21 1:39 PM, Len Brown wrote:
> On Sat, May 8, 2021 at 5:45 AM Thomas Gleixner <tglx@...utronix.de> wrote:
> 
>> Where is #6 which describes the signal interaction?
> 
> #6 Per the current ABI, Linux gives signal handlers access to all of
> the hardware architectural state.
> 
> #6a Signal Stack is on User Stack
> 
> The architectural state is pushed on the user stack in uncompressed
> XSTATE format.
> 
> It is established that there exists application code that counts on
> this opaque state being complete so that it can do a user-space
> XRESTORE instead of a sigreturn(2).

Is this established?

Note that the specific case of a user program doing XRSTOR will work
just fine if we omit the allocation of non-in-use states from the
buffer, at least by my reading of the pseudocode.  The case that would
break is if user code then assumes that it can XSAVE back to the same
buffer.

> (My opinion is that not breaking
> that legacy code is a requirement, and I'm actually shocked this view
> is not unanimous)
> 
It's pretty unanimous.  But the legacy code that's broken has to
actually exist for this to apply.