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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 8 Nov 2014 07:54:25 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Matt Fleming <matt@...sole-pimps.org>
Cc:	Ong Boon Leong <boon.leong.ong@...el.com>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	Sam Protsenko <semen.protsenko@...aro.org>,
	Matt Fleming <matt.fleming@...el.com>,
	"Kweh, Hock Leong" <hock.leong.kweh@...el.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	Ming Lei <ming.lei@...onical.com>
Subject: Re: [PATCH v2 3/3] efi: Capsule update with user helper interface

On Nov 8, 2014 5:05 AM, "Matt Fleming" <matt@...sole-pimps.org> wrote:
>
> On Tue, 04 Nov, at 08:35:40AM, Andy Lutomirski wrote:
> >
> > Am I missing something here?  The current proposal is missing the
> > success/failure part, unless you count the loaded count (in a
> > different sysfs directory) as a useful interface for that.
>
> As Wilson pointed out, you only get the ability to make meaningful
> success/failure declarations once you've performed the reboot.
>
> I know of no firmware that will hot-patch itself when you call
> UpdateCapsule(). A reboot is always required. Certainly that's the way
> Windows will work from what I've read, which means that for x86 it's
> pretty much set in stone.

I dunno.  If nothing else, efi_capsule_update can fail due to ENOMEM.

>
> Which means there's only so much info you can return to userspace once
> you've handed the blob to the firmware. I don't see a huge problem with
> printing things in kernel buffer, since that's how other
> firmware-related things work today.

I think the kernel log is fine.  But if the code is going to report
success / failure to userspace at all, shouldn't that indication be
reliable?

TBH, I find this discussion very strange.  In summary:

me: This API is really awkward.

others: But it's using the subsystem that it should be using.

me: Then fix the subsystem?

others: The subsystem the correct choice.

me: But the API is still really awkward, and, by the way, it probably
has at least two races that user code could hit.  And, by the way, the
sample script written by the author of the patches is subject to
*both* races most likely and therefore won't work reliably.

you: Common use cases (e.g. Windows-style uses, perhaps) don't need
the features that are racy anyway.

My only response is that (a) something else might want the full
functionality and (b) Wilson's actual example script exercises the
racy code.

I think I'm done reviewing these patches.  I'll probably grumble at
the result the first time I actually try to install an EFI capsule,
though.

--Andy

P.S. What happens when a strange UEFI BIOS really wants two capsules,
and the second one will brick the machine if the first one isn't
there, and the first one failed to load but no one noticed because
there's no useful error handling?
--
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/