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

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

[Bui Nguyen Nhu Quynh]

Hi,

I am trying to determine whether PowerVM firmware populates the rtas-sensors device-tree property on the /rtas node. The kernel's ppc_rtas_sensors_show() in arch/powerpc/kernel/rtas-proc.c reads it, but I have found no producer in QEMU, SLOF, or the kernel documentation.

On any PowerVM system, the answer is one command:

    ls -l /proc/device-tree/rtas/rtas-sensors
    od -An -tx1 /proc/device-tree/rtas/rtas-sensors

If the file exists, could you report the byte output? If it does not exist, that also answers the question.

I have a QEMU patch and a local reproducer if useful, but the firmware-side answer is the only thing I cannot determine locally.

Thanks.

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

[Kay]

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.

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?

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.

Thanks.

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

[Michael Ellerman]

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