[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[dmidecode] /sys/firmware interface?

From: Leif Lindholm
Subject: [dmidecode] /sys/firmware interface?
Date: Mon, 17 Nov 2014 11:36:35 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

(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

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]