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

[Mike Waychison]

On Tue, Feb 22, 2011 at 3:49 PM, Rob Lippert <rlippert@xxxxxxxxxx> wrote:
> On Thu, Feb 17, 2011 at 1:28 PM, Mike Waychison <mikew@xxxxxxxxxx> wrote:
>> 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.

>> +/*
>> + * 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 :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/