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: <CAJvTdK=A64DQXjYkZgPebWb-V_p_HAM+jTZRLTyi1qrP9kucMg@mail.gmail.com>
Date:   Fri, 21 May 2021 18:07:07 -0400
From:   Len Brown <lenb@...nel.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Florian Weimer <fweimer@...hat.com>,
        Dave Hansen <dave.hansen@...el.com>,
        Dave Hansen via Libc-alpha <libc-alpha@...rceware.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 3:10 PM Thomas Gleixner <tglx@...utronix.de> 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.

Regarding pre-allocation vs on-demand allocation, consider two scenarios:

1. Synchronous.  At process or thread start up time, prctl()
synchronously allocates 8K context switch buffers.  Return code is 0
-- good go go!  10 seconds later the program decides to create
additional threads.  Woops. vmalloc failed, and the process
synchronously dies.  bug filed.

2. On demand.  Same scenario, except vmalloc failure upon creation of
those additional threads sends a SIGSEGV at the instruction where AMX
is touched.  bug filed.

Why ignore the 2nd bug and not ignore the 1st bug?

My concern about synchronous allocation is that it will be very easy
to abuse.  programs and threads can ask for buffers they will never
use.  With on-demand allocation, we allocate buffers only if they are
actually needed.

Len Brown, Intel Open Source Technology Center