From: "Kweh, Hock Leong" <hock.leong.kweh@intel.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Matt Fleming <matt@console-pimps.org>,
Borislav Petkov <bp@alien8.de>,
Sam Protsenko <semen.protsenko@linaro.org>,
Ming Lei <ming.lei@canonical.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Ong, Boon Leong" <boon.leong.ong@intel.com>,
LKML <linux-kernel@vger.kernel.org>,
"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>
Subject: RE: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface
Date: Thu, 5 Mar 2015 09:18:15 +0000 [thread overview]
Message-ID: <F54AEECA5E2B9541821D670476DAE19C2B8AF4F2@PGSMSX102.gar.corp.intel.com> (raw)
In-Reply-To: <CALCETrXfjbKcYSSRQXZbam7TgHU34LXM0BhvMuba_vYyCCPTig@mail.gmail.com>
[-- 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¥
next prev parent reply other threads:[~2015-03-05 9:19 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 [this message]
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
[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=F54AEECA5E2B9541821D670476DAE19C2B8AF4F2@PGSMSX102.gar.corp.intel.com \
--to=hock.leong.kweh@intel.com \
--cc=boon.leong.ong@intel.com \
--cc=bp@alien8.de \
--cc=gregkh@linuxfoundation.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--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).