From: Andy Lutomirski <luto@amacapital.net>
To: Kweh Hock Leong <hock.leong.kweh@intel.com>
Cc: Borislav Petkov <bp@alien8.de>,
Matt Fleming <matt@console-pimps.org>,
"Ong, Boon Leong" <boon.leong.ong@intel.com>,
"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
Sam Protsenko <semen.protsenko@linaro.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Ming Lei <ming.lei@canonical.com>
Subject: RE: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface
Date: Fri, 6 Mar 2015 11:05:00 -0800 [thread overview]
Message-ID: <CALCETrW9w2AtHR7qs2zNphhcSDq8=Q=Vw4J-e4yOw87gWHSUbQ@mail.gmail.com> (raw)
In-Reply-To: <F54AEECA5E2B9541821D670476DAE19C2B8AF8A2@PGSMSX102.gar.corp.intel.com>
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
>
next prev parent reply other threads:[~2015-03-06 19:05 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-02 10:59 Re: [PATCH v2 3/3] efi: Capsule update with user helper interface Kweh, Hock Leong
2015-03-02 12:29 ` Matt Fleming
2015-03-03 5:56 ` Kweh, Hock Leong
2015-03-03 20:37 ` Andy Lutomirski
2015-03-03 20:49 ` Borislav Petkov
2015-03-03 21:56 ` Andy Lutomirski
2015-03-05 9:18 ` Kweh, Hock Leong
2015-03-05 23:08 ` Andy Lutomirski
2015-03-06 8:13 ` Borislav Petkov
2015-03-06 11:41 ` Kweh, Hock Leong
2015-03-06 14:47 ` Borislav Petkov
2015-03-09 21:23 ` fwupdate Borislav Petkov
2015-03-10 1:54 ` fwupdate Roy Franz
2015-03-10 14:56 ` fwupdate Peter Jones
2015-03-10 15:27 ` fwupdate Peter Jones
2015-03-06 12:20 ` Re: [PATCH v2 3/3] efi: Capsule update with user helper interface Kweh, Hock Leong
2015-03-06 19:05 ` Andy Lutomirski [this message]
[not found] <F54AEECA5E2B9541821D670476DAE19C2B8AC95C@PGSMSX102.gar.corp.intel.com>
2015-02-24 12:49 ` Kweh, Hock Leong
2015-02-25 11:47 ` Borislav Petkov
2015-02-25 12:38 ` Kweh, Hock Leong
2015-02-25 12:49 ` Borislav Petkov
2015-02-26 15:30 ` Andy Lutomirski
2015-02-26 15:54 ` Borislav Petkov
2015-03-02 11:24 ` Matt Fleming
2015-03-06 21:39 ` Peter Jones
2015-03-06 21:49 ` Roy Franz
2015-03-06 22:17 ` Peter Jones
2015-03-10 12:26 ` Matt Fleming
2015-03-10 15:21 ` Peter Jones
2015-03-10 15:26 ` Andy Lutomirski
2015-03-10 15:40 ` Peter Jones
2015-03-10 15:51 ` Andy Lutomirski
2015-03-10 17:26 ` Peter Jones
2015-03-10 17:31 ` Andy Lutomirski
2015-03-12 22:47 ` Matt Fleming
2015-03-13 14:42 ` Greg Kroah-Hartman
2015-03-16 15:35 ` Andy Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALCETrW9w2AtHR7qs2zNphhcSDq8=Q=Vw4J-e4yOw87gWHSUbQ@mail.gmail.com' \
--to=luto@amacapital.net \
--cc=boon.leong.ong@intel.com \
--cc=bp@alien8.de \
--cc=gregkh@linuxfoundation.org \
--cc=hock.leong.kweh@intel.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@console-pimps.org \
--cc=ming.lei@canonical.com \
--cc=semen.protsenko@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).