linux-kernel - Re: [PATCH 11/29] x86/fpu: Always init the `state' in fpu_

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] [day] [month] [year] [list]

Date:   Thu, 13 Dec 2018 15:35:53 +0100
From:   Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:     Borislav Petkov <bp@...en8.de>
Cc:     linux-kernel@...r.kernel.org, x86@...nel.org,
        Andy Lutomirski <luto@...nel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Radim Krčmář <rkrcmar@...hat.com>,
        kvm@...r.kernel.org, "Jason A. Donenfeld" <Jason@...c4.com>,
        Rik van Riel <riel@...riel.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>
Subject: Re: [PATCH 11/29] x86/fpu: Always init the `state' in fpu__clear()

On 2018-12-12 18:11:29 [+0100], Borislav Petkov wrote:
> > diff --git a/arch/x86/math-emu/fpu_entry.c b/arch/x86/math-emu/fpu_entry.c
> > index 9e2ba7e667f61..a873da6b46d6b 100644
> > --- a/arch/x86/math-emu/fpu_entry.c
> > +++ b/arch/x86/math-emu/fpu_entry.c
> > @@ -113,9 +113,6 @@ void math_emulate(struct math_emu_info *info)
> >  	unsigned long code_base = 0;
> >  	unsigned long code_limit = 0;	/* Initialized to stop compiler warnings */
> >  	struct desc_struct code_descriptor;
> > -	struct fpu *fpu = &current->thread.fpu;
> > -
> > -	fpu__initialize(fpu);
> 
> Ok, you're removing it here but where is the FPU going to be initialized
> now in the FPU-less case?
> 
> IOW, it is not clear to me where fpu__clear() get called for the FPU
> emulation case now...

During fork() fpu__initialize() is called for both (with and without
FPU) systems. The difference is made in fpu__clear() where the init is
avoided in the FPU-less case. With this hunk:

--- a/arch/x86/kernel/fpu/core.c
+++ b/arch/x86/kernel/fpu/core.c
@@ -365,8 +364,8 @@ void fpu__clear(struct fpu *fpu)
        /*
         * Make sure fpstate is cleared and initialized.
         */
+       fpu__initialize(fpu);
        if (static_cpu_has(X86_FEATURE_FPU)) {
-               fpu__initialize(fpu);
                user_fpu_begin();
                copy_init_fpstate_to_fpregs();
        }                                                                                                                                                                                 
we have the initialization in both cases.
The only "negative" thing might be that we now have a memset(, 0, 684)
(fpstate_init_soft()) during fork which would be avoided in case the
FPU-less system has a userland which is compiled with a soft-FPU toolchain.

I would worry about it once someone complains (and I doubt someone
complains even if we remove soft FPU support).

Sebastian