[dmidecode] /sys/firmware interface?

[Leif Lindholm]

(My email from last week doesn't seem to have made it through
moderation, so I have subscribed before resending.)

Hi there,

So, related to Sam Kottler's email of last month, I am interested in
the state of dmidecode on at least one additional architecture
(arm64).

But the problem is non-trivial; making dmidecide work is simple (just
ensure not to scan random bits of memory for the tables, and find them
instead via UEFI), but making it work safely is a different matter.

On x86, the memory map is fairly predictable, and access to /dev/mem
can be filtered to permit only (relatively) safe regions to be mapped.

However, on ARM, there are userspace GPU drivers, GPIO poking and
other random things going on - and locking down access to only known
safe-ish regions would at best be very tricky. Certainly for the types
of ARM systems likely to want dmidecode (servers), one would like to
be able to completely disable access to /dev/mem.

So, the above scene set:

Has anyone looked into using the /sys/firmware/dmi (CONFIG_DMI_SYSFS)
interface rather than /dev/mem? (And /sys/firmware/acpi for ACPI.)

Looking around, I find at least several (possibly many) projects doing
/dev/mem scanning for DMI/SMBIOS. If DMI_SYSFS is an acceptable way to
go, would anyone object to it being an external library as opposed to
part directly of this project?

/
    Leif