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]

Date:	Mon, 14 Mar 2011 13:13:46 -0700
From:	Greg KH <greg@...ah.com>
To:	Mike Waychison <mikew@...gle.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 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?

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/