[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dmidecode] /sys/firmware interface?
From: |
Jean Delvare |
Subject: |
Re: [dmidecode] /sys/firmware interface? |
Date: |
Thu, 5 Feb 2015 10:58:39 +0100 |
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
- Re: [dmidecode] /sys/firmware interface?,
Jean Delvare <=
Re: [dmidecode] /sys/firmware interface?, David Sommerseth, 2015/02/05