Re: [dmidecode] /sys/firmware interface?

[Jean Delvare]

Hi Leif,

Sorry for the late answer.

On Mon, 17 Nov 2014 11:36:35 +0000, Leif Lindholm wrote:
> 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?

I took a quick look and I have to say I don't like
the /sys/firmware/dmi interface. I don't even understand how something
like that was accepted in the kernel. It is exposing half-decoded
information to user-space. Plugging dmidecode on top of it would
require writing extra code specifically to parse this half-decoded
information. And performance-wise, having to read a directory to look
for the entries and then opening several hundred files is really not
appealing.

> (And /sys/firmware/acpi for ACPI.)

Not sure why you mention that, as dmidecode doesn't care about ACPI at
all?

> 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?

The sole fact that you think it would require a library to
make /sys/firmware/dmi usable by user-space tools is IMHO a good hint
that the interface is screwed up.

I'd rather have the kernel export the 2 relevant memory chunks through
sysfs as raw, binary blobs. That way dmidecode could just fetch these
instead of reading from /dev/mem. This approach would require minimum
changes to dmidecode. I think Ivan Khoronzhuk (Cc'd) is actually
working on this?

-- 
Jean Delvare
SUSE L3 Support