linux-kernel - Re: [PATCH v4 1/2] firmware_loader: introduce new API

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: <20150415101455.GB4804@codeblueprint.co.uk>
Date:	Wed, 15 Apr 2015 11:14:55 +0100
From:	Matt Fleming <matt@...eblueprint.co.uk>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Kweh, Hock Leong" <hock.leong.kweh@...el.com>,
	Ming Lei <ming.lei@...onical.com>,
	Ong Boon Leong <boon.leong.ong@...el.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	Sam Protsenko <semen.protsenko@...aro.org>,
	Peter Jones <pjones@...hat.com>,
	Roy Franz <roy.franz@...aro.org>
Subject: Re: [PATCH v4 1/2] firmware_loader: introduce new API -
 request_firmware_direct_full_path()

On Tue, 14 Apr, at 06:18:33PM, Borislav Petkov wrote:
> On Tue, Apr 14, 2015 at 11:56:26AM -0400, Andy Lutomirski wrote:
> > This is why I think that the right approach would be to avoid using
> > firmware_class entirely for this.  IMO a simple_char device would be
> > the way to go (hint hint...) but other simple approaches are certainly
> > possible.
> 
> Btw, didn't mfleming want to try using capsules for other funky stuff
> like early logging and pstore-like logging in panic time so that we can
> read out crash data on the next boot?
 
Yeah, exactly. Being able to pass random data blobs to the capsule
internals allows the kernel to support cool things we haven't conceived
of yet, and where we want to use the capsule's in-memory persistence
across reboot to pass data to the next kernel.

The panic code paths is just one example.

> Which would mean that capsules would need a completely different
> interface, something new for shuffling lotsa binary data in and out of
> the kernel and in and out of the UEFI...
> 
> Which would make the firmware_class thing completely inappropriate for
> that.

Well, I haven't come across a scenario where you need a brand new
interface for getting it *out* of the kernel again. And I'm happy enough
with these patches for passing data in.

-- 
Matt Fleming, Intel Open Source Technology Center
--
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/