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
(<[email protected]>, never merged,
https://lore.kernel.org/linuxppc-dev/[email protected]/)
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
