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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20110211012552.GA28995@kroah.com>
Date:	Thu, 10 Feb 2011 17:25:52 -0800
From:	Greg KH <greg@...ah.com>
To:	Mike Waychison <mikew@...gle.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Tim Hockin <thockin@...gle.com>,
	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 03:18:14PM -0800, Mike Waychison wrote:
> Hey guys,
> 
> I need some guidance. Do either of you know of any attempts to have
> the kernel decode and display/interact with DMI type 15: System
> Event Log?

I don't have any experience in this area, but I do have one comment on
your proposal below:

> The event log I'm dealing with while cleaning up the "gsmi" driver
> interacts with a log that is modeled after the System Event Log.
> I'm wondering if there is any precedent for a clean way to expose
> the event log, I'd like to use it (replacing the ioctls from my
> earlier patch series send-out).
> 
> FYI, we use OEM specific headers and descriptors, which probably
> doesn't help.
> 
> Do most folks that need access to this data rely on /dev/mem and
> dmidecode?  I'd like to avoid going that route if possible.
> 
> Lacking any better ideas though, I was thinking of something along
> the lines of the following:
> 
> 
> $ cat /sys/firmware/gsmi/eventlog
> <offset> <boot number> <recorded time> <quoted reason> <optional data>
> ...
> 
> with a single event log entry per line.
>   <offset> would be the record number,
>   <boot number> is the recorded boot number
>   <recorded time> comes from each record,
>   <quoted reason> is the English translation of Event Log Types from
> the DMTF standard + vendor extended types we use.
>   <optional data> is space separated values associated with <quoted reason>

Ick, no, remember, sysfs is "one value per file".  doing even a single
line like you describe here isn't ok, not to mention a huge buffer of
these lines.

And no, a "binary" sysfs file is not ok either.

Now your idea for such a log file is fine, I'm not saying that's not ok,
or acceptable, just don't put it in sysfs, sorry.  Try using the ring
buffer framework from the tracing code perhaps?

Or use debugfs?  Or make a 'firmwarefs'?  I can easily knock that
together if you need it.

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/