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: <AANLkTikhhYv2=memo-Rkhh1pG3v4-edrUROTgLoc6cbd@mail.gmail.com>
Date:	Mon, 14 Mar 2011 13:01:50 -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 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.

>
> 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.
--
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/