RE: [PATCH v2 0/3] Enable user helper interface for efi capsule update
> -Original Message- > From: Fleming, Matt > Sent: Tuesday, November 04, 2014 10:08 PM > To: Greg Kroah-Hartman > > > > Good point, I don't know. > > > > Who ever wrote this code should know this, can someone please provide > > a use-case for how this is all supposed to work? > > That would be Wilson. He's wanting to use this to send updates to the > firmware on the Intel Quark, I think. Hi Matt, I believe Greg already got that from the commit message on my patch 3/3. Thanks. Regards, Wilson
Re: [PATCH v2 0/3] Enable user helper interface for efi capsule update
On Mon, 2014-11-03 at 16:38 -0800, Greg Kroah-Hartman wrote: > > Good point, I don't know. > > Who ever wrote this code should know this, can someone please provide a > use-case for how this is all supposed to work? That would be Wilson. He's wanting to use this to send updates to the firmware on the Intel Quark, I think. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] Enable user helper interface for efi capsule update
On Mon, Nov 3, 2014 at 4:38 PM, Greg Kroah-Hartman wrote: > On Mon, Nov 03, 2014 at 03:08:08PM -0800, Andy Lutomirski wrote: >> On Mon, Nov 3, 2014 at 3:02 PM, Greg Kroah-Hartman >> wrote: >> > On Mon, Nov 03, 2014 at 01:32:46PM -0800, Andy Lutomirski wrote: >> >> On Mon, Nov 3, 2014 at 1:27 PM, Greg Kroah-Hartman >> >> wrote: >> >> > On Mon, Nov 03, 2014 at 11:33:23AM -0800, Andy Lutomirski wrote: >> >> >> On 11/02/2014 07:07 PM, Kweh Hock Leong wrote: >> >> >> > From: "Kweh, Hock Leong" >> >> >> > >> >> >> > >> >> >> > Hi Guys, >> >> >> > >> >> >> > This patchset is created on top of "efi: Capsule update support" >> >> >> > patch: >> >> >> > http://permalink.gmane.org/gmane.linux.kernel.efi/4837 >> >> >> > >> >> >> > It leverages the request_firmware_nowait() to expose the user helper >> >> >> > interface for user to upload the capsule binary and calling the >> >> >> > efi_capsule_update() API to pass the binary to EFI firmware. >> >> >> >> >> >> I don't get it. Why is the firmware interface at all reasonable for >> >> >> uploading capsules? >> >> > >> >> > Tradition dictates that BIOS updates go through the firmware interface, >> >> > that way you don't have to write a new userspace tool, which is a good >> >> > thing. >> >> > >> >> >> The firmware interface makes sense for nonvolatile firmware where >> >> >> hotplugging something or otherwise loading a driver needs a blob. >> >> > >> >> > Or BIOS data. We've been doing it this way for a long time now. >> >> >> >> On what system? Dell? >> > >> > Yes. >> > >> >> IMO this sucks from a UI point of view. When I install wifi firmware, >> >> I expect to stick it somewhere and have the driver find it, because >> >> the driver knows exactly when it needs the firmware. When I update my >> >> BIOS, I want to click a button or type a command and update my bios. >> > >> > I agree, it should be "triggered" by something, not just automagically >> > loaded whenever the kernel randomly looks for it. >> > >> >> >> But uploading an EFI capsule is an *action*, not something that should >> >> >> happen transparently. If there's an EFI firmware update available and >> >> >> the user wants to install it, then the userspace tool should install >> >> >> it, >> >> >> and it shouldn't hang around in /lib/firmware. In fact, you shouldn't >> >> >> even need /lib to be on writable media to use this. >> >> > >> >> > What does /lib have to do with this? >> >> >> >> Where else does the file come from, given that udev no longer supports >> >> userspace firmware loading? Is there really some pre-existing tool >> >> that pokes it into the sysfs firmware class thing? >> > >> > Well, you can specify other locations than /lib/firmware/ for firmware >> > updates, but yes, you are right, it should be in /lib somewhere. But >> > /lib doesn't need to be writable, it's a read-only file. >> > >> >> I assume that whoever downloaded the firmware update will want to >> install it, right? I don't really expect distros to ship EFI capsules >> in packages that install to /lib/firmware. Won't there be userspace >> code that either installs a capsule from some URL or uses some future >> magical find-my-firmware service? > > Good point, I don't know. > > Who ever wrote this code should know this, can someone please provide a > use-case for how this is all supposed to work? There's a partial description here: http://download.microsoft.com/download/5/f/5/5f5d16cd-2530-4289-8019-94c6a20bed3c/windows-uefi-firmware-update-platform.docx It looks like there may need to be a way to atomically load several capsules in the same UpdateCapsule call so that userspace can do fancy things like ask for an image to be displayed while the update is applied. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] Enable user helper interface for efi capsule update
On Mon, Nov 03, 2014 at 03:08:08PM -0800, Andy Lutomirski wrote: > On Mon, Nov 3, 2014 at 3:02 PM, Greg Kroah-Hartman > wrote: > > On Mon, Nov 03, 2014 at 01:32:46PM -0800, Andy Lutomirski wrote: > >> On Mon, Nov 3, 2014 at 1:27 PM, Greg Kroah-Hartman > >> wrote: > >> > On Mon, Nov 03, 2014 at 11:33:23AM -0800, Andy Lutomirski wrote: > >> >> On 11/02/2014 07:07 PM, Kweh Hock Leong wrote: > >> >> > From: "Kweh, Hock Leong" > >> >> > > >> >> > > >> >> > Hi Guys, > >> >> > > >> >> > This patchset is created on top of "efi: Capsule update support" > >> >> > patch: > >> >> > http://permalink.gmane.org/gmane.linux.kernel.efi/4837 > >> >> > > >> >> > It leverages the request_firmware_nowait() to expose the user helper > >> >> > interface for user to upload the capsule binary and calling the > >> >> > efi_capsule_update() API to pass the binary to EFI firmware. > >> >> > >> >> I don't get it. Why is the firmware interface at all reasonable for > >> >> uploading capsules? > >> > > >> > Tradition dictates that BIOS updates go through the firmware interface, > >> > that way you don't have to write a new userspace tool, which is a good > >> > thing. > >> > > >> >> The firmware interface makes sense for nonvolatile firmware where > >> >> hotplugging something or otherwise loading a driver needs a blob. > >> > > >> > Or BIOS data. We've been doing it this way for a long time now. > >> > >> On what system? Dell? > > > > Yes. > > > >> IMO this sucks from a UI point of view. When I install wifi firmware, > >> I expect to stick it somewhere and have the driver find it, because > >> the driver knows exactly when it needs the firmware. When I update my > >> BIOS, I want to click a button or type a command and update my bios. > > > > I agree, it should be "triggered" by something, not just automagically > > loaded whenever the kernel randomly looks for it. > > > >> >> But uploading an EFI capsule is an *action*, not something that should > >> >> happen transparently. If there's an EFI firmware update available and > >> >> the user wants to install it, then the userspace tool should install it, > >> >> and it shouldn't hang around in /lib/firmware. In fact, you shouldn't > >> >> even need /lib to be on writable media to use this. > >> > > >> > What does /lib have to do with this? > >> > >> Where else does the file come from, given that udev no longer supports > >> userspace firmware loading? Is there really some pre-existing tool > >> that pokes it into the sysfs firmware class thing? > > > > Well, you can specify other locations than /lib/firmware/ for firmware > > updates, but yes, you are right, it should be in /lib somewhere. But > > /lib doesn't need to be writable, it's a read-only file. > > > > I assume that whoever downloaded the firmware update will want to > install it, right? I don't really expect distros to ship EFI capsules > in packages that install to /lib/firmware. Won't there be userspace > code that either installs a capsule from some URL or uses some future > magical find-my-firmware service? Good point, I don't know. Who ever wrote this code should know this, can someone please provide a use-case for how this is all supposed to work? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] Enable user helper interface for efi capsule update
On Mon, Nov 3, 2014 at 3:02 PM, Greg Kroah-Hartman
wrote:
> On Mon, Nov 03, 2014 at 01:32:46PM -0800, Andy Lutomirski wrote:
>> On Mon, Nov 3, 2014 at 1:27 PM, Greg Kroah-Hartman
>> wrote:
>> > On Mon, Nov 03, 2014 at 11:33:23AM -0800, Andy Lutomirski wrote:
>> >> On 11/02/2014 07:07 PM, Kweh Hock Leong wrote:
>> >> > From: "Kweh, Hock Leong"
>> >> >
>> >> >
>> >> > Hi Guys,
>> >> >
>> >> > This patchset is created on top of "efi: Capsule update support" patch:
>> >> > http://permalink.gmane.org/gmane.linux.kernel.efi/4837
>> >> >
>> >> > It leverages the request_firmware_nowait() to expose the user helper
>> >> > interface for user to upload the capsule binary and calling the
>> >> > efi_capsule_update() API to pass the binary to EFI firmware.
>> >>
>> >> I don't get it. Why is the firmware interface at all reasonable for
>> >> uploading capsules?
>> >
>> > Tradition dictates that BIOS updates go through the firmware interface,
>> > that way you don't have to write a new userspace tool, which is a good
>> > thing.
>> >
>> >> The firmware interface makes sense for nonvolatile firmware where
>> >> hotplugging something or otherwise loading a driver needs a blob.
>> >
>> > Or BIOS data. We've been doing it this way for a long time now.
>>
>> On what system? Dell?
>
> Yes.
>
>> IMO this sucks from a UI point of view. When I install wifi firmware,
>> I expect to stick it somewhere and have the driver find it, because
>> the driver knows exactly when it needs the firmware. When I update my
>> BIOS, I want to click a button or type a command and update my bios.
>
> I agree, it should be "triggered" by something, not just automagically
> loaded whenever the kernel randomly looks for it.
>
>> >> But uploading an EFI capsule is an *action*, not something that should
>> >> happen transparently. If there's an EFI firmware update available and
>> >> the user wants to install it, then the userspace tool should install it,
>> >> and it shouldn't hang around in /lib/firmware. In fact, you shouldn't
>> >> even need /lib to be on writable media to use this.
>> >
>> > What does /lib have to do with this?
>>
>> Where else does the file come from, given that udev no longer supports
>> userspace firmware loading? Is there really some pre-existing tool
>> that pokes it into the sysfs firmware class thing?
>
> Well, you can specify other locations than /lib/firmware/ for firmware
> updates, but yes, you are right, it should be in /lib somewhere. But
> /lib doesn't need to be writable, it's a read-only file.
>
I assume that whoever downloaded the firmware update will want to
install it, right? I don't really expect distros to ship EFI capsules
in packages that install to /lib/firmware. Won't there be userspace
code that either installs a capsule from some URL or uses some future
magical find-my-firmware service?
>> Since EFI capsules are apparently on their way to becoming a
>> ubiquitous mechanism, I think it might be time to rethink
>> request_firmware for this.
>
> What do you suggest instead? A "custom" sysfs file? What is going to
> trigger it to be loaded? A userspace script that someone else has to
> write? :)
Some ioctl on /dev/efi_capsule seems reasonable to me, or a new script
that uses a custom sysfs file. Isn't the Dell thing already a rather
custom script? You write to a custom sysfs file ("rbu_image_type", I
think) and then the handler for that file calls request_firmware.
I think that we can handle a very small C program or script that
uploads the EFI capsule.
Also, FWIW, I think that there are EFI capsules that aren't firmware
updates. For example, IIRC there's some mechansim that allows you to
pass data to the next OS that boots via a capsule. It's probably
buggy on every motherboard in existence, but if it ever worked, using
it through /lib/firmware would make no sense.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] Enable user helper interface for efi capsule update
On Mon, Nov 03, 2014 at 01:32:46PM -0800, Andy Lutomirski wrote: > On Mon, Nov 3, 2014 at 1:27 PM, Greg Kroah-Hartman > wrote: > > On Mon, Nov 03, 2014 at 11:33:23AM -0800, Andy Lutomirski wrote: > >> On 11/02/2014 07:07 PM, Kweh Hock Leong wrote: > >> > From: "Kweh, Hock Leong" > >> > > >> > > >> > Hi Guys, > >> > > >> > This patchset is created on top of "efi: Capsule update support" patch: > >> > http://permalink.gmane.org/gmane.linux.kernel.efi/4837 > >> > > >> > It leverages the request_firmware_nowait() to expose the user helper > >> > interface for user to upload the capsule binary and calling the > >> > efi_capsule_update() API to pass the binary to EFI firmware. > >> > >> I don't get it. Why is the firmware interface at all reasonable for > >> uploading capsules? > > > > Tradition dictates that BIOS updates go through the firmware interface, > > that way you don't have to write a new userspace tool, which is a good > > thing. > > > >> The firmware interface makes sense for nonvolatile firmware where > >> hotplugging something or otherwise loading a driver needs a blob. > > > > Or BIOS data. We've been doing it this way for a long time now. > > On what system? Dell? Yes. > IMO this sucks from a UI point of view. When I install wifi firmware, > I expect to stick it somewhere and have the driver find it, because > the driver knows exactly when it needs the firmware. When I update my > BIOS, I want to click a button or type a command and update my bios. I agree, it should be "triggered" by something, not just automagically loaded whenever the kernel randomly looks for it. > >> But uploading an EFI capsule is an *action*, not something that should > >> happen transparently. If there's an EFI firmware update available and > >> the user wants to install it, then the userspace tool should install it, > >> and it shouldn't hang around in /lib/firmware. In fact, you shouldn't > >> even need /lib to be on writable media to use this. > > > > What does /lib have to do with this? > > Where else does the file come from, given that udev no longer supports > userspace firmware loading? Is there really some pre-existing tool > that pokes it into the sysfs firmware class thing? Well, you can specify other locations than /lib/firmware/ for firmware updates, but yes, you are right, it should be in /lib somewhere. But /lib doesn't need to be writable, it's a read-only file. > Since EFI capsules are apparently on their way to becoming a > ubiquitous mechanism, I think it might be time to rethink > request_firmware for this. What do you suggest instead? A "custom" sysfs file? What is going to trigger it to be loaded? A userspace script that someone else has to write? :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] Enable user helper interface for efi capsule update
On Mon, Nov 3, 2014 at 1:27 PM, Greg Kroah-Hartman wrote: > On Mon, Nov 03, 2014 at 11:33:23AM -0800, Andy Lutomirski wrote: >> On 11/02/2014 07:07 PM, Kweh Hock Leong wrote: >> > From: "Kweh, Hock Leong" >> > >> > >> > Hi Guys, >> > >> > This patchset is created on top of "efi: Capsule update support" patch: >> > http://permalink.gmane.org/gmane.linux.kernel.efi/4837 >> > >> > It leverages the request_firmware_nowait() to expose the user helper >> > interface for user to upload the capsule binary and calling the >> > efi_capsule_update() API to pass the binary to EFI firmware. >> >> I don't get it. Why is the firmware interface at all reasonable for >> uploading capsules? > > Tradition dictates that BIOS updates go through the firmware interface, > that way you don't have to write a new userspace tool, which is a good > thing. > >> The firmware interface makes sense for nonvolatile firmware where >> hotplugging something or otherwise loading a driver needs a blob. > > Or BIOS data. We've been doing it this way for a long time now. On what system? Dell? IMO this sucks from a UI point of view. When I install wifi firmware, I expect to stick it somewhere and have the driver find it, because the driver knows exactly when it needs the firmware. When I update my BIOS, I want to click a button or type a command and update my bios. > >> But uploading an EFI capsule is an *action*, not something that should >> happen transparently. If there's an EFI firmware update available and >> the user wants to install it, then the userspace tool should install it, >> and it shouldn't hang around in /lib/firmware. In fact, you shouldn't >> even need /lib to be on writable media to use this. > > What does /lib have to do with this? Where else does the file come from, given that udev no longer supports userspace firmware loading? Is there really some pre-existing tool that pokes it into the sysfs firmware class thing? Since EFI capsules are apparently on their way to becoming a ubiquitous mechanism, I think it might be time to rethink request_firmware for this. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] Enable user helper interface for efi capsule update
On Mon, Nov 03, 2014 at 11:33:23AM -0800, Andy Lutomirski wrote: > On 11/02/2014 07:07 PM, Kweh Hock Leong wrote: > > From: "Kweh, Hock Leong" > > > > > > Hi Guys, > > > > This patchset is created on top of "efi: Capsule update support" patch: > > http://permalink.gmane.org/gmane.linux.kernel.efi/4837 > > > > It leverages the request_firmware_nowait() to expose the user helper > > interface for user to upload the capsule binary and calling the > > efi_capsule_update() API to pass the binary to EFI firmware. > > I don't get it. Why is the firmware interface at all reasonable for > uploading capsules? Tradition dictates that BIOS updates go through the firmware interface, that way you don't have to write a new userspace tool, which is a good thing. > The firmware interface makes sense for nonvolatile firmware where > hotplugging something or otherwise loading a driver needs a blob. Or BIOS data. We've been doing it this way for a long time now. > But uploading an EFI capsule is an *action*, not something that should > happen transparently. If there's an EFI firmware update available and > the user wants to install it, then the userspace tool should install it, > and it shouldn't hang around in /lib/firmware. In fact, you shouldn't > even need /lib to be on writable media to use this. What does /lib have to do with this? > And you most certainly don't want the EFI capsule hanging around so that > it might be accidentally installed again if the hard disk is moved. > > ISTM there should be some file in sysfs to which you can write a > capsule, or perhaps a chardev and an ioctl. No, just use the firmware interface please. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] Enable user helper interface for efi capsule update
On 11/02/2014 07:07 PM, Kweh Hock Leong wrote: > From: "Kweh, Hock Leong" > > > Hi Guys, > > This patchset is created on top of "efi: Capsule update support" patch: > http://permalink.gmane.org/gmane.linux.kernel.efi/4837 > > It leverages the request_firmware_nowait() to expose the user helper > interface for user to upload the capsule binary and calling the > efi_capsule_update() API to pass the binary to EFI firmware. I don't get it. Why is the firmware interface at all reasonable for uploading capsules? The firmware interface makes sense for nonvolatile firmware where hotplugging something or otherwise loading a driver needs a blob. But uploading an EFI capsule is an *action*, not something that should happen transparently. If there's an EFI firmware update available and the user wants to install it, then the userspace tool should install it, and it shouldn't hang around in /lib/firmware. In fact, you shouldn't even need /lib to be on writable media to use this. And you most certainly don't want the EFI capsule hanging around so that it might be accidentally installed again if the hard disk is moved. ISTM there should be some file in sysfs to which you can write a capsule, or perhaps a chardev and an ioctl. --Andy > > Besides build in kernel, the design also cater for build as kernel driver > module. This patchset introduce a new API (request_firmware_abort()) at > firmware_class so that the driver module could be unloaded by calling the API > to properly stop user helper interface and release the device. > > Thanks. > > --- > changelog v2: > [PATCH 1/3] > * use fw_lookup_buf() instead of __fw_lookup_buf() function call > * move the fw_lookup_buf() function out of the CONFIG_PM_SLEEP block > > [PATCH 2/3] > * no change > > [PATCH 3/3] > * no change > > > Kweh, Hock Leong (3): > firmware loader: Introduce new API - request_firmware_abort() > firmware loader: fix hung task warning dump > efi: Capsule update with user helper interface > > drivers/base/firmware_class.c | 56 -- > drivers/firmware/efi/Kconfig | 13 ++ > drivers/firmware/efi/Makefile |1 + > drivers/firmware/efi/efi-capsule-user-helper.c | 246 > > include/linux/firmware.h |4 + > 5 files changed, 306 insertions(+), 14 deletions(-) > create mode 100644 drivers/firmware/efi/efi-capsule-user-helper.c > -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] Enable user helper interface for efi capsule update
From: "Kweh, Hock Leong" Hi Guys, This patchset is created on top of "efi: Capsule update support" patch: http://permalink.gmane.org/gmane.linux.kernel.efi/4837 It leverages the request_firmware_nowait() to expose the user helper interface for user to upload the capsule binary and calling the efi_capsule_update() API to pass the binary to EFI firmware. Besides build in kernel, the design also cater for build as kernel driver module. This patchset introduce a new API (request_firmware_abort()) at firmware_class so that the driver module could be unloaded by calling the API to properly stop user helper interface and release the device. Thanks. --- changelog v2: [PATCH 1/3] * use fw_lookup_buf() instead of __fw_lookup_buf() function call * move the fw_lookup_buf() function out of the CONFIG_PM_SLEEP block [PATCH 2/3] * no change [PATCH 3/3] * no change Kweh, Hock Leong (3): firmware loader: Introduce new API - request_firmware_abort() firmware loader: fix hung task warning dump efi: Capsule update with user helper interface drivers/base/firmware_class.c | 56 -- drivers/firmware/efi/Kconfig | 13 ++ drivers/firmware/efi/Makefile |1 + drivers/firmware/efi/efi-capsule-user-helper.c | 246 include/linux/firmware.h |4 + 5 files changed, 306 insertions(+), 14 deletions(-) create mode 100644 drivers/firmware/efi/efi-capsule-user-helper.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
