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

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

[Kweh, Hock Leong]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2121 bytes --]

> -----Original Message-----
> From: Borislav Petkov [mailto:bp@alien8.de]
> Sent: Wednesday, February 25, 2015 8:49 PM
> 
> On Wed, Feb 25, 2015 at 12:38:20PM +0000, Kweh, Hock Leong wrote:
> > The reason we use this interface for efi capsule is that efi capsule
> > support multi binaries to be uploaded and each binary file name
> > can be different.
> 
> So you can write the file path to a second file and reload then, once
> per file.

Thanks for the suggestion. Did some exploration on this approach and
would like to continue the discussion together with this suggested design.

Ideal condition:
- one file note is enough for load binary and status return (capsule_load)
- load steps would be as simple as just:
   echo [binary file name] > capsule_load
- status return in the same command action. If failed, the echo will fail
   with the failing status code.

Trade off:
- does not have the run time flexibility to load any firmware binaries at
   different different path as firmware class  only support one custom
   path inputted during boot time/load time. Unless to add new export
   function for firmware class.
- if any typo on user level or file path not found, firmware class falls back
   to user helper interface. User is required to open another terminal to
   performs:
   -> echo 1 > loading
   -> cat capsule.bin > data
   -> echo 0 > loading
   Or wait for timeout.
- User has the capability to configure the firmware_class time out value.
   If the infinite value is set, the only method to break the infinite waiting
   by manually perform "echo -1 > loading" on the other terminal.

Are you guys okay with these trade off?
Or you guys still okay with the previous 2 design idea?

> 
> Alternatively, you can combine all the files into a cpio archive like
> we do with the microcode loader too, and let the kernel parse the cpio
> archive.

I believe this will make the implementation complicated compare to above.


Regards,
Wilson
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

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

[Kweh, Hock Leong]

> -----Original Message-----
> From: Borislav Petkov [mailto:bp@alien8.de]
> Sent: Wednesday, February 25, 2015 8:49 PM
> 
> On Wed, Feb 25, 2015 at 12:38:20PM +0000, Kweh, Hock Leong wrote:
> > The reason we use this interface for efi capsule is that efi capsule
> > support multi binaries to be uploaded and each binary file name
> > can be different.
> 
> So you can write the file path to a second file and reload then, once
> per file.

Thanks for the suggestion. Did some exploration on this approach and
would like to continue the discussion together with this suggested design.

Ideal condition:
- one file note is enough for load binary and status return (capsule_load)
- load steps would be as simple as just:
   echo [binary file name] > capsule_load
- status return in the same command action. If failed, the echo will fail
   with the failing status code.

Trade off:
- does not have the run time flexibility to load any firmware binaries at
   different different path as firmware class  only support one custom
   path inputted during boot time/load time. Unless to add new export
   function for firmware class.
- if any typo on user level or file path not found, firmware class falls back
   to user helper interface. User is required to open another terminal to
   performs:
   -> echo 1 > loading
   -> cat capsule.bin > data
   -> echo 0 > loading
   Or wait for timeout.
- User has the capability to configure the firmware_class time out value.
   If the infinite value is set, the only method to break the infinite waiting
   by manually perform "echo -1 > loading" on the other terminal.

Are you guys okay with these trade off?
Or you guys still okay with the previous 2 design idea?

> 
> Alternatively, you can combine all the files into a cpio archive like
> we do with the microcode loader too, and let the kernel parse the cpio
> archive.

I believe this will make the implementation complicated compare to above.


Regards,
Wilson

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

[Matt Fleming]

On Mon, 02 Mar, at 10:59:00AM, Kweh Hock Leong wrote:
> > -----Original Message-----
> > From: Borislav Petkov [mailto:bp@alien8.de]
> > Sent: Wednesday, February 25, 2015 8:49 PM
> > 
> > On Wed, Feb 25, 2015 at 12:38:20PM +0000, Kweh, Hock Leong wrote:
> > > The reason we use this interface for efi capsule is that efi capsule
> > > support multi binaries to be uploaded and each binary file name
> > > can be different.
> > 
> > So you can write the file path to a second file and reload then, once
> > per file.
> 
> Thanks for the suggestion. Did some exploration on this approach and
> would like to continue the discussion together with this suggested design.
> 
> Ideal condition:
> - one file note is enough for load binary and status return (capsule_load)
> - load steps would be as simple as just:
>    echo [binary file name] > capsule_load
> - status return in the same command action. If failed, the echo will fail
>    with the failing status code.
> 
> Trade off:
> - does not have the run time flexibility to load any firmware binaries at
>    different different path as firmware class  only support one custom
>    path inputted during boot time/load time. Unless to add new export
>    function for firmware class.

Could you elaborate here? I don't understand this point.

> - if any typo on user level or file path not found, firmware class falls back
>    to user helper interface. User is required to open another terminal to
>    performs:
>    -> echo 1 > loading
>    -> cat capsule.bin > data
>    -> echo 0 > loading
>    Or wait for timeout.

Not if you use request_firmware_direct(), right?
request_firmware_direct() explicitly does not invoke the user helper.

> - User has the capability to configure the firmware_class time out value.
>    If the infinite value is set, the only method to break the infinite waiting
>    by manually perform "echo -1 > loading" on the other terminal.
 
I'm not sure this is a problem if we use request_firmware_direct().

> Are you guys okay with these trade off?
> Or you guys still okay with the previous 2 design idea?
 
I quite like the design that Borislav is proposing. Things become a lot
simpler when we stop using request_firmware_nowait().

The next question is whether we want to batch passing capsules to the
firmware. The UpdateCapsule() EFI runtime service allows you to chain
capsule blobs together and pass a scatter-gather list.

If we do want to batch uploading then we need the equivalent of the
'reload' file from the microcode loader to signal to the kernel that the
userland process has finished uploading capsules, and the kernel can now
send them to the firmware as one chunk.

Also, Andy previously raised the point about multiple userland processes
passing capsules to the firmware simultaneously and the races that
occur, so we'd need a way to make that atomic.

I'd much prefer to send one capsule at a time to the firmware, because
it just makes this whole thing simpler.

Wilson, I'm really looking for your input here with how capsule
uploading works on Quark. If we can just repeatedly call UpdateCapsule()
with one capsule file at a time, that's fine. If we absolutely must
bundle multiple capsule files together then we probably need to provide
some atomicity.

Thoughts?

> > Alternatively, you can combine all the files into a cpio archive like
> > we do with the microcode loader too, and let the kernel parse the cpio
> > archive.
> 
> I believe this will make the implementation complicated compare to above.

Agreed. The capsule files we're sending to the firmware (via this
interface) already contain all the information we need to stitch
multiple binaries together - there's really no reason to bundle things
any further.

-- 
Matt Fleming, Intel Open Source Technology Center

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

[Matt Fleming]

On Mon, 02 Mar, at 10:59:00AM, Kweh Hock Leong wrote:
> > -----Original Message-----
> > From: Borislav Petkov [mailto:bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org]
> > Sent: Wednesday, February 25, 2015 8:49 PM
> > 
> > On Wed, Feb 25, 2015 at 12:38:20PM +0000, Kweh, Hock Leong wrote:
> > > The reason we use this interface for efi capsule is that efi capsule
> > > support multi binaries to be uploaded and each binary file name
> > > can be different.
> > 
> > So you can write the file path to a second file and reload then, once
> > per file.
> 
> Thanks for the suggestion. Did some exploration on this approach and
> would like to continue the discussion together with this suggested design.
> 
> Ideal condition:
> - one file note is enough for load binary and status return (capsule_load)
> - load steps would be as simple as just:
>    echo [binary file name] > capsule_load
> - status return in the same command action. If failed, the echo will fail
>    with the failing status code.
> 
> Trade off:
> - does not have the run time flexibility to load any firmware binaries at
>    different different path as firmware class  only support one custom
>    path inputted during boot time/load time. Unless to add new export
>    function for firmware class.

Could you elaborate here? I don't understand this point.

> - if any typo on user level or file path not found, firmware class falls back
>    to user helper interface. User is required to open another terminal to
>    performs:
>    -> echo 1 > loading
>    -> cat capsule.bin > data
>    -> echo 0 > loading
>    Or wait for timeout.

Not if you use request_firmware_direct(), right?
request_firmware_direct() explicitly does not invoke the user helper.

> - User has the capability to configure the firmware_class time out value.
>    If the infinite value is set, the only method to break the infinite waiting
>    by manually perform "echo -1 > loading" on the other terminal.
 
I'm not sure this is a problem if we use request_firmware_direct().

> Are you guys okay with these trade off?
> Or you guys still okay with the previous 2 design idea?
 
I quite like the design that Borislav is proposing. Things become a lot
simpler when we stop using request_firmware_nowait().

The next question is whether we want to batch passing capsules to the
firmware. The UpdateCapsule() EFI runtime service allows you to chain
capsule blobs together and pass a scatter-gather list.

If we do want to batch uploading then we need the equivalent of the
'reload' file from the microcode loader to signal to the kernel that the
userland process has finished uploading capsules, and the kernel can now
send them to the firmware as one chunk.

Also, Andy previously raised the point about multiple userland processes
passing capsules to the firmware simultaneously and the races that
occur, so we'd need a way to make that atomic.

I'd much prefer to send one capsule at a time to the firmware, because
it just makes this whole thing simpler.

Wilson, I'm really looking for your input here with how capsule
uploading works on Quark. If we can just repeatedly call UpdateCapsule()
with one capsule file at a time, that's fine. If we absolutely must
bundle multiple capsule files together then we probably need to provide
some atomicity.

Thoughts?

> > Alternatively, you can combine all the files into a cpio archive like
> > we do with the microcode loader too, and let the kernel parse the cpio
> > archive.
> 
> I believe this will make the implementation complicated compare to above.

Agreed. The capsule files we're sending to the firmware (via this
interface) already contain all the information we need to stitch
multiple binaries together - there's really no reason to bundle things
any further.

-- 
Matt Fleming, Intel Open Source Technology Center

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

[Kweh, Hock Leong]

> -----Original Message-----
> From: Matt Fleming [mailto:matt@console-pimps.org]
> Sent: Monday, March 02, 2015 8:30 PM
> 
> On Mon, 02 Mar, at 10:59:00AM, Kweh Hock Leong wrote:
> > > -----Original Message-----
> > > From: Borislav Petkov [mailto:bp@alien8.de]
> > > Sent: Wednesday, February 25, 2015 8:49 PM
> > >
> > > On Wed, Feb 25, 2015 at 12:38:20PM +0000, Kweh, Hock Leong wrote:
> > > > The reason we use this interface for efi capsule is that efi capsule
> > > > support multi binaries to be uploaded and each binary file name
> > > > can be different.
> > >
> > > So you can write the file path to a second file and reload then, once
> > > per file.
> >
> > Thanks for the suggestion. Did some exploration on this approach and
> > would like to continue the discussion together with this suggested design.
> >
> > Ideal condition:
> > - one file note is enough for load binary and status return (capsule_load)
> > - load steps would be as simple as just:
> >    echo [binary file name] > capsule_load
> > - status return in the same command action. If failed, the echo will fail
> >    with the failing status code.
> >
> > Trade off:
> > - does not have the run time flexibility to load any firmware binaries at
> >    different different path as firmware class  only support one custom
> >    path inputted during boot time/load time. Unless to add new export
> >    function for firmware class.
> 
> Could you elaborate here? I don't understand this point.

Just to call out that using firmware class auto locate binary feature is limited
to locations:
- "/lib/firmware/updates/" UTS_RELEASE,
- "/lib/firmware/updates",
- "/lib/firmware/" UTS_RELEASE,
- "/lib/firmware"
and one custom path which inputted during firmware_class module load
time or kernel boot up time.

It is just not like the user helper interface which allow load the binary at
any path/location.

This really is not a big deal. User should cope with it.

> 
> > - if any typo on user level or file path not found, firmware class falls back
> >    to user helper interface. User is required to open another terminal to
> >    performs:
> >    -> echo 1 > loading
> >    -> cat capsule.bin > data
> >    -> echo 0 > loading
> >    Or wait for timeout.
> 
> Not if you use request_firmware_direct(), right?
> request_firmware_direct() explicitly does not invoke the user helper.
> 
> > - User has the capability to configure the firmware_class time out value.
> >    If the infinite value is set, the only method to break the infinite waiting
> >    by manually perform "echo -1 > loading" on the other terminal.
> 
> I'm not sure this is a problem if we use request_firmware_direct().

Oops... I miss out this function. Will rework using this function.

> 
> > Are you guys okay with these trade off?
> > Or you guys still okay with the previous 2 design idea?
> 
> I quite like the design that Borislav is proposing. Things become a lot
> simpler when we stop using request_firmware_nowait().
> 
> The next question is whether we want to batch passing capsules to the
> firmware. The UpdateCapsule() EFI runtime service allows you to chain
> capsule blobs together and pass a scatter-gather list.
> 
> If we do want to batch uploading then we need the equivalent of the
> 'reload' file from the microcode loader to signal to the kernel that the
> userland process has finished uploading capsules, and the kernel can now
> send them to the firmware as one chunk.
> 
> Also, Andy previously raised the point about multiple userland processes
> passing capsules to the firmware simultaneously and the races that
> occur, so we'd need a way to make that atomic.
> 
> I'd much prefer to send one capsule at a time to the firmware, because
> it just makes this whole thing simpler.
> 
> Wilson, I'm really looking for your input here with how capsule
> uploading works on Quark. If we can just repeatedly call UpdateCapsule()
> with one capsule file at a time, that's fine. If we absolutely must
> bundle multiple capsule files together then we probably need to provide
> some atomicity.
> 
> Thoughts?

Quark does not need batch uploading. Even I tested multiple capsules on
Quark by doing repeatedly calling UpdateCapsule() is still working for Quark.
So, Quark does not require this bundling.

> 
> > > Alternatively, you can combine all the files into a cpio archive like
> > > we do with the microcode loader too, and let the kernel parse the cpio
> > > archive.
> >
> > I believe this will make the implementation complicated compare to above.
> 
> Agreed. The capsule files we're sending to the firmware (via this
> interface) already contain all the information we need to stitch
> multiple binaries together - there's really no reason to bundle things
> any further.
> 
> --
> Matt Fleming, Intel Open Source Technology Center

Hi Greg, Ming Lei, Sam & Andy,

Do you guys have any others concern on Borislav proposed approach?
Thanks.


Regards,
Wilson

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

[Andy Lutomirski]

On Mon, Mar 2, 2015 at 9:56 PM, Kweh, Hock Leong
<hock.leong.kweh@intel.com> wrote:
>> -----Original Message-----
>> From: Matt Fleming [mailto:matt@console-pimps.org]
>> Sent: Monday, March 02, 2015 8:30 PM
>>
>> On Mon, 02 Mar, at 10:59:00AM, Kweh Hock Leong wrote:
>> > > -----Original Message-----
>> > > From: Borislav Petkov [mailto:bp@alien8.de]
>> > > Sent: Wednesday, February 25, 2015 8:49 PM
>> > >
>> > > On Wed, Feb 25, 2015 at 12:38:20PM +0000, Kweh, Hock Leong wrote:
>> > > > The reason we use this interface for efi capsule is that efi capsule
>> > > > support multi binaries to be uploaded and each binary file name
>> > > > can be different.
>> > >
>> > > So you can write the file path to a second file and reload then, once
>> > > per file.
>> >
>> > Thanks for the suggestion. Did some exploration on this approach and
>> > would like to continue the discussion together with this suggested design.
>> >
>> > Ideal condition:
>> > - one file note is enough for load binary and status return (capsule_load)
>> > - load steps would be as simple as just:
>> >    echo [binary file name] > capsule_load
>> > - status return in the same command action. If failed, the echo will fail
>> >    with the failing status code.
>> >
>> > Trade off:
>> > - does not have the run time flexibility to load any firmware binaries at
>> >    different different path as firmware class  only support one custom
>> >    path inputted during boot time/load time. Unless to add new export
>> >    function for firmware class.
>>
>> Could you elaborate here? I don't understand this point.
>
> Just to call out that using firmware class auto locate binary feature is limited
> to locations:
> - "/lib/firmware/updates/" UTS_RELEASE,
> - "/lib/firmware/updates",
> - "/lib/firmware/" UTS_RELEASE,
> - "/lib/firmware"
> and one custom path which inputted during firmware_class module load
> time or kernel boot up time.
>
> It is just not like the user helper interface which allow load the binary at
> any path/location.
>
> This really is not a big deal. User should cope with it.

No, it's a big deal, and the user should not cope.

The user *should not* be required to have write access to anything in
/lib to install a UEFI capsule that they download from their
motherboard vendor's website.  /lib belongs to the distro, and UEFI
capsules do not belong to the distro.  In this regard, UEFI capsules
are completely unlike your wireless card firmware, your cpu microcode,
etc.

Imagine systems using NFS root, Atomic-style systems (e.g. ostree),
systems that boot off squashfs, etc.  They should still be able to
load capsules.  The basic user interface that should work is:

# uefi-load-capsule /path/to/capsule

or:

# uefi-load-capsule - </path/to/capsule

I don't really care how uefi-load-capsule is implemented, as long as
it's straightforward, because people will screw it up if it isn't
straightforward.

Why is it so hard to have a file in sysfs that you write the capsule
to using *cat* (not echo) and that will return an error code if cat
fails?  Is it because you don't know where the end of the capsule is?
if so, ioctl is designed for exactly this purpose.

TBH, I find this thread kind of ridiculous.  The problem that you're
trying to solve is extremely simple, the functionality that userspace
needs is trivial, and all of these complex proposals for how it should
work are an artifact of the fact that the kernel-internal interfaces
you're using for it are not well suited to the problem at hand.

--Andy

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

[Borislav Petkov]

On Tue, Mar 03, 2015 at 12:37:54PM -0800, Andy Lutomirski wrote:
> The user *should not* be required to have write access to anything in
> /lib to install a UEFI capsule that they download from their
> motherboard vendor's website.  /lib belongs to the distro, and UEFI
> capsules do not belong to the distro.  In this regard, UEFI capsules
> are completely unlike your wireless card firmware, your cpu microcode,
> etc.

Oh oh but but, if an UEFI capsule can brick the system, a normal user
would be able to brick that system then. I think we should forbid that.

I agree with the rest of your note that a simple

cat <fw_blob> > /sys/...

should be enough.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

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

[Borislav Petkov]

On Tue, Mar 03, 2015 at 12:37:54PM -0800, Andy Lutomirski wrote:
> The user *should not* be required to have write access to anything in
> /lib to install a UEFI capsule that they download from their
> motherboard vendor's website.  /lib belongs to the distro, and UEFI
> capsules do not belong to the distro.  In this regard, UEFI capsules
> are completely unlike your wireless card firmware, your cpu microcode,
> etc.

Oh oh but but, if an UEFI capsule can brick the system, a normal user
would be able to brick that system then. I think we should forbid that.

I agree with the rest of your note that a simple

cat <fw_blob> > /sys/...

should be enough.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

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

[Andy Lutomirski]

On Mar 3, 2015 12:51 PM, "Borislav Petkov" <bp@alien8.de> wrote:
>
> On Tue, Mar 03, 2015 at 12:37:54PM -0800, Andy Lutomirski wrote:
> > The user *should not* be required to have write access to anything in
> > /lib to install a UEFI capsule that they download from their
> > motherboard vendor's website.  /lib belongs to the distro, and UEFI
> > capsules do not belong to the distro.  In this regard, UEFI capsules
> > are completely unlike your wireless card firmware, your cpu microcode,
> > etc.
>
> Oh oh but but, if an UEFI capsule can brick the system, a normal user
> would be able to brick that system then. I think we should forbid that.

Absolutely.  That's why I said

# uefi-load-capsule

and not

$ uefi-load-capsule

:)

>
> I agree with the rest of your note that a simple
>
> cat <fw_blob> > /sys/...
>
> should be enough.
>
> --
> Regards/Gruss,
>     Boris.
>
> ECO tip #101: Trim your mails when you reply.
> --

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

[Kweh, Hock Leong]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2817 bytes --]

> -----Original Message-----
> From: Andy Lutomirski [mailto:luto@amacapital.net]
> Sent: Wednesday, March 04, 2015 4:38 AM
> 
> On Mon, Mar 2, 2015 at 9:56 PM, Kweh, Hock Leong
> <hock.leong.kweh@intel.com> wrote:
> >
> > Just to call out that using firmware class auto locate binary feature is limited
> > to locations:
> > - "/lib/firmware/updates/" UTS_RELEASE,
> > - "/lib/firmware/updates",
> > - "/lib/firmware/" UTS_RELEASE,
> > - "/lib/firmware"
> > and one custom path which inputted during firmware_class module load
> > time or kernel boot up time.
> >
> > It is just not like the user helper interface which allow load the binary at
> > any path/location.
> >
> > This really is not a big deal. User should cope with it.
> 
> No, it's a big deal, and the user should not cope.
> 
> The user *should not* be required to have write access to anything in
> /lib to install a UEFI capsule that they download from their
> motherboard vendor's website.  /lib belongs to the distro, and UEFI
> capsules do not belong to the distro.  In this regard, UEFI capsules
> are completely unlike your wireless card firmware, your cpu microcode,
> etc.
> 
> Imagine systems using NFS root, Atomic-style systems (e.g. ostree),
> systems that boot off squashfs, etc.  They should still be able to
> load capsules.  The basic user interface that should work is:
> 
> # uefi-load-capsule /path/to/capsule
> 
> or:
> 
> # uefi-load-capsule - </path/to/capsule
> 
> I don't really care how uefi-load-capsule is implemented, as long as
> it's straightforward, because people will screw it up if it isn't
> straightforward.
> 
> Why is it so hard to have a file in sysfs that you write the capsule
> to using *cat* (not echo) and that will return an error code if cat
> fails?  Is it because you don't know where the end of the capsule is?
> if so, ioctl is designed for exactly this purpose.
> 
> TBH, I find this thread kind of ridiculous.  The problem that you're
> trying to solve is extremely simple, the functionality that userspace
> needs is trivial, and all of these complex proposals for how it should
> work are an artifact of the fact that the kernel-internal interfaces
> you're using for it are not well suited to the problem at hand.
> 
> --Andy

Sorry, I may not catch your point correctly. Are you trying to tell that
a "normal" user can perform efi capsule update. But a "normal" user
does not have the right to install or copy the capsule binary into
"/lib/firmware/". So, there is a need to make this capsule module to
allow uploading the capsule binary at any path or location other than
"/lib/firmware/".

Is this what you mean?


Regards,
Wilson
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

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

[Kweh, Hock Leong]

> -----Original Message-----
> From: Andy Lutomirski [mailto:luto@amacapital.net]
> Sent: Wednesday, March 04, 2015 4:38 AM
> 
> On Mon, Mar 2, 2015 at 9:56 PM, Kweh, Hock Leong
> <hock.leong.kweh@intel.com> wrote:
> >
> > Just to call out that using firmware class auto locate binary feature is limited
> > to locations:
> > - "/lib/firmware/updates/" UTS_RELEASE,
> > - "/lib/firmware/updates",
> > - "/lib/firmware/" UTS_RELEASE,
> > - "/lib/firmware"
> > and one custom path which inputted during firmware_class module load
> > time or kernel boot up time.
> >
> > It is just not like the user helper interface which allow load the binary at
> > any path/location.
> >
> > This really is not a big deal. User should cope with it.
> 
> No, it's a big deal, and the user should not cope.
> 
> The user *should not* be required to have write access to anything in
> /lib to install a UEFI capsule that they download from their
> motherboard vendor's website.  /lib belongs to the distro, and UEFI
> capsules do not belong to the distro.  In this regard, UEFI capsules
> are completely unlike your wireless card firmware, your cpu microcode,
> etc.
> 
> Imagine systems using NFS root, Atomic-style systems (e.g. ostree),
> systems that boot off squashfs, etc.  They should still be able to
> load capsules.  The basic user interface that should work is:
> 
> # uefi-load-capsule /path/to/capsule
> 
> or:
> 
> # uefi-load-capsule - </path/to/capsule
> 
> I don't really care how uefi-load-capsule is implemented, as long as
> it's straightforward, because people will screw it up if it isn't
> straightforward.
> 
> Why is it so hard to have a file in sysfs that you write the capsule
> to using *cat* (not echo) and that will return an error code if cat
> fails?  Is it because you don't know where the end of the capsule is?
> if so, ioctl is designed for exactly this purpose.
> 
> TBH, I find this thread kind of ridiculous.  The problem that you're
> trying to solve is extremely simple, the functionality that userspace
> needs is trivial, and all of these complex proposals for how it should
> work are an artifact of the fact that the kernel-internal interfaces
> you're using for it are not well suited to the problem at hand.
> 
> --Andy

Sorry, I may not catch your point correctly. Are you trying to tell that
a "normal" user can perform efi capsule update. But a "normal" user
does not have the right to install or copy the capsule binary into
"/lib/firmware/". So, there is a need to make this capsule module to
allow uploading the capsule binary at any path or location other than
"/lib/firmware/".

Is this what you mean?


Regards,
Wilson

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

[Andy Lutomirski]

On Mar 5, 2015 1:19 AM, "Kweh, Hock Leong" <hock.leong.kweh@intel.com> wrote:
>
> > -----Original Message-----
> > From: Andy Lutomirski [mailto:luto@amacapital.net]
> > Sent: Wednesday, March 04, 2015 4:38 AM
> >
> > On Mon, Mar 2, 2015 at 9:56 PM, Kweh, Hock Leong
> > <hock.leong.kweh@intel.com> wrote:
> > >
> > > Just to call out that using firmware class auto locate binary feature is limited
> > > to locations:
> > > - "/lib/firmware/updates/" UTS_RELEASE,
> > > - "/lib/firmware/updates",
> > > - "/lib/firmware/" UTS_RELEASE,
> > > - "/lib/firmware"
> > > and one custom path which inputted during firmware_class module load
> > > time or kernel boot up time.
> > >
> > > It is just not like the user helper interface which allow load the binary at
> > > any path/location.
> > >
> > > This really is not a big deal. User should cope with it.
> >
> > No, it's a big deal, and the user should not cope.
> >
> > The user *should not* be required to have write access to anything in
> > /lib to install a UEFI capsule that they download from their
> > motherboard vendor's website.  /lib belongs to the distro, and UEFI
> > capsules do not belong to the distro.  In this regard, UEFI capsules
> > are completely unlike your wireless card firmware, your cpu microcode,
> > etc.
> >
> > Imagine systems using NFS root, Atomic-style systems (e.g. ostree),
> > systems that boot off squashfs, etc.  They should still be able to
> > load capsules.  The basic user interface that should work is:
> >
> > # uefi-load-capsule /path/to/capsule
> >
> > or:
> >
> > # uefi-load-capsule - </path/to/capsule
> >
> > I don't really care how uefi-load-capsule is implemented, as long as
> > it's straightforward, because people will screw it up if it isn't
> > straightforward.
> >
> > Why is it so hard to have a file in sysfs that you write the capsule
> > to using *cat* (not echo) and that will return an error code if cat
> > fails?  Is it because you don't know where the end of the capsule is?
> > if so, ioctl is designed for exactly this purpose.
> >
> > TBH, I find this thread kind of ridiculous.  The problem that you're
> > trying to solve is extremely simple, the functionality that userspace
> > needs is trivial, and all of these complex proposals for how it should
> > work are an artifact of the fact that the kernel-internal interfaces
> > you're using for it are not well suited to the problem at hand.
> >
> > --Andy
>
> Sorry, I may not catch your point correctly. Are you trying to tell that
> a "normal" user can perform efi capsule update. But a "normal" user
> does not have the right to install or copy the capsule binary into
> "/lib/firmware/". So, there is a need to make this capsule module to
> allow uploading the capsule binary at any path or location other than
> "/lib/firmware/".
>
> Is this what you mean?

No.  Only root should be able to load capsules, but even root may not
be able to write to /lib.

--Andy

>
>
> Regards,
> Wilson

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

[Andy Lutomirski]

On Mar 5, 2015 1:19 AM, "Kweh, Hock Leong" <hock.leong.kweh-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>
> > -----Original Message-----
> > From: Andy Lutomirski [mailto:luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org]
> > Sent: Wednesday, March 04, 2015 4:38 AM
> >
> > On Mon, Mar 2, 2015 at 9:56 PM, Kweh, Hock Leong
> > <hock.leong.kweh-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
> > >
> > > Just to call out that using firmware class auto locate binary feature is limited
> > > to locations:
> > > - "/lib/firmware/updates/" UTS_RELEASE,
> > > - "/lib/firmware/updates",
> > > - "/lib/firmware/" UTS_RELEASE,
> > > - "/lib/firmware"
> > > and one custom path which inputted during firmware_class module load
> > > time or kernel boot up time.
> > >
> > > It is just not like the user helper interface which allow load the binary at
> > > any path/location.
> > >
> > > This really is not a big deal. User should cope with it.
> >
> > No, it's a big deal, and the user should not cope.
> >
> > The user *should not* be required to have write access to anything in
> > /lib to install a UEFI capsule that they download from their
> > motherboard vendor's website.  /lib belongs to the distro, and UEFI
> > capsules do not belong to the distro.  In this regard, UEFI capsules
> > are completely unlike your wireless card firmware, your cpu microcode,
> > etc.
> >
> > Imagine systems using NFS root, Atomic-style systems (e.g. ostree),
> > systems that boot off squashfs, etc.  They should still be able to
> > load capsules.  The basic user interface that should work is:
> >
> > # uefi-load-capsule /path/to/capsule
> >
> > or:
> >
> > # uefi-load-capsule - </path/to/capsule
> >
> > I don't really care how uefi-load-capsule is implemented, as long as
> > it's straightforward, because people will screw it up if it isn't
> > straightforward.
> >
> > Why is it so hard to have a file in sysfs that you write the capsule
> > to using *cat* (not echo) and that will return an error code if cat
> > fails?  Is it because you don't know where the end of the capsule is?
> > if so, ioctl is designed for exactly this purpose.
> >
> > TBH, I find this thread kind of ridiculous.  The problem that you're
> > trying to solve is extremely simple, the functionality that userspace
> > needs is trivial, and all of these complex proposals for how it should
> > work are an artifact of the fact that the kernel-internal interfaces
> > you're using for it are not well suited to the problem at hand.
> >
> > --Andy
>
> Sorry, I may not catch your point correctly. Are you trying to tell that
> a "normal" user can perform efi capsule update. But a "normal" user
> does not have the right to install or copy the capsule binary into
> "/lib/firmware/". So, there is a need to make this capsule module to
> allow uploading the capsule binary at any path or location other than
> "/lib/firmware/".
>
> Is this what you mean?

No.  Only root should be able to load capsules, but even root may not
be able to write to /lib.

--Andy

>
>
> Regards,
> Wilson

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

[Borislav Petkov]

On Thu, Mar 05, 2015 at 03:08:42PM -0800, Andy Lutomirski wrote:
> No.  Only root should be able to load capsules, but even root may not
> be able to write to /lib.

So basically what we want to do is:

# cat /any/path/to/efi/capsule/accessible/to/root/efi_capsule.img > /sys/firmware/efi/update

Now it can't get any simpler than that and you get error codes too by
failing the cat if the update fails.

Mind you, I'm using '#' and not '$' as a shell prompt :-)

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

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

[Borislav Petkov]

On Thu, Mar 05, 2015 at 03:08:42PM -0800, Andy Lutomirski wrote:
> No.  Only root should be able to load capsules, but even root may not
> be able to write to /lib.

So basically what we want to do is:

# cat /any/path/to/efi/capsule/accessible/to/root/efi_capsule.img > /sys/firmware/efi/update

Now it can't get any simpler than that and you get error codes too by
failing the cat if the update fails.

Mind you, I'm using '#' and not '$' as a shell prompt :-)

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

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

[Kweh, Hock Leong]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1151 bytes --]

> -----Original Message-----
> From: Borislav Petkov [mailto:bp@alien8.de]
> Sent: Friday, March 06, 2015 4:14 PM
> 
> On Thu, Mar 05, 2015 at 03:08:42PM -0800, Andy Lutomirski wrote:
> > No.  Only root should be able to load capsules, but even root may not
> > be able to write to /lib.
> 
> So basically what we want to do is:
> 
> # cat /any/path/to/efi/capsule/accessible/to/root/efi_capsule.img >
> /sys/firmware/efi/update
> 
> Now it can't get any simpler than that and you get error codes too by
> failing the cat if the update fails.
> 
> Mind you, I'm using '#' and not '$' as a shell prompt :-)
> 
> --
> Regards/Gruss,
>     Boris.
> 
> ECO tip #101: Trim your mails when you reply.
> --

I believe you guys are more paying attention to the PATH and
whether doing:
# cat /any/path/capsule.bin > /sys/devices/platform/efi_capsule/capsule_load

or doing:
# echo "/any/path/capsule.bin" > /sys/devices/platform/efi_capsule/capsule_load

is not a big issue right?


Regards,
Wilson

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

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

[Kweh, Hock Leong]

> -----Original Message-----
> From: Borislav Petkov [mailto:bp@alien8.de]
> Sent: Friday, March 06, 2015 4:14 PM
> 
> On Thu, Mar 05, 2015 at 03:08:42PM -0800, Andy Lutomirski wrote:
> > No.  Only root should be able to load capsules, but even root may not
> > be able to write to /lib.
> 
> So basically what we want to do is:
> 
> # cat /any/path/to/efi/capsule/accessible/to/root/efi_capsule.img >
> /sys/firmware/efi/update
> 
> Now it can't get any simpler than that and you get error codes too by
> failing the cat if the update fails.
> 
> Mind you, I'm using '#' and not '$' as a shell prompt :-)
> 
> --
> Regards/Gruss,
>     Boris.
> 
> ECO tip #101: Trim your mails when you reply.
> --

I believe you guys are more paying attention to the PATH and
whether doing:
# cat /any/path/capsule.bin > /sys/devices/platform/efi_capsule/capsule_load

or doing:
# echo "/any/path/capsule.bin" > /sys/devices/platform/efi_capsule/capsule_load

is not a big issue right?


Regards,
Wilson

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

[Kweh, Hock Leong]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3223 bytes --]

> -----Original Message-----
> From: Andy Lutomirski [mailto:luto@amacapital.net]
> Sent: Friday, March 06, 2015 7:09 AM
> 
> On Mar 5, 2015 1:19 AM, "Kweh, Hock Leong" <hock.leong.kweh@intel.com>
> wrote:
> >
> > > > This really is not a big deal. User should cope with it.
> > >
> > > No, it's a big deal, and the user should not cope.
> > >
> > > The user *should not* be required to have write access to anything in
> > > /lib to install a UEFI capsule that they download from their
> > > motherboard vendor's website.  /lib belongs to the distro, and UEFI
> > > capsules do not belong to the distro.  In this regard, UEFI capsules
> > > are completely unlike your wireless card firmware, your cpu microcode,
> > > etc.
> > >
> > > Imagine systems using NFS root, Atomic-style systems (e.g. ostree),
> > > systems that boot off squashfs, etc.  They should still be able to
> > > load capsules.  The basic user interface that should work is:
> > >
> > > # uefi-load-capsule /path/to/capsule
> > >
> > > or:
> > >
> > > # uefi-load-capsule - </path/to/capsule
> > >
> > > I don't really care how uefi-load-capsule is implemented, as long as
> > > it's straightforward, because people will screw it up if it isn't
> > > straightforward.
> > >
> > > Why is it so hard to have a file in sysfs that you write the capsule
> > > to using *cat* (not echo) and that will return an error code if cat
> > > fails?  Is it because you don't know where the end of the capsule is?
> > > if so, ioctl is designed for exactly this purpose.
> > >
> > > TBH, I find this thread kind of ridiculous.  The problem that you're
> > > trying to solve is extremely simple, the functionality that userspace
> > > needs is trivial, and all of these complex proposals for how it should
> > > work are an artifact of the fact that the kernel-internal interfaces
> > > you're using for it are not well suited to the problem at hand.
> > >
> > > --Andy
> >
> > Sorry, I may not catch your point correctly. Are you trying to tell that
> > a "normal" user can perform efi capsule update. But a "normal" user
> > does not have the right to install or copy the capsule binary into
> > "/lib/firmware/". So, there is a need to make this capsule module to
> > allow uploading the capsule binary at any path or location other than
> > "/lib/firmware/".
> >
> > Is this what you mean?
> 
> No.  Only root should be able to load capsules, but even root may not
> be able to write to /lib.
> 
> --Andy
> 

Okay, I accept that only root user can perform the load capsule. It is new
to me that root user may not have the access right to "/lib/firmware".

But I remember you do mention that CPU micro code and wifi firmware
they are different and able to write in /lib/firmware. I am curious why
efi capsule binary have such a restriction.  What is preventing it being
write to that location?

I even went to check out the FHS:
http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
I do not find any restriction calling out for that.

Would you mind to educate me on that?
Thanks.


Regards,
Wilson

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

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

[Kweh, Hock Leong]

> -----Original Message-----
> From: Andy Lutomirski [mailto:luto@amacapital.net]
> Sent: Friday, March 06, 2015 7:09 AM
> 
> On Mar 5, 2015 1:19 AM, "Kweh, Hock Leong" <hock.leong.kweh@intel.com>
> wrote:
> >
> > > > This really is not a big deal. User should cope with it.
> > >
> > > No, it's a big deal, and the user should not cope.
> > >
> > > The user *should not* be required to have write access to anything in
> > > /lib to install a UEFI capsule that they download from their
> > > motherboard vendor's website.  /lib belongs to the distro, and UEFI
> > > capsules do not belong to the distro.  In this regard, UEFI capsules
> > > are completely unlike your wireless card firmware, your cpu microcode,
> > > etc.
> > >
> > > Imagine systems using NFS root, Atomic-style systems (e.g. ostree),
> > > systems that boot off squashfs, etc.  They should still be able to
> > > load capsules.  The basic user interface that should work is:
> > >
> > > # uefi-load-capsule /path/to/capsule
> > >
> > > or:
> > >
> > > # uefi-load-capsule - </path/to/capsule
> > >
> > > I don't really care how uefi-load-capsule is implemented, as long as
> > > it's straightforward, because people will screw it up if it isn't
> > > straightforward.
> > >
> > > Why is it so hard to have a file in sysfs that you write the capsule
> > > to using *cat* (not echo) and that will return an error code if cat
> > > fails?  Is it because you don't know where the end of the capsule is?
> > > if so, ioctl is designed for exactly this purpose.
> > >
> > > TBH, I find this thread kind of ridiculous.  The problem that you're
> > > trying to solve is extremely simple, the functionality that userspace
> > > needs is trivial, and all of these complex proposals for how it should
> > > work are an artifact of the fact that the kernel-internal interfaces
> > > you're using for it are not well suited to the problem at hand.
> > >
> > > --Andy
> >
> > Sorry, I may not catch your point correctly. Are you trying to tell that
> > a "normal" user can perform efi capsule update. But a "normal" user
> > does not have the right to install or copy the capsule binary into
> > "/lib/firmware/". So, there is a need to make this capsule module to
> > allow uploading the capsule binary at any path or location other than
> > "/lib/firmware/".
> >
> > Is this what you mean?
> 
> No.  Only root should be able to load capsules, but even root may not
> be able to write to /lib.
> 
> --Andy
> 

Okay, I accept that only root user can perform the load capsule. It is new
to me that root user may not have the access right to "/lib/firmware".

But I remember you do mention that CPU micro code and wifi firmware
they are different and able to write in /lib/firmware. I am curious why
efi capsule binary have such a restriction.  What is preventing it being
write to that location?

I even went to check out the FHS:
http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
I do not find any restriction calling out for that.

Would you mind to educate me on that?
Thanks.


Regards,
Wilson

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

[Borislav Petkov]

On Fri, Mar 06, 2015 at 11:41:57AM +0000, Kweh, Hock Leong wrote:
> # cat /any/path/capsule.bin > /sys/devices/platform/efi_capsule/capsule_load

This is straight-forward and clean.

> or doing:
> # echo "/any/path/capsule.bin" > /sys/devices/platform/efi_capsule/capsule_load

This is strange and clumsy. So do the first one please.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

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

[Borislav Petkov]

On Fri, Mar 06, 2015 at 11:41:57AM +0000, Kweh, Hock Leong wrote:
> # cat /any/path/capsule.bin > /sys/devices/platform/efi_capsule/capsule_load

This is straight-forward and clean.

> or doing:
> # echo "/any/path/capsule.bin" > /sys/devices/platform/efi_capsule/capsule_load

This is strange and clumsy. So do the first one please.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

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

[Andy Lutomirski]

On Mar 6, 2015 4:20 AM, "Kweh, Hock Leong" <hock.leong.kweh@intel.com> wrote:
>
> > -----Original Message-----
> > From: Andy Lutomirski [mailto:luto@amacapital.net]
> > Sent: Friday, March 06, 2015 7:09 AM
> >
> > On Mar 5, 2015 1:19 AM, "Kweh, Hock Leong" <hock.leong.kweh@intel.com>
> > wrote:
> > >
> > > > > This really is not a big deal. User should cope with it.
> > > >
> > > > No, it's a big deal, and the user should not cope.
> > > >
> > > > The user *should not* be required to have write access to anything in
> > > > /lib to install a UEFI capsule that they download from their
> > > > motherboard vendor's website.  /lib belongs to the distro, and UEFI
> > > > capsules do not belong to the distro.  In this regard, UEFI capsules
> > > > are completely unlike your wireless card firmware, your cpu microcode,
> > > > etc.
> > > >
> > > > Imagine systems using NFS root, Atomic-style systems (e.g. ostree),
> > > > systems that boot off squashfs, etc.  They should still be able to
> > > > load capsules.  The basic user interface that should work is:
> > > >
> > > > # uefi-load-capsule /path/to/capsule
> > > >
> > > > or:
> > > >
> > > > # uefi-load-capsule - </path/to/capsule
> > > >
> > > > I don't really care how uefi-load-capsule is implemented, as long as
> > > > it's straightforward, because people will screw it up if it isn't
> > > > straightforward.
> > > >
> > > > Why is it so hard to have a file in sysfs that you write the capsule
> > > > to using *cat* (not echo) and that will return an error code if cat
> > > > fails?  Is it because you don't know where the end of the capsule is?
> > > > if so, ioctl is designed for exactly this purpose.
> > > >
> > > > TBH, I find this thread kind of ridiculous.  The problem that you're
> > > > trying to solve is extremely simple, the functionality that userspace
> > > > needs is trivial, and all of these complex proposals for how it should
> > > > work are an artifact of the fact that the kernel-internal interfaces
> > > > you're using for it are not well suited to the problem at hand.
> > > >
> > > > --Andy
> > >
> > > Sorry, I may not catch your point correctly. Are you trying to tell that
> > > a "normal" user can perform efi capsule update. But a "normal" user
> > > does not have the right to install or copy the capsule binary into
> > > "/lib/firmware/". So, there is a need to make this capsule module to
> > > allow uploading the capsule binary at any path or location other than
> > > "/lib/firmware/".
> > >
> > > Is this what you mean?
> >
> > No.  Only root should be able to load capsules, but even root may not
> > be able to write to /lib.
> >
> > --Andy
> >
>
> Okay, I accept that only root user can perform the load capsule. It is new
> to me that root user may not have the access right to "/lib/firmware".
>
> But I remember you do mention that CPU micro code and wifi firmware
> they are different and able to write in /lib/firmware. I am curious why
> efi capsule binary have such a restriction.  What is preventing it being
> write to that location?
>

It has to do with where the firmware comes from.  When someone
prepares Linux fs image, they put user code, a kernel (usually), all
modules that might be needed, and all firmware that's likely to be
needed into /.  This might come from the distro or a company-wide
image.

If a normal firmware firmware file needs an update, it's just like
updating a driver or a library -- / will be updated by whatever
mechanism is in use.

Nonvolatile firmware is different.  The update isn't needed on
subsequent boots, and it could be much less generic than a driver.
For example, a capsule could contain a boot splash screen image that
says "this is computer #27."  Updating the system image to do this
makes little sense.  Instead it'll be a one-time thing done by root.

--Andy

> I even went to check out the FHS:
> http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
> I do not find any restriction calling out for that.
>
> Would you mind to educate me on that?
> Thanks.
>
>
> Regards,
> Wilson
>

fwupdate

[Borislav Petkov]

+ 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.

ECO tip #101: Trim your mails when you reply.
--

fwupdate

[Borislav Petkov]

+ 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.

ECO tip #101: Trim your mails when you reply.
--

Re: fwupdate

[Roy Franz]

On Mon, Mar 9, 2015 at 2:23 PM, Borislav Petkov <bp@alien8.de> 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 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.

Roy

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@alien8.de> 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.

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-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org> 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.

Re: fwupdate

[Peter Jones]

On Tue, Mar 10, 2015 at 10:56:32AM -0400, Peter Jones wrote:
> 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.

Slight correction, I did actually do that - it's in the current upstream
repo.

-- 
        Peter

Re: fwupdate

[Peter Jones]

On Tue, Mar 10, 2015 at 10:56:32AM -0400, Peter Jones wrote:
> 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.

Slight correction, I did actually do that - it's in the current upstream
repo.

-- 
        Peter