linux-kernel - Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware

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]

Message-ID: <1430343554.2189.30.camel@HansenPartnership.com>
Date:	Wed, 29 Apr 2015 14:39:14 -0700
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	"Kweh, Hock Leong" <hock.leong.kweh@...el.com>,
	Peter Jones <pjones@...hat.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Matt Fleming <matt@...eblueprint.co.uk>,
	Ming Lei <ming.lei@...onical.com>,
	"Ong, Boon Leong" <boon.leong.ong@...el.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	Sam Protsenko <semen.protsenko@...aro.org>,
	Roy Franz <roy.franz@...aro.org>,
	Borislav Petkov <bp@...en8.de>,
	Al Viro <viro@...iv.linux.org.uk>,
	Linux FS Devel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi
 firmware

On Wed, 2015-04-29 at 14:36 -0700, Andy Lutomirski wrote:
> On Wed, Apr 29, 2015 at 2:35 PM, James Bottomley
> <James.Bottomley@...senpartnership.com> wrote:
> > On Wed, 2015-04-29 at 11:23 +0000, Kweh, Hock Leong wrote:
> >> I agree with James. Due to different people may have different needs. But
> >> from our side, we would just like to have a simple interface for us to upload
> >> the efi capsule and perform update. We do not have any use case or need
> >> to get info from QueryCapsuleUpdate(). Let me give a suggestion here:
> >> please allow me to focus on deliver this simple loading interface and
> >> upstream it. Then later whoever has the actual use case or needs on the ioctl
> >> implementation, he or she could enhance base on this simple loading interface.
> >> What do you guys think?
> >>
> >> Let me summarize the latest design idea:
> >> - No longer leverage on firmware class but use misc device
> >> - Do not use platform device but use device_create()
> >> - User just need to perform "cat file.bin > /sys/.../capsule_loader" in the shell
> >> - File operation functions include: open(), read(), write() and flush()
> >> - Perform mutex lock in open() then release the mutex in flush() for avoiding
> >>    race condition / concurrent loading
> >> - Perform the capsule update and error return at flush() function
> >>
> >> Is there anything I missed? Any one still have concern with this idea?
> >> Thanks for providing the ideas as well as the review.
> >
> > I think that's pretty much it.
> >
> > Why don't you let me construct a straw man patch.  It's going to be a
> > bit controversial because it involves adding flush operations to sysfs
> > and kernfs, slicing apart firmware_class.c to extract the transaction
> > handling stuff and creating an new efi update capsule file which makes
> > use of it.
> >
> > Once we have code, we at least have something more concrete to argue
> > over.
> 
> Would it be worth checking whether busybox is also okay with it first?
> (Sorry to be a naysayer.)
> 
> It would be a shame if we do all this to keep the userspace footprint
> light and then it doesn't work for non-coreutils userspace.

I don't think so, because we can fix busybox if it's a problem.  The
embedded people wanting this control the tool space, so they can decide
to use the fixed version.

So yes, someone should check and fix busybox cat if broken, but no, it's
not a blocker.

James


--
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/