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

[Roy Franz]

On Fri, Mar 6, 2015 at 1:39 PM, Peter Jones <pjones@xxxxxxxxxx> wrote:
> 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.

So this does it by writing the capsules to the EFI system partition, and having
them processed from there during the next boot?
How would this work on diskless systems? (or boot-disk-less systems)

What are the use cases for capsules that don't require a reboot?  I'm not
really clear uses for those, but the kernel interface could be better for those,
as it would allow processing without a reboot.

Roy

>
> 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-efi" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/