linux-kernel - Re: [PATCH 01/22] x86/fpu: Remove fpu->initialized usage in __fpu__restore

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, 14 Jan 2019 17:24:00 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.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 01/22] x86/fpu: Remove fpu->initialized usage in
 __fpu__restore_sig()

On Wed, Jan 09, 2019 at 12:47:23PM +0100, Sebastian Andrzej Siewior wrote:
> This is a preparation for the removal of the ->initialized member in the
> fpu struct.
> __fpu__restore_sig() is deactivating the FPU via fpu__drop() and then
> setting manually ->initialized followed by fpu__restore(). The result is
> that it is possible to manipulate fpu->state and the state of registers
> won't be saved/restored on a context switch which would overwrite
> fpu->state.
> 
> Don't access the fpu->state while the content is read from user space
> and examined / sanitized. Use a temporary kmalloc() buffer for the
> preparation of the FPU registers and once the state is considered okay,
> load it. Should something go wrong, return with an error and without
> altering the original FPU registers.
> 
> The removal of "fpu__initialize()" is a nop because fpu->initialized is
> already set for the user task.
> 
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
> ---
>  arch/x86/include/asm/fpu/signal.h |  2 +-
>  arch/x86/kernel/fpu/regset.c      |  5 ++--
>  arch/x86/kernel/fpu/signal.c      | 41 ++++++++++++-------------------
>  3 files changed, 19 insertions(+), 29 deletions(-)

...

> @@ -315,40 +313,33 @@ static int __fpu__restore_sig(void __user *buf, void __user *buf_fx, int size)
>  		 * header. Validate and sanitize the copied state.
>  		 */
>  		struct user_i387_ia32_struct env;
> +		union fpregs_state *state;
>  		int err = 0;
> +		void *tmp;
>  
> -		/*
> -		 * Drop the current fpu which clears fpu->initialized. This ensures
> -		 * that any context-switch during the copy of the new state,
> -		 * avoids the intermediate state from getting restored/saved.
> -		 * Thus avoiding the new restored state from getting corrupted.
> -		 * We will be ready to restore/save the state only after
> -		 * fpu->initialized is again set.
> -		 */
> -		fpu__drop(fpu);
> +		tmp = kzalloc(sizeof(*state) + fpu_kernel_xstate_size + 64, GFP_KERNEL);
> +		if (!tmp)
> +			return -ENOMEM;
> +		state = PTR_ALIGN(tmp, 64);
>  
>  		if (using_compacted_format()) {
> -			err = copy_user_to_xstate(&fpu->state.xsave, buf_fx);
> +			err = copy_user_to_xstate(&state->xsave, buf_fx);
>  		} else {
> -			err = __copy_from_user(&fpu->state.xsave, buf_fx, state_size);
> +			err = __copy_from_user(&state->xsave, buf_fx, state_size);
>  
>  			if (!err && state_size > offsetof(struct xregs_state, header))
> -				err = validate_xstate_header(&fpu->state.xsave.header);
> +				err = validate_xstate_header(&state->xsave.header);
>  		}
>  
>  		if (err || __copy_from_user(&env, buf, sizeof(env))) {
> -			fpstate_init(&fpu->state);
> -			trace_x86_fpu_init_state(fpu);
>  			err = -1;
>  		} else {
> -			sanitize_restored_xstate(tsk, &env, xfeatures, fx_only);
> +			sanitize_restored_xstate(state, &env,
> +						 xfeatures, fx_only);

Just let that one stick out - there are other lines in this file already
longer than 80.

Notwithstanding, I don't see anything wrong with this patch.

Acked-by: Borislav Petkov <bp@...e.de>

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.