[PATCH] platform: generic: spacemit: k3: deny S-mode access to the reset vectors

[liutong]

On Thu, 12 Nov 2026 07:59:32 +0000, Xiang W wrote:
> The PMP granularity on K3 is 4 KiB, so a mapping size smaller than
> that will be ignored.
>
> Could you clarify how this case should be handled?

Thanks, and thanks to Han Gao for putting it on hardware. You are
right.

The region order comes out of sbi_domain_memregion_init() without
reference to the PMP granularity, and both protection backends then
drop a region whose order is below it:

	if (pmp_log2gran <= reg->order && pmp_addr < pmp_addr_max)
		...program the entry...
	else
		sbi_printf("Can not configure pmp for domain %s ...

(lib/sbi/sbi_hart_pmp.c:209 and :390). So with a 4 KiB granularity the
1 KiB region in my patch is never programmed and the firmware boots on
with one line printed. The patch was a no-op on your board. I had only
tested on qemu virt, where the granularity is 4 bytes and any size
passes.

Rounding up to the page is not a fix either, and this is the part I had
wrong. The page at 0xd4282000 also holds the APMU block, which upstream
Linux drives directly from S-mode:

	syscon_apmu: system-controller at d4282800 {
		compatible = "spacemit,k3-syscon-apmu";
		reg = <0x0 0xd4282800 0x0 0x400>;
		#clock-cells = <1>;
		#power-domain-cells = <1>;
	};

(arch/riscv/boot/dts/spacemit/k3.dtsi, with drivers/clk/spacemit/ccu-k3.c
behind it). Denying S-mode the page on its own would take out the clock,
reset and power domain provider for the whole board.

SpaceMit's k3-br-v1.0.y does not only register the region. It also
installs emulate_load and emulate_store, which translate the faulting
S-mode address and perform the access in M-mode, except for an
m_only_ranges list that it refuses to emulate - and that list is exactly
the four RVBADDR pairs plus the PMU CAP and CX idle and wakeup
registers. The comment on the barriers in that emulator names the kernel
CCU driver's recalc_rate loop, so the S-mode traffic is expected there by
design. Upstream already has the hooks for that
(sbi_platform_operations.emulate_load and emulate_store), although no
in-tree platform uses them yet.

That two part shape is what makes the protection safe on that branch,
and my patch carried over only the first part. I am dropping it rather
than sending a v2 that would break clocks.

Troy, Xianbin: would you be interested in upstreaming that protection
from k3-br-v1.0.y?

One smaller thing this exposed, separate from K3: a region below the PMP
granularity is dropped with a single printf and boot continues, so a
platform author gets no signal that the protection they registered is
not in effect. That is how I missed it. Whether it should be louder, or
rounded up, looks like its own discussion and I did not want to fold it
into this thread.

Thanks again for catching this before it went in.

liutong