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: <87y2cdzmsd.ffs@nanos.tec.linutronix.de>
Date:   Mon, 17 May 2021 12:18:10 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Florian Weimer <fweimer@...hat.com>
Cc:     Len Brown <lenb@...nel.org>, Borislav Petkov <bp@...en8.de>,
        Willy Tarreau <w@....eu>, Andy Lutomirski <luto@...nel.org>,
        "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-api@...r.kernel.org,
        "libc-alpha\@sourceware.org" <libc-alpha@...rceware.org>,
        Rich Felker <dalias@...c.org>, Kyle Huey <me@...ehuey.com>,
        Keno Fischer <keno@...iacomputing.com>,
        Arjan van de Ven <arjan@...ux.intel.com>
Subject: Re: Candidate Linux ABI for Intel AMX and hypothetical new related features

On Mon, May 17 2021 at 11:56, Florian Weimer wrote:
> * Thomas Gleixner:
>
>> Having a proper interface (syscall, prctl) which user space can use to
>> ask for permission and allocation of the necessary buffer(s) is clearly
>> avoiding the downsides and provides the necessary mechanisms for proper
>> control and failure handling.
>>
>> It's not the end of the world if something which wants to utilize this
>> has do issue a syscall during detection. It does not matter whether
>> that's a library or just the application code itself.
>>
>> That's a one off operation and every involved entity can cache the
>> result in TLS.
>
> I'm not sure if it's a good idea to have each AMX consumer to set up its
> own TLS cache.  How expensive is checking XCR0 via XGETBV instead on the
> AMX path?  Then AMX can be enabled on the thread via a system call. 

Right, did not think about that.

> It also allows disabling of AMX.

That needs reference counting, but yes it's possible.

> It would also need an AT_HWCAP2 feature flag telling user space that AMX
> support is available after that system call (switching on AMX to check
> whether AMX paths should enabled later seems potentially wasteful if the
> AMX paths are never taken after all).

Either that or just have:

       prctl(PR_QUERY_XSTATE_FEATURES,....
       prctl(PR_ENABLE_XSTATE_FEATURES,....
       prctl(PR_DISABLE_XSTATE_FEATURES,....

Thanks,

        tglx