Re: fwupdate

[Peter Jones]

On Mon, Mar 09, 2015 at 06:54:12PM -0700, Roy Franz wrote:
> On Mon, Mar 9, 2015 at 2:23 PM, Borislav Petkov <bp@xxxxxxxxx> wrote:
> > + pjones.
> >
> > So reportedly, there is already a capsule-loading thing which doesn't
> > need the kernel at all:
> >
> > https://github.com/rhinstaller/fwupdate
> >
> > So why are we even wasting energy with this discussion here?
> >
> > --
> > Regards/Gruss,
> >     Boris.
> 
> The network boot case can be taken care of as Peter described (ie
> taking network device paths, instead of just file paths), so
> this should work for those cases as well.  There would be some extra
> setup, as for this to work the EFI firmware update program
> would need to be run at boot (via the BootNext variable), but I don't
> think this is unreasonable.
> It looks like GnuEFI now supports Aarch64, so building the firmware
> update utility shouldn't be a problem.  Peter - have you you tried
> building
> this on Aarch64 yet?  If not I'll give it a try.

I tried a very early version of the code on an Aarch64 machine where I
also wrote the firmware feature, and it basically seemed to work, modulo
my buggy firmware ;)  I haven't tried it recently, but I do have all the
right makefile goo in there to build it reasonably, and I don't know of
any reason it wouldn't work.

That said, I haven't sent my patch to add the capsule headers to gnu-efi
yet, so you won't get very far - I'll make sure and send those this
week, hopefully today.  Also note that fwupdate is still a very active
work in progress; it's not /quite/ ready for general purpose deployment
even in a "trying it out" phase, but I'm hoping to get to that point
this week or next - in particular the code on github right now assumes
an HD() device path with a specific partition guid.

That is, it has literally worked on two machines ever.  Yes, it's a
thing we intend on supporting, but it's not /there/ yet.

> I think there is some value in using runtime update capsule calls, as
> that will help make sure the feature works in the firmware.  I think
> with arm64 servers in an early stage of development, we can influence
> the firmware support of various features by using them.  I don't know
> that this is a sufficient reason, but if runtime capsules are never
> used then there is a good chance that there will be many broken
> implementations.

That's certainly potentially valid, but it doesn't necessarily yield
something we (the OS vendor deploying features to customers) can
actually depend on.  Usually firmware features like this become
generally usable when there's some market maker causing hardware vendors
to have a large interest in making sure the feature works.  That means
most often the carrot being dangled is MS Logo certification marketing
dollars, and the testing all follows from the situations they require to
work.  So far, it appears MS has been using this only from Boot
Services, so that's what works.  

It looks to me like that's probably likely to remain true.  One reason
is peripheral cards.  My expectation (though possibly unfounded) is that
MS will require peripheral cards to use this same update mechanism for
option ROMs, and even if they don't I know some vendors are working on
it.  To do so, the card's UEFI driver (supplied on the option ROM) will
be using EFI's Firmware Management Protocol (FMP) to participate in the
capsule update system.

The 2.5 spec drafts that include FMP and UpdateCapsule() support for FMP
state that capsule updates for FMP aren't required to be available
during runtime - it expressly calls out the case where
CAPSULE_FLAGS_PERSIST_ACROSS_RESET is used.  (I don't think I'm allowed
to quote language from drafts in public, but if you have a copy, I'm
talking about the last paragraph of 22.2.1)  In my mind this means most
implementations are going to always try to do updates from before
ExitBootServices() for those option types - anything else and you're
just in an error case where you have to do that anyway.

So again, I'm not dead-set against having a kernel implementation, but I
think its use cases are severely constrained, and most of the time most
implementations will want to do this before the kernel loads.  The best
case for doing it in the kernel is embedded devices where a) there's no
persistent storage except the flash part you're updating anyway, and b)
the vendor nominally controls both the firmware and the deployed OS.

-- 
        Peter, heading back to the code.
--
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/