| 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
| ||
|
Date: Mon, 24 Jun 2024 14:47:47 +0800
From: "Ning, Hongyu" <hongyu.ning@...ux.intel.com>
To: Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org
Cc: Andy Lutomirski <luto@...capital.net>,
Andrew Morton <akpm@...ux-foundation.org>, Dave Hansen <dave@...1.net>,
Peter Zijlstra <peterz@...radead.org>, Borislav Petkov <bp@...en8.de>,
"H . Peter Anvin" <hpa@...or.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Oleg Nesterov <oleg@...hat.com>, Thomas Gleixner <tglx@...utronix.de>,
Uros Bizjak <ubizjak@...il.com>, kirill.shutemov@...ux.intel.com
Subject: Re: [PATCH 3/3] x86/fpu: Remove init_task FPU state dependencies, add
debugging warning
On 2024/6/5 16:35, Ingo Molnar wrote:
> init_task's FPU state initialization was a bit of a hack:
>
> __x86_init_fpu_begin = .;
> . = __x86_init_fpu_begin + 128*PAGE_SIZE;
> __x86_init_fpu_end = .;
>
> But the init task isn't supposed to be using the FPU in any case,
> so remove the hack and add in some debug warnings.
>
> Signed-off-by: Ingo Molnar <mingo@...nel.org>
> Cc: Andy Lutomirski <luto@...nel.org>
> Cc: Borislav Petkov <bp@...en8.de>
> Cc: Fenghua Yu <fenghua.yu@...el.com>
> Cc: H. Peter Anvin <hpa@...or.com>
> Cc: Linus Torvalds <torvalds@...ux-foundation.org>
> Cc: Oleg Nesterov <oleg@...hat.com>
> Cc: Dave Hansen <dave.hansen@...ux.intel.com>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Uros Bizjak <ubizjak@...il.com>
> Link: https://lore.kernel.org/r/ZgaNs1lC2Y+AnRG4@gmail.com
> ---
> arch/x86/include/asm/processor.h | 6 +++++-
> arch/x86/kernel/fpu/core.c | 12 +++++++++---
> arch/x86/kernel/fpu/init.c | 5 ++---
> arch/x86/kernel/fpu/xstate.c | 3 ---
> arch/x86/kernel/vmlinux.lds.S | 4 ----
> 5 files changed, 16 insertions(+), 14 deletions(-)
>
> diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> index 249c5fa20de4..ed8981866f4d 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -504,7 +504,11 @@ struct thread_struct {
> #endif
> };
>
> -#define x86_task_fpu(task) ((struct fpu *)((void *)task + sizeof(*task)))
> +#ifdef CONFIG_X86_DEBUG_FPU
> +extern struct fpu *x86_task_fpu(struct task_struct *task);
> +#else
> +# define x86_task_fpu(task) ((struct fpu *)((void *)task + sizeof(*task)))
> +#endif
>
> /*
> * X86 doesn't need any embedded-FPU-struct quirks:
> diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
> index 0ccabcd3bf62..fdc3b227800d 100644
> --- a/arch/x86/kernel/fpu/core.c
> +++ b/arch/x86/kernel/fpu/core.c
> @@ -51,6 +51,15 @@ static DEFINE_PER_CPU(bool, in_kernel_fpu);
> */
> DEFINE_PER_CPU(struct fpu *, fpu_fpregs_owner_ctx);
>
> +#ifdef CONFIG_X86_DEBUG_FPU
> +struct fpu *x86_task_fpu(struct task_struct *task)
> +{
> + WARN_ON_ONCE(task == &init_task);
> +
> + return (void *)task + sizeof(*task);
> +}
> +#endif
> +
> /*
> * Can we use the FPU in kernel mode with the
> * whole "kernel_fpu_begin/end()" sequence?
> @@ -591,10 +600,8 @@ int fpu_clone(struct task_struct *dst, unsigned long clone_flags, bool minimal,
> * This is safe because task_struct size is a multiple of cacheline size.
> */
> struct fpu *dst_fpu = (void *)dst + sizeof(*dst);
> - struct fpu *src_fpu = x86_task_fpu(current);
>
> BUILD_BUG_ON(sizeof(*dst) % SMP_CACHE_BYTES != 0);
> - BUG_ON(!src_fpu);
>
> /* The new task's FPU state cannot be valid in the hardware. */
> dst_fpu->last_cpu = -1;
> @@ -657,7 +664,6 @@ int fpu_clone(struct task_struct *dst, unsigned long clone_flags, bool minimal,
> if (update_fpu_shstk(dst, ssp))
> return 1;
>
> - trace_x86_fpu_copy_src(src_fpu);
> trace_x86_fpu_copy_dst(dst_fpu);
>
> return 0;
> diff --git a/arch/x86/kernel/fpu/init.c b/arch/x86/kernel/fpu/init.c
> index 11aa31410df2..53580e59e5db 100644
> --- a/arch/x86/kernel/fpu/init.c
> +++ b/arch/x86/kernel/fpu/init.c
> @@ -38,7 +38,7 @@ static void fpu__init_cpu_generic(void)
> /* Flush out any pending x87 state: */
> #ifdef CONFIG_MATH_EMULATION
> if (!boot_cpu_has(X86_FEATURE_FPU))
> - fpstate_init_soft(&x86_task_fpu(current)->fpstate->regs.soft);
> + ;
> else
> #endif
> asm volatile ("fninit");
> @@ -164,7 +164,7 @@ static void __init fpu__init_task_struct_size(void)
> * Subtract off the static size of the register state.
> * It potentially has a bunch of padding.
> */
> - task_size -= sizeof(x86_task_fpu(current)->__fpstate.regs);
> + task_size -= sizeof(union fpregs_state);
>
> /*
> * Add back the dynamically-calculated register state
> @@ -209,7 +209,6 @@ static void __init fpu__init_system_xstate_size_legacy(void)
> fpu_kernel_cfg.default_size = size;
> fpu_user_cfg.max_size = size;
> fpu_user_cfg.default_size = size;
> - fpstate_reset(x86_task_fpu(current));
> }
>
> /*
> diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
> index 90b11671e943..1f37da22ddbe 100644
> --- a/arch/x86/kernel/fpu/xstate.c
> +++ b/arch/x86/kernel/fpu/xstate.c
> @@ -844,9 +844,6 @@ void __init fpu__init_system_xstate(unsigned int legacy_size)
> if (err)
> goto out_disable;
>
> - /* Reset the state for the current task */
> - fpstate_reset(x86_task_fpu(current));
> -
> /*
> * Update info used for ptrace frames; use standard-format size and no
> * supervisor xstates:
> diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
> index 226244a894da..3509afc6a672 100644
> --- a/arch/x86/kernel/vmlinux.lds.S
> +++ b/arch/x86/kernel/vmlinux.lds.S
> @@ -170,10 +170,6 @@ SECTIONS
> /* equivalent to task_pt_regs(&init_task) */
> __top_init_kernel_stack = __end_init_stack - TOP_OF_KERNEL_STACK_PADDING - PTREGS_SIZE;
>
> - __x86_init_fpu_begin = .;
> - . = __x86_init_fpu_begin + 128*PAGE_SIZE;
> - __x86_init_fpu_end = .;
> -
> #ifdef CONFIG_X86_32
> /* 32 bit has nosave before _edata */
> NOSAVE_DATA
Hi,
we've hit x86/fpu related WARNING and NULL pointer issue during KVM/QEMU
VM booting with latest linux-next kernel, bisect results show it's
related to this commit, would you take a look?
detailed description in https://bugzilla.kernel.org/show_bug.cgi?id=218980
Powered by blists - more mailing lists