linux-kernel - Re: [PATCH v1 3/6] 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:	Thu, 27 Jan 2011 18:56: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 3/6] driver: Google EFI SMI

On Thu, Jan 27, 2011 at 03:41:06PM -0800, Mike Waychison wrote:
> On Wed, Jan 26, 2011 at 5:22 PM, Mike Waychison <mikew@...gle.com> wrote:
> > On Wed, Jan 26, 2011 at 3:58 PM, Mike Waychison <mikew@...gle.com> wrote:
> >> On Tue, Jan 25, 2011 at 6:46 PM, Greg KH <greg@...ah.com> wrote:
> >>> So, let me ask, what specifically are you wanting to import/export
> >>> to/from the kernel here?  Have you thought about other kernel/user apis
> >>> instead of ioctls?  What is forcing you to use ioctls?
> >>
> >> I'm not sure if you are trying to suggest that there is a better way
> >> to solve these problems without actually saying so.  We could probably
> >> use a different interface, sure.
> >>
> >
> > Well, I managed to find efivars.c, and it seems like I can probably
> > massage it to do what I want as several of the calls I'd like to
> > export to userland mirror portions of the EFI runtime services page.
> > That won't take care of all of the firmware calls I'd like to export,
> > but it's a start.
> >
> 
> I've spent the last few hours looking at efivars.c and working out how
> I can refactor it to reuse all the kobject bits it uses.  Does anybody
> use this thing though?
> 
> I can't believe I was just lectured for crappy ABI when this thing
> takes a binary packed struct on write() and process it:
>    - without regard to write length, and
>    - in a way that isn't compatible across compat (both DataSize and
> Status are unsigned long!).

It should just be passing that data straight to the hardware and not
trying to process the data at all, right?  If not, then it needs to be
fixed and not use the firmware binary interface...

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/