linux-kernel - Re: [PATCH 2/2] riscv: mm: Use mmu-type from FDT to limit SATP mode

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: <18558b7c6df10da0.2100f58a3d0fe250.7de105a1ea2dd0f@Mac>
Date: Fri, 25 Jul 2025 16:29:56 +0000
From: "Junhui Liu" <junhui.liu@...moral.tech>
To: "Alexandre Ghiti" <alex@...ti.fr>, 
	"Paul Walmsley" <paul.walmsley@...ive.com>, 
	"Palmer Dabbelt" <palmer@...belt.com>, "Albert Ou" <aou@...s.berkeley.edu>
Cc: <linux-riscv@...ts.infradead.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] riscv: mm: Use mmu-type from FDT to limit SATP mode

On 25/07/2025 16:04, Alexandre Ghiti wrote:
> On 7/21/25 18:53, Junhui Liu wrote:
>> Some RISC-V implementations may hang when attempting to write an
>> unsupported SATP mode, even though the latest RISC-V specification
>> states such writes should have no effect. To avoid this issue, the
>> logic for selecting SATP mode has been refined:
>>
>> The kernel now determines the SATP mode limit by taking the minimum of
>> the value specified by the kernel command line (noXlvl) and the
>> "mmu-type" property in the device tree (FDT). If only one is specified,
>> use that.
>> - If the resulting limit is sv48 or higher, the kernel will probe SATP
>>    modes from this limit downward until a supported mode is found.
>> - If the limit is sv39, the kernel will directly use sv39 without
>>    probing.
>>
>> This ensures SATP mode selection is safe and compatible with both
>> hardware and user configuration, minimizing the risk of hangs.
>>
>> Signed-off-by: Junhui Liu <junhui.liu@...moral.tech>
>> ---
>>   arch/riscv/kernel/pi/fdt_early.c | 40 ++++++++++++++++++++++++++++++++++++++++
>>   arch/riscv/kernel/pi/pi.h        |  1 +
>>   arch/riscv/mm/init.c             | 11 ++++++++---
>>   3 files changed, 49 insertions(+), 3 deletions(-)
>>

[...]

> 
> I guess it's more convenient to use the 'mmu-type' property on this core 
> rather than using no4lvl right?

Yes, It's hard to ensure that all the users are aware of the need to use
the 'no4lvl', and the cmdline args can easily be overridden by the
bootloader or users if a `bootargs = "no4lvl"` is defined in the device
tree. Therefore, relying on the 'mmu-type' property is more robust and
user-friendly.

> 
> Anyway, what you implemented matches the description of the 'mmu-type' 
> binding, so:
> 
> Reviewed-by: Alexandre Ghiti <alexghiti@...osinc.com>
> 
> I'll take that for 6.17.

Thanks!

> 
> Thanks,
> 
> Alex

-- 
Best regards,
Junhui Liu