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] [day] [month] [year] [list]

Date:   Wed, 30 Jun 2021 17:25:12 +0200
From:   "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
To:     Arjan van de Ven <arjan@...ux.intel.com>,
        Florian Weimer <fweimer@...hat.com>
Cc:     Len Brown <lenb@...nel.org>, 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

On 30.06.21 15:55, Arjan van de Ven wrote:

>> * this feature needs to be initialized first, before it can be used
>> * on first use (when not initialized yet), it traps into the kernel
>> * we don't want to always initialize it at boot
>>
>> Correct ?
> 
> not really, the init is PER PROCESS

IIRC there had been some discussion here whether it should be done per
thread. But now that I've learned that the major problem is saving the
register state, I wouldn't dare thinking about how a working per-thread
solution really would need to look like :o

(by the way: is sighandler stack per thread or per process ?)

> the kernel needs to be able to say "no" in a graceful way, there are 
> several scenarios
> (from the sysadmin wanting to manage power/performance/resources to 
> outright compatibility where
> the kernel wants or needs to say "no". Most obvious example: if a 
> process asked for an sigaltstack,
> we can't let the process use AMX since that stack will be too small most 
> likely to hold
> the stackframe)

Ah okay, when I wrote that mail, didn't know yet that so much state
needs to be saved.


--mtx


-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@...ux.net -- +49-151-27565287