On Fri, Mar 06, 2015 at 01:49:20PM -0800, Roy Franz wrote: > On Fri, Mar 6, 2015 at 1:39 PM, Peter Jones <pjo...@redhat.com> 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)
One of the things I'm currently writing is making the file we load be specified correctly by UEFI device paths - and that'll include the ability to get it from devices presented by the network drivers. On currently extant test machines that includes tftp support, just like netbooting. On UEFI 2.5 machines, where ESRT is introduced so that we actually know something about the capsules we can apply updates for, it also includes http support. Admittedly that means when you're doing deployment you'll have to have some process for putting the images someplace, but it can be the same device you're net-booting from. Just one example. If we're talking about systems that are booting entirely out of their own firmware volume, there's definitely some legitimate argument that doing this without an ESP could be valuable - so yeah, a kernel API in that case might be worthwhile. That said, the extra complexity combined with the fact that it's running after ExitBootServices() and SetVirtualAddressMap() means I'll probably avoid using it from the userland code except on machines where there are no other options. My faith that we're going to see a lot of machines where that's well tested without our address maps looking exactly like Windows's isn't very high, and we've repeatedly run into a lot of pain with that in the past. That's not the only thing that has to be exactly right, either - for instance there's no guarantee it'll work if you use the ACPI reset vector instead of the EFI runtime services ResetSystem(EfiResetWarm) call. Right now we use the ACPI method preferentially because of SetVirtualAddressMap() not working as documented on so *many* platforms. That means what happens upon reboot when we do UpdateCapsule() is undefined behavior. Of course I'm likely not the only person who will ever implement tools in userland to orchestrate firmware updates, either :) > 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. I'm really not sure if we know the answer to that yet. Things like USB devices most often won't ever be registered with firmware's FMP anyway, so they won't have capsules exposed, and they'll use more traditional USB commands to do firmware updates - stuff like hughsie's ColorHug device are in that category, and he's already supporting that with fwupd. Things like peripheral card option ROMs are potentially in that category, though I'm a little skeptical of the idea that I actually want to update the firmware on my video or network card with the kernel already running, and that when I do I'm not going to want to reboot immediately to make sure it worked right anyway. There are almost certainly lots of cases I haven't thought of, though. If we want this interface for those cases, I think we should also be enumerating the cases we think it's supporting, as well, even if only in broad strokes. I don't think we need to say "support this specific device's updates", but keeping track of the basic model of the update we're supporting would go a long way to establishing the value of supporting all the complexity. -- Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/