linux-kernel - Re: [PATCH v2 11/12] driver: Google EFI SMI

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: <AANLkTinNvq0Y6=nxDaBP1uDR-SwdGX65yP1HiBHwpa4L@mail.gmail.com>
Date:	Mon, 14 Mar 2011 14:09:33 -0700
From:	Mike Waychison <mikew@...gle.com>
To:	Greg KH <greg@...ah.com>
Cc:	Matt Domsch <Matt_Domsch@...l.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Duncan Laurie <dlaurie@...gle.com>,
	Aaron Durbin <adurbin@...gle.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org, Tim Hockin <thockin@...gle.com>,
	San Mehat <san@...gle.com>
Subject: Re: [PATCH v2 11/12] driver: Google EFI SMI

On Mon, Mar 14, 2011 at 1:13 PM, Greg KH <greg@...ah.com> wrote:
> On Mon, Mar 14, 2011 at 01:01:50PM -0700, Mike Waychison wrote:
>> On Mon, Mar 14, 2011 at 8:47 AM, Greg KH <greg@...ah.com> wrote:
>> > On Fri, Mar 11, 2011 at 05:43:53PM -0800, Mike Waychison wrote:
>> >> The "gsmi" driver bridges userland with firmware specific routines for
>> >> accessing hardware.
>> >
>> > As with the other driver in this series, what keeps this driver from
>> > being loaded on hardware that does not support this functionality?  If
>> > it is loaded, will it cause bad things to happen?
>>
>> gsmi itself is better guarded than the memconsole driver that the x86
>> maintainers objected to.
>>
>> It relies on keying off of a couple different strings, looking for
>> "GOOGLE" as either the OEM ID in the  FADT table, or "Google, Inc." as
>> the board vendor.  We further discriminate whether the driver should
>> load (it doesn't apply to all of our boards) with a couple other
>> checks.  See gsmi_system_valid().  I've added a comment to the patch
>> description indicating this for the upcoming v3 send-out.
>
> Ok, fair enough.  I'm guessing that you have tried testing the module by
> loading it in a machine where this doesn't work?
>
>> > Also, what causes it to be loaded on hardware that needs it?  There
>> > should be some MODULE_DEVICE_TABLE somewhere in this thing to cause it
>> > to be autoloaded?
>>
>> I don't know if there is a good way to have this guy autoloaded, but
>> that's probably fine. We will likely compile it in as a built-in or
>> adjust our userland to have the module loaded.  We use it on all
>> machines we've been building for the last 4-5 years, and a table of
>> device IDs would just contain a list of a bunch of parts that aren't
>> really google-specific.
>
> What's wrong with using DMI strings?  Are there going to be that many
> different ones of them here?

DMI strings would probably work.  I totally missed the fact that I
could use them for MODULE_DEVICE_TABLE.  Let me re-work patch 11 and
12 to use this matching stuff.
--
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/