Re: [PATCH v1 2/5] firmware: Basic dmi-sysfs support

On Tue, Feb 22, 2011 at 3:49 PM, Rob Lippert [off-list ref] wrote:

On Thu, Feb 17, 2011 at 1:28 PM, Mike Waychison [off-list ref] wrote:

quoted

Introduce a new module "dmi-sysfs" that exports the broken out entries
of the DMI table through sysfs.

Entries are enumerated via dmi_walk() on module load, and are populated
as kobjects rooted at /sys/firmware/dmi/entries.

Entries are named "<type>-<instance>", where:
  <type>       : is the type of the entry, and
  <instance>   : is the ordinal count within the DMI table of that
                 entry type.  This instance is used in lieu the DMI
                 entry's handle as no assurances are made by the kernel
                 that handles are unique.

All entries export the following attributes:

Can you add an entry here for index/ordinal in the set of all tables?
This way the user can walk the tables in the original order exported
by the BIOS.  Some (buggy) BIOSes don't properly set up links between
things like MEM_ARRAY and MEM_DEVICE tables but depend on the position
of the table relative to other tables.

Oh weird.  I can add an attribute called "position" if that works?
I'd rather not put the position in the directory name itself if I can
help it though, it just looks -- odd.

quoted

+/*
+ * Calculate and return the byte length of the dmi entry identified by
+ * dh.  This includes both the formatted portion as well as the
+ * unformatted string space, including the two trailing nul characters.
+ */
+static size_t dmi_entry_length(const struct dmi_header *dh)
+{
+       const char *p = (const char *)dh;
+
+       p += dh->length;
+
+       while (p[0] || p[1])
+               p++;
+

Is there any chance this could walk outside of SMBIOS space on a
corrupted table?  I can point you at some machines with corrupted
tables to test on if you want.

AFAICT, this should be safe to do.  dmi_table() is the code that
iterates through the table of entries, and will not callback any
entries if it can't find the double nul characters within dmi_len
bytes (as described by the dmi table header).

I'd be happy to test this on machines that get it wrong though.  Just
add me to the auth files and IM me the hostnames :)