linux-kernel - Re: [PATCH v9 12/26] x86/fpu/xstate: Use feature disable (XFD) to protect dynamic user state

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]

Date:   Mon, 30 Aug 2021 19:53:04 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Len Brown <lenb@...nel.org>
Cc:     "Chang S. Bae" <chang.seok.bae@...el.com>,
        Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>, X86 ML <x86@...nel.org>,
        "Brown, Len" <len.brown@...el.com>,
        Dave Hansen <dave.hansen@...el.com>, thiago.macieira@...el.com,
        "Liu, Jing2" <jing2.liu@...el.com>,
        "Ravi V. Shankar" <ravi.v.shankar@...el.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v9 12/26] x86/fpu/xstate: Use feature disable (XFD) to
 protect dynamic user state

On Tue, Aug 24, 2021 at 07:17:49PM -0400, Len Brown wrote:
> The problem with a system call to pre-allocate an AMX context switch
> buffer is that it doesn't actually deliver on the goal of guaranteeing
> no subsequent run-time failures due to OOM.

You mean you pre-allocate *everything*, i.e., you won't do any more
allocations but then you still might OOM?

Yeah, right.

Maybe from something else but not from your AMX-using process which has
prepared everything already.

> Even if your AMX thread pool threads were to invoke this system call
> as soon as possible... What is to say that the thread pool is created
> only at a time when memory is available? A thread could be created
> 24 hours into program execution under OOM conditions and this system
> call will return ENOMEM, and your program will in all likelihood
> throw up its arms and exit at the exact same place it would exit for
> transparently allocated buffers.

Well, if you preallocate everything you won't have to run for 24 hours,
encounter -ENOMEM and *lose* 24 hours worth of AMX computation. And then
the kernel won't have to do all kinds of crazy dance with dynamically
resizing buffers just because some small percentage of luserspace apps
decided to do AMX stuff.

> The program can equally cause the kernel to allocate an AMX context
> switch buffer by simply touching a TMM register -- and this can
> be done at exactly the same place in the program that calling a
> pre-allocate system call.

If the program touches a TMM register and it hasn't requested AMX
support upfront, it'll get killed.

> The advantage of the #NM over the syscall is that the programmer
> doesn't actually have to do anything. Also, transparently allocated
> buffers offer a theoretical benefit that a program may have many
> threads, but only a few may actually touch AMX, and so there is
> savings to be had by allocating buffers only for the threads that
> actually use the buffers.

The program already asked the kernel whether it can use AMX - it can
allocate the buffers for the threads too.

> XFD is used to *enforce* that AMX is not used without permission.
> Were we to not use the XFD feature, users would be able to stash
> data in TMM registers and even use TMUL without the kernel
> being able to prevent them from doing so.  Then when they
> context switch or take a signal, the data in their TMM registers
> would mysteriously vanish...
>
> Much better to be able to tell them immediately that they are doing it
> wrong...

Ok, killing the program in the #NM handler if it hasn't requested AMX
prior makes sense.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette