linux-kernel - Re: [PATCH] riscv: smp: Align secondary_start

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: <o7fbcofuyu3nuqk2bituvfr7fitsiiimvu55h4wyefezpuqniw@34xczmgjn5lm>
Date: Thu, 5 Feb 2026 12:21:20 -0600
From: Andrew Jones <andrew.jones@....qualcomm.com>
To: cp0613@...ux.alibaba.com
Cc: pjw@...nel.org, anup@...infault.org, alex@...ti.fr, guoren@...nel.org,
        linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] riscv: smp: Align secondary_start_sbi to 4 bytes

On Thu, Feb 05, 2026 at 08:16:25PM +0800, cp0613@...ux.alibaba.com wrote:
> From: Chen Pei <cp0613@...ux.alibaba.com>
> 
> During SMP boot, the secondary_start_sbi address is passed to the
> slave core via sbi_hsm_hart_start. In OpenSBI, this address is
> written to STVEC in sbi_hart_switch_mode.
> 
> According to the privileged specification, the BASE field of STVEC
> must always be aligned on a 4-byte boundary. However, System.map
> reveals that secondary_start_sbi is not a 4-byte aligned address.
> 
> For example, the address of secondary_start_sbi is
> 0xffffffff80001066, and the disassembly is as follows:
> 
> Dump of assembler code from 0xffffffff80001052 to 0xffffffff8000107a:
>    0xffffffff80001052 <_start+4178>:    c.nop   -11
>    0xffffffff80001054 <_start+4180>:    auipc   gp,0x1a1f
>    0xffffffff80001058 <_start+4184>:    addi    gp,gp,84
>    0xffffffff8000105c <_start+4188>:    csrw    satp,a2
>    0xffffffff80001060 <_start+4192>:    sfence.vma
>    0xffffffff80001064 <_start+4196>:    ret
>    0xffffffff80001066 <_start+4198>:    csrw    sie,zero
>    0xffffffff8000106a <_start+4202>:    csrw    sip,zero
>    0xffffffff8000106e <_start+4206>:    li      t0,2
>    0xffffffff80001070 <_start+4208>:    csrw    scounteren,t0
>    0xffffffff80001074 <_start+4212>:    auipc   gp,0x1a1f
>    0xffffffff80001078 <_start+4216>:    addi    gp,gp,52
> 
> When writing to STVEC at address 0xffffffff80001066, the actual
> write address is 0xffffffff80001064, corresponding to the address
> of the previous ret instruction. This is unexpected, and if an
> interrupt occurs at this point, it will cause unpredictable results.
> 
> However, secondary_start_sbi immediately masks all interrupts and
> updates STVEC, so no problems occurred.
> 
> In summary, it is more reasonable to make secondary_start_sbi
> satisfy 4-byte alignment.
> 
> Signed-off-by: Chen Pei <cp0613@...ux.alibaba.com>
> ---
>  arch/riscv/kernel/head.S | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S
> index bdf3352acf4c..f35dbfa79505 100644
> --- a/arch/riscv/kernel/head.S
> +++ b/arch/riscv/kernel/head.S
> @@ -124,6 +124,7 @@ relocate_enable_mmu:
>  
>  	ret
>  #endif /* CONFIG_MMU */
> +.align 2
>  #ifdef CONFIG_SMP
>  	.global secondary_start_sbi
>  secondary_start_sbi:
> -- 
> 2.50.1
>

Looks good, but the .align 2 would ideally go inside the
#ifdef CONFIG_SMP, just above the label.

Reviewed-by: Andrew Jones <andrew.jones@....qualcomm.com>

Thanks,
drew