lkml.org 
[lkml]   [2015]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface
    Date
    > -----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
    \
     
     \ /
      Last update: 2015-03-05 10:41    [W:2.189 / U:0.356 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site