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]

Message-ID: <a96a65fc-061b-e94b-cee7-16201ac0820f@intel.com>
Date:   Mon, 30 Aug 2021 11:04:40 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Len Brown <lenb@...nel.org>, Borislav Petkov <bp@...en8.de>
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>, 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 8/24/21 4:17 PM, Len Brown wrote:
> 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.

I tried this exact line of reasoning with Thomas: it doesn't matter
where we run out of memory, we still need the same memory and we're
screwed either way.

However, Thomas expressed a clear preference for ABIs which return
memory failures explicitly at syscalls versus implicit failures which
can happen on random instructions.

One might say that the odds of checking for and handling a NULL value
(or ENOMEM) are the same as installing a signal handler.  *But*, it's
infinitely easier to unroll state and recover from a NULL than it is to
handle it from within a signal handler.  In other words, the explicit
ones *encourage* better programming.

I'd prefer removing the demand-driven allocation at this point.