linux-kernel - Re: [PATCH v1 1/1] riscv: fix runtime constant support for nommu kernels

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: <mhng-25801815-A406-4521-8A19-2F2B5E7AB30D@palmerdabbelt-mac>
Date: Tue, 10 Jun 2025 15:25:53 -0700 (PDT)
From: Palmer Dabbelt <palmer@...belt.com>
To: cmirabil@...hat.com
CC: linux-kernel@...r.kernel.org, Paul Walmsley <paul.walmsley@...ive.com>,
  aou@...s.berkeley.edu, Alexandre Ghiti <alex@...ti.fr>, Charlie Jenkins <charlie@...osinc.com>,
  linux-riscv@...ts.infradead.org (open list:RISC-V ARCHITECTURE), cmirabil@...hat.com
Subject:     Re: [PATCH v1 1/1] riscv: fix runtime constant support for nommu kernels

On Fri, 30 May 2025 14:14:22 PDT (-0700), cmirabil@...hat.com wrote:
> the `__runtime_fixup_32` function does not handle the case where `val` is
> zero correctly (as might occur when patching a nommu kernel and referring
> to a physical address below the 4GiB boundary whose upper 32 bits are all
> zero) because nothing in the existing logic prevents the code from taking
> the `else` branch of both nop-checks and emitting two `nop` instructions.
>
> This leaves random garbage in the register that is supposed to receive the
> upper 32 bits of the pointer instead of zero that when combined with the
> value for the lower 32 bits yields an invalid pointer and causes a kernel
> panic when that pointer is eventually accessed.
>
> The author clearly considered the fact that if the `lui` is converted into
> a `nop` that the second instruction needs to be adjusted to become an `li`
> instead of an `addi`, hence introducing the `addi_insn_mask` variable, but
> didn't follow that logic through fully to the case where the `else` branch
> executes. To fix it just adjust the logic to ensure that the second `else`
> branch is not taken if the first instruction will be patched to a `nop`.
>
> Fixes: a44fb5722199 ("riscv: Add runtime constant support")
>
> Signed-off-by: Charles Mirabile <cmirabil@...hat.com>
> ---
>  arch/riscv/include/asm/runtime-const.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/riscv/include/asm/runtime-const.h b/arch/riscv/include/asm/runtime-const.h
> index 451fd76b8811..d766e2b9e6df 100644
> --- a/arch/riscv/include/asm/runtime-const.h
> +++ b/arch/riscv/include/asm/runtime-const.h
> @@ -206,7 +206,7 @@ static inline void __runtime_fixup_32(__le16 *lui_parcel, __le16 *addi_parcel, u
>  		addi_insn_mask &= 0x07fff;
>  	}
>
> -	if (lower_immediate & 0x00000fff) {
> +	if (lower_immediate & 0x00000fff || lui_insn == RISCV_INSN_NOP4) {
>  		/* replace upper 12 bits of addi with lower 12 bits of val */
>  		addi_insn &= addi_insn_mask;
>  		addi_insn |= (lower_immediate & 0x00000fff) << 20;

Thanks.  This looks reasonable to me, so I've stuck it on fixes -- I'm 
still sorting out some post-merge-window cruft, so it might take a bit 
to show up for real.