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]
Message-ID: <82259B6F-2F57-4099-869D-84891D996664@zytor.com>
Date: Wed, 06 Mar 2024 12:39:46 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Xin Li <xin@...or.com>, linux-kernel@...r.kernel.org,
        xen-devel@...ts.xenproject.org
CC: tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
        dave.hansen@...ux.intel.com, x86@...nel.org, jgross@...e.com,
        boris.ostrovsky@...cle.com, arnd@...db.de, andrew.cooper3@...rix.com,
        brgerst@...il.com
Subject: Re: [PATCH v2 1/1] x86/fred: Fix init_task thread stack pointer initialization

On March 6, 2024 10:28:25 AM PST, Xin Li <xin@...or.com> wrote:
>On 3/4/2024 12:33 AM, Xin Li (Intel) wrote:
>> As TOP_OF_KERNEL_STACK_PADDING is defined as 0 on x86_64, no one noticed
>> it's missing in the calculation of the .sp field in INIT_THREAD until it
>> is defined to 16 with CONFIG_X86_FRED=y.
>> 
>> Subtract TOP_OF_KERNEL_STACK_PADDING from the .sp field of INIT_THREAD.
>> 
>> Fixes: 65c9cc9e2c14 ("x86/fred: Reserve space for the FRED stack frame")
>> Fixes: 3adee777ad0d ("x86/smpboot: Remove initial_stack on 64-bit")
>> Reported-by: kernel test robot <oliver.sang@...el.com>
>> Closes: https://lore.kernel.org/oe-lkp/202402262159.183c2a37-lkp@intel.com
>> Signed-off-by: Xin Li (Intel) <xin@...or.com>
>> ---
>
>Should this fix, if it looks good, be included for the coming merge
>window?
>
>Thanks!
>    Xin
>
>> 
>> Change Since v1:
>> * Apply offset TOP_OF_KERNEL_STACK_PADDING to all uses of __end_init_task
>>    (Brian Gerst).
>> ---
>>   arch/x86/include/asm/processor.h | 6 ++++--
>>   arch/x86/kernel/head_64.S        | 3 ++-
>>   arch/x86/xen/xen-head.S          | 2 +-
>>   3 files changed, 7 insertions(+), 4 deletions(-)
>> 
>> diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
>> index 26620d7642a9..17fe81998ce4 100644
>> --- a/arch/x86/include/asm/processor.h
>> +++ b/arch/x86/include/asm/processor.h
>> @@ -664,8 +664,10 @@ static __always_inline void prefetchw(const void *x)
>>   #else
>>   extern unsigned long __end_init_task[];
>>   -#define INIT_THREAD {							    \
>> -	.sp	= (unsigned long)&__end_init_task - sizeof(struct pt_regs), \
>> +#define INIT_THREAD {							\
>> +	.sp	= (unsigned long)&__end_init_task -			\
>> +		  TOP_OF_KERNEL_STACK_PADDING -				\
>> +		  sizeof(struct pt_regs),				\
>>   }
>>     extern unsigned long KSTK_ESP(struct task_struct *task);
>> diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
>> index d4918d03efb4..c38e43589046 100644
>> --- a/arch/x86/kernel/head_64.S
>> +++ b/arch/x86/kernel/head_64.S
>> @@ -26,6 +26,7 @@
>>   #include <asm/apicdef.h>
>>   #include <asm/fixmap.h>
>>   #include <asm/smp.h>
>> +#include <asm/thread_info.h>
>>     /*
>>    * We are not able to switch in one step to the final KERNEL ADDRESS SPACE
>> @@ -66,7 +67,7 @@ SYM_CODE_START_NOALIGN(startup_64)
>>   	mov	%rsi, %r15
>>     	/* Set up the stack for verify_cpu() */
>> -	leaq	(__end_init_task - PTREGS_SIZE)(%rip), %rsp
>> +	leaq	(__end_init_task - TOP_OF_KERNEL_STACK_PADDING - PTREGS_SIZE)(%rip), %rsp
>>     	leaq	_text(%rip), %rdi
>>   diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
>> index a0ea285878db..04101b984f24 100644
>> --- a/arch/x86/xen/xen-head.S
>> +++ b/arch/x86/xen/xen-head.S
>> @@ -49,7 +49,7 @@ SYM_CODE_START(startup_xen)
>>   	ANNOTATE_NOENDBR
>>   	cld
>>   -	leaq	(__end_init_task - PTREGS_SIZE)(%rip), %rsp
>> +	leaq	(__end_init_task - TOP_OF_KERNEL_STACK_PADDING - PTREGS_SIZE)(%rip), %rsp
>>     	/* Set up %gs.
>>   	 *
>> 
>> base-commit: e13841907b8fda0ae0ce1ec03684665f578416a8
>

Absolutely.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ