[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrVVC2bqM9KAbb6A_2kN=fwbKer5VZ-nZdKW8J_MNrM-MA@mail.gmail.com>
Date: Tue, 3 Mar 2015 13:56:30 -0800
From: Andy Lutomirski <luto@...capital.net>
To: Borislav Petkov <bp@...en8.de>
Cc: Matt Fleming <matt@...sole-pimps.org>,
Ong Boon Leong <boon.leong.ong@...el.com>,
"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Sam Protsenko <semen.protsenko@...aro.org>,
"Kweh, Hock Leong" <hock.leong.kweh@...el.com>,
LKML <linux-kernel@...r.kernel.org>,
Ming Lei <ming.lei@...onical.com>
Subject: Re: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface
On Mar 3, 2015 12:51 PM, "Borislav Petkov" <bp@...en8.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.
> --
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists