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]
Message-ID: <3fe43c05-3505-498e-b36f-04da15f73b6b@linux.intel.com>
Date: Thu, 27 Jun 2024 11:50:55 +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/24 14:47, Ning, Hongyu wrote:
> 
> 
> 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
> 

add a quick update:
1. CONFIG_X86_DEBUG_FPU=y was set by auto regression framework
2. disable CONFIG_X86_DEBUG_FPU will bypass above WARNING and NULL 
pointer issue

it may not make sense for general kernel regression check to enable 
CONFIG_X86_DEBUG_FPU=y, will revise auto regression framework to keep 
CONFIG_X86_DEBUG_FPU disabled to bypass it.

in the meanwhile, please let me know if this issue is still valuable to 
look into.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ