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
(<[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.
Thanks.
