linux-kernel - Re: [PATCH v5 14/28] x86/fpu/xstate: Prevent unauthorised use of 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:   Wed, 16 Jun 2021 12:01:47 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     "Bae, Chang Seok" <chang.seok.bae@...el.com>,
        Andy Lutomirski <luto@...nel.org>
Cc:     Borislav Petkov <bp@...e.de>, Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>, X86 ML <x86@...nel.org>,
        "Brown, Len" <len.brown@...el.com>,
        "Liu, Jing2" <jing2.liu@...el.com>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 14/28] x86/fpu/xstate: Prevent unauthorised use of
 dynamic user state

On 6/16/21 11:47 AM, Bae, Chang Seok wrote:
> On Jun 16, 2021, at 11:12, Andy Lutomirski <luto@...nel.org> wrote:
>> On 6/16/21 9:27 AM, Dave Hansen wrote:
>>> On 5/23/21 12:32 PM, Chang S. Bae wrote:
>>>> @@ -571,6 +612,8 @@ static inline void switch_fpu_finish(struct fpu *new_fpu)
>>>>
>>>> 	set_thread_flag(TIF_NEED_FPU_LOAD);
>>>>
>>>> +	xfd_switch(old_fpu, new_fpu);
>>> This seems fragile.
>>>
>>> XSAVE* will decline to write out state for feature i when XFD[i]=1 and
>>> will instead write out the init state.  That means that, at this point,
>>> we switch XFD and yet leave state for feature i in place.
>>>
>>> That means this *MUST* come before any copy_fpregs_to_fpstate() occurs.
>>>
>>> Could we please add some FPU_WARN_ON() checks to ensure that no XSAVE*
>>> is ever performed with XINUSE=1 *and* XFD armed?
> So, xfd_switch() is after copy_fpregs_to_fpstate():
>  
> __switch_to()
> --> switch_fpu_prepare() --> copy_fpregs_to_fpstate()
> --> switch_fpu_finish() --> xfd_switch()
>  
> I don't see someone intentionally flip this order.

I'm more worried about how it might interact with KVM, or how future
code might try to optimize the whole thing.

Either way: the point stands: XSAVE with XINIT[i]=0 and XFD[i]=1 kills
puppies.  I ideally want a warning if the puppy slaughter ever happens.
 If that's not feasible, I'll also settle for a big fat comment about it.

But, something is needed.  The XSAVE code is littered with assumptions
that demonstrate a lack of imagination about how future hacking might
kill puppies.

> Reading XINUSE via XGETBV is cheap but not free. I don't know spending a
> hundred cycles for this WARN is big deal but this is one of the most
> performance-critical paths.
Is XGETBV(1) really a hundred cycles?  That seems absurdly high for a
non-serializing register read.

If you're really worried, let's put it under X86_FEATURE_DEBUG_FPU or
something.