linux-kernel - Re: SMBIOS / DMI Event Logs in Linux?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110211032049.GB884@kroah.com>
Date:	Thu, 10 Feb 2011 19:20:49 -0800
From:	Greg KH <greg@...ah.com>
To:	Tim Hockin <thockin@...gle.com>
Cc:	Mike Waychison <mikew@...gle.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Robert Lippert <rlippert@...gle.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: SMBIOS / DMI Event Logs in Linux?

On Thu, Feb 10, 2011 at 06:20:52PM -0800, Tim Hockin wrote:
> Caveat: I kind of loathe the proliferation of single use filesystems
> for things that just aren't well mapped to the model.
> 
> That said, maybe smbiosfs is not so horrible of a mapping.  I'm
> reticent to dredge up my spec, but I think it fits well enough, and
> you can can leave most OEM-specific processing in userspace.
> 
> So for the type 15, something like:
> 
> /smbios/              # mountpoint
>     15/                  # record type (decimal)
>         0/                # instance number (decimal)
>             change_token # change token from the type 15 struct
>             header    # binary dump of the header section (if present)
>             0/            # one dir for each record (decimal)
>                 id        # event ID (decimal)
>                 id_str  # event ID (stringified, if possible)
>                 size    # event size (decimal, bytes)
>                 timestamp   # year, month, day, hour, minute, second
>                 data   # binary dump of the payload
>                 raw    # binary dump of the whole event
> 
> This does not handle type descriptors, but I know *we* don't use them..
> 
> This does not address operations such as clearing the log or writing a
> new event or locking/unlocking the log.  If there's an OEM-specific
> driver loaded it could augment the above.
> 
>             clear_log       # write a number to this to clear some
> percent of the log
>             write_events # write a binary dump of an event, including timestamp?
> 
> I don't hate it.  IT would be cool to have all of SMBIOS available this way.
> 
> I'm not sure its worth the work, though.  Most Type 15 logs are in
> memory-mapped ROM or in RAM, so tools can access it via /dev/mem (if
> you have privs to do so).

Wait, if this is just a simple "pass through to the hardware", then just
export the thing, with the proper permissions, in a single binary sysfs
file, and do the parsing in userspace.

That would be the simplest thing to do, and fit the rules for valid
sysfs files, and keep people from having to dig through /dev/mem, right?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/