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: <AANLkTimrm5zFxA++0ZgXL7csJSU17TgDx5Qb_3RdtzBU@mail.gmail.com>
Date:	Fri, 11 Feb 2011 10:56:16 -0800
From:	Mike Waychison <mikew@...gle.com>
To:	Greg KH <greg@...ah.com>
Cc:	Tim Hockin <thockin@...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 Fri, Feb 11, 2011 at 10:32 AM, Greg KH <greg@...ah.com> wrote:
> On Fri, Feb 11, 2011 at 10:00:37AM -0800, Mike Waychison wrote:
>> resend as plain text, sorry :(
>>
>>
>> On Thu, Feb 10, 2011 at 7:20 PM, Greg KH <greg@...ah.com> wrote:
>> > 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.
>> >
>>
>> If you mean s/hardware/firmware/, then yes.
>
> Yes, sorry, that is what I ment.
>
>> > 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?
>>
>> Yup, exposing the log via a bin_attribute and allowing for blobs to be
>> appended (with the firmware either accepting or rejecting the format
>> will do).
>
> Great, that should be a simple thing to do then, right?

Ya.  Here's what I'm working on now:

/sys/firmware/gsmi/eventlog
  - read: reads out binary bytes of the log as exported by firmware.
  - write: takes the user buffer and passes it on to the firmware via
a SET_EVENT_LOG command and returns a mapped errno to the user.

/sys/firmware/gsmi/clear_eventlog
  - write-only: takes a value between 0 and 100 and passes it to the
firmware to clear out a percentage of the log.

/sys/firmware/gsmi/clear_config
  - write-only: takes arbitrary data and tells the firmware to wipe it's config.

/sys/firmware/gsmi/vars (directory)
  - same code as /sys/firmware/efi/vars except firmware calls vector
through gsmi instead of the EFI runtime services page  (I've
abstracted it out for re-use)

This covers the gsmi driver and removes the ioctls completely from it.


I've already changed the "memconsole" driver I sent out a while ago to
export itself as an untouched binary file /sys/firmware/log .

The only bit that remains that needs cleaning is the 'bootlog' driver.
  I'm going to work with Robert offline (or online if he wants to
follow up here) with what "proper" kernel interfaces should look like
for his purposes.
--
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/