linux-kernel - Re: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface

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: <20150306213912.GA8020@fenchurch.internal.datastacks.com>
Date:	Fri, 6 Mar 2015 16:39:12 -0500
From:	Peter Jones <pjones@...hat.com>
To:	"Kweh, Hock Leong" <hock.leong.kweh@...el.com>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Sam Protsenko <semen.protsenko@...aro.org>,
	Matt Fleming <matt@...sole-pimps.org>,
	Ming Lei <ming.lei@...onical.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Ong, Boon Leong" <boon.leong.ong@...el.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>
Subject: Re: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface

On Tue, Feb 24, 2015 at 12:49:09PM +0000, Kweh, Hock Leong wrote:
> Hi All,
> 
> After some internal discussion and re-design prototyping & testing on
> this efi capsule interface kernel module, I would like to start a discussion
> here on the new idea and wish to get input for the implementation and
> eventually upstream.

So do we actually *need* a kernel interface to UpdateCapsule?  We've
already got an implementation in progress where we use my ESRT patch to
figure out what firmwares we can update, and we schedule them and do the
update during boot up before the normal bootloader is run.  That means
never having to call UpdateCapsule() after ExitBootServices() or
SetVirtualAddressMap() have been called, and only doing it across
reboots that UEFI is performing itself.  It also means never having to
do it with multiple CPUs running.

I've posted several revisions of the ESRT patch to linux-efi , and right
now we're just waiting on the UEFI 2.5 spec to be finalized before I
send a final copy to Matt.  The command line tool and the code to apply
the firmwares during boot are at https://github.com/rhinstaller/fwupdate
and there's a GNOME-based UI in progress at
https://github.com/hughsie/fwupd (yes we apparently stink at naming
things.)

I'm not sure how making this go through the kernel will make things
better - it introduces a lot more things that can go wrong, and the only
benefit is one reboot where BootNext is set - which actually is
relatively fast even slow-POSTing machines.  After that the
UpdateCapsule+reboot to apply is *extremely* fast, because
applying capsule updates have to happen very very early in the boot-up
sequence.  (That early processing is /effectively/ a requirement,
since it has to happen before the block write locking on the SPI part is
done.)  So even on the machine that takes quite some time to POST, the
time that would be saved saved is less than 1% or so of the total update
time.

An early version of my code worked to update a machine I got from your
employer, FWIW - right now we're adding API and fixing up implementation
bits I made specifically to that one proof-of-concept scenario, and
there's some API parts that are in UEFI 2.5 draft releases that we're
not quite handling yet.  However, there's code there that's already been
checked in which has successfully applied system firmware updates
without having a kernel interface to UpdateCapsule().

So again: do we really need or want to do this?

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