linux-kernel - Re: [PATCH v1 0/6] google firmware support

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]

Date:	Wed, 26 Jan 2011 10:47:29 +0800
From:	Greg KH <greg@...ah.com>
To:	Mike Waychison <mikew@...gle.com>
Cc:	torvalds@...ux-foundation.org, San Mehat <san@...gle.com>,
	Aaron Durbin <adurbin@...gle.com>,
	Duncan Laurie <dlaurie@...gle.com>,
	linux-kernel@...r.kernel.org, Tim Hockin <thockin@...gle.com>
Subject: Re: [PATCH v1 0/6] google firmware support

On Tue, Jan 25, 2011 at 11:58:27AM -0800, Mike Waychison wrote:
> On Mon, Jan 24, 2011 at 7:01 PM, Greg KH <greg@...ah.com> wrote:
> > On Mon, Jan 24, 2011 at 04:24:34PM -0800, Mike Waychison wrote:
> >>
> >>    - [5] prepares for [6] by introducing prepend_to_dmesg() which
> >>      allows drivers to prepend pre-kernel messages to the dmesg at
> >>      bootup.
> >
> > That seems "rude".  Why can't you just pick out from the kernel log the
> > data you need when it gets printed?  This seems like you feel your code
> > should always get a "First Post!" message.
> 
> Well, the use case we have is that we prepend all the bios output (and
> anything emitted by option roms and boot loaders via int 10h).  This
> typically runs in the 100+ lines of output.
> 
> Basically, everything the user sees on the console after power up is
> available to him in the dmesg.  We did this out of convenience as it
> makes for a good looking log :)

That's a nice goal, but I don't think the kernel log is the proper place
for this.

> That said, it's dmesg, and we don't build automation on anything in
> there if we can help it.  I can move this memory console dump
> elsewhere (/sys/firmware/log ?)

Yes, /sys/firmware/log would be a great place for it.  Make it a binary
sysfs file, and just dump the firmware data right into it, not having
the kernel do anything with it at all.

Oh, and document the thing in Documentation/ABI please, so that other
platforms can take advantage of this interface as well in the future.

nice idea,

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/