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: <6c9c4597-a1af-4cbb-9dc8-424999d04793@www.fastmail.com>
Date:   Fri, 21 May 2021 13:07:52 -0700
From:   "Andy Lutomirski" <luto@...nel.org>
To:     "Thomas Gleixner" <tglx@...utronix.de>,
        "Florian Weimer" <fweimer@...hat.com>,
        "Dave Hansen" <dave.hansen@...el.com>
Cc:     "Dave Hansen via Libc-alpha" <libc-alpha@...rceware.org>,
        "Len Brown" <lenb@...nel.org>, "Rich Felker" <dalias@...c.org>,
        "Linux API" <linux-api@...r.kernel.org>,
        "Bae, Chang Seok" <chang.seok.bae@...el.com>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
        "Kyle Huey" <me@...ehuey.com>, "Borislav Petkov" <bp@...en8.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:10 PM, Thomas Gleixner wrote:
> On Fri, May 21 2021 at 09:31, Andy Lutomirski wrote:
> > arch_prctl(SET_XSTATE_INIT_ON_FIRST_USE, TILE_STUFF);?
> >
> > As long as this is allowed to fail, I don’t have a huge problem with
> > it.
> 
> I'm fine with that. It's still controlled by the OS and can return
> -EPERM.
> 
> If allowed then the application would also accept to be insta killed if
> that #NM allocation fails. Any bug report vs. that will be ignored.
> 
> > I think several things here are regrettable:
> >
> > 1. Legacy XSTATE code might assume that XCR0 is a constant.
> >
> > 2. Intel virt really doesn’t like us context switching XCR0, although
> > we might say that this is Intel’s fault and therefore Intel’s
> > problem. AMD hardware doesn’t appear to have this issue.
> >
> > 3. AMX bring tangled up in XSTATE is unfortunate.  The whole XSTATE
> > mechanism is less than amazing.
> >
> > IMO the best we can make of this whole situation is to make XCR0
> > dynamic, but the legacy compatibility issues are potentially
> > problematic.
> 
> Why? The bit can be enabled and #NM catches the violation of the ABI
> contract if the application did not request usage. No XCR0 fiddling on
> context switch required.
> 
> Thanks,
> 
>         tglx
> 
> 
> 

XFD does nothing about signals.  It also doesn’t help give applications a non-Linux-specific way to ask if AMX is available. The SDM says that one can read XCR0.  Sure, we can use it, but cross platform libraries seem likely to get it wrong.