Re: [QUESTION] Does PowerVM populate the rtas-sensors device-tree property?

[Michael Ellerman <mpe@kernel.org>]

On 3/11/26 7:35 pm, Kay wrote:
> Hi,
> 
> I asked a while back whether PowerVM populates rtas-sensors. The
> answer is yes. Michael Bringmann posted a live pHyp device-tree dump
> in June 2017 that contains:
> 
>      rtas-sensors     00000001 00000000 00000005 00000000
>                       00000009 00000000 0000232d 00000000
> 
> That's four (token, maxindex) pairs, 32 bytes on an IBM 8408-E8E running pHyp.

There's also a dump here from an old system:
   https://github.com/linuxppc/example-device-trees/blob/main/power6-lpar/lsprop.txt#L278

So it has been populated in the past, I don't know about newer systems.
> I looked at LoPAPR 1.1 section 7.2.6.1.2 and couldn't find a stated
> maximum. Linux uses MAX_SENSORS = 17 with the comment "I only know of
> 17 sensors", which reads to me like an implementation choice rather
> than a documented firmware limit. Bringmann's dump has 4. Can PowerVM
> ever emit more than 17?

It's possible.

New features on PowerVM have tended to use hcalls rather than adding more use
of device tree, but that's just a general tendency, not to say a new sensor
couldn't show up here.

> In case you might wonder why I ask: ppc_rtas_find_all_sensors()
> computes sensors.quant = len / 8 and copies that many entries into
> sensors.sensor[17] without checking. I reproduced this in QEMU with an
> 18-descriptor (144-byte) property against unmodified upstream
> cbbddb6b08cc with CONFIG_KASAN=y. Reading /proc/powerpc/rtas/sensors
> as uid 65534 gives me:
> 
>      BUG: KASAN: global-out-of-bounds in ppc_rtas_sensors_show
>      Write of size 4 at ... by task cat/66
>      ... sensors+0x8c/0xc0
> 
> I then applied Pengpeng Hou's April bounds check
> (<20260401160317.88585-1-pengpeng@iscas.ac.cn>, never merged,
> https://lore.kernel.org/linuxppc-dev/20260401160317.88585-1-pengpeng@iscas.ac.cn/)
> on the same kernel and property:
> 
>      too many sensors reported: 18
>      No sensors are available
> 
> No KASAN report at all. So the overrun is demonstrable from an
> unprivileged read once a >17-descriptor property exists. What I can't
> determine is reachability: does any shipped firmware emit one? If 17
> is a firmware cap, the fix is defensive only, if not, I think
> Pengpeng's check is worth reviving.
Yes that patch looks good even if we think 17 is a maximum.

A better solution would be to allocate the array based on the number of sensors found, but that could be a follow-up.

cheers