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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YR1NAvJW4w8bhEEu@zn.tnic>
Date:   Wed, 18 Aug 2021 20:10:10 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Thiago Macieira <thiago.macieira@...el.com>
Cc:     "Chang S. Bae" <chang.seok.bae@...el.com>, luto@...nel.org,
        tglx@...utronix.de, mingo@...nel.org, x86@...nel.org,
        len.brown@...el.com, dave.hansen@...el.com, jing2.liu@...el.com,
        ravi.v.shankar@...el.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v9 12/26] x86/fpu/xstate: Use feature disable (XFD) to
 protect dynamic user state

On Wed, Aug 18, 2021 at 10:58:42AM -0700, Thiago Macieira wrote:
> That tells me what the CPU supports, not what the kernel does. By
> omitting the "xfd" entry in /proc/cpuinfo, we are assuming that all
> kernels with "amxtile" also implicitly support xfd. That is a valid
> assumption.

What relevance does the fact have for userspace whether the kernel
supports XFD or not?

IOW, userspace cares about AMX and the other features which are supposed
to use XFD - not how those features are implemented: whether with
faulting or with pre-allocation or whatever.

> Many applications need to determine which plugins and code paths to
> enable before getting the data that will tell them what to do. It's
> entirely possible for them to never need to run the AMX instructions,
> so they may wish to defer the request to allocate the XSAVE state
> until they have read their input data.
>
> It's indeed possible that the allocation then fails and the
> application be unable to continue. But OOM conditions are unlikely, so
> it may be an acceptable price to pay. In fact, by *not* allocating the
> extra state for every thread in the current process, it may avoid the
> OOM.

And?

That doesn't conflict with my suggestion. It goes and asks the kernel
what it supports and then requests the buffers.

> Sorry, that's not what I meant. I was going to request an extra API, a third 
> call. We'd have:
>  - get current state
>  - set new state
>  - get available bits to set

Yes, this should have been the API from the very beginning. Of course
you need to be able to query what bits can be set at all.

> ...
> Now, if we are going to have this API any way, it might be a good
> idea to combine the two getters in one by adding a second pointer
> parameter.

Yeah, I'll get to that patch in the coming days and have a look. So far,
it only makes sense to have a querying API too so that we can provide
support for more "fat" features.

Unless Intel folks decide to stop using XSAVE for that - it was a bad
idea in the first place anyway, TBH - but it's not like hw people listen
to sw folk so...

-- 
Regards/Gruss,
    Boris.

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