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]

Date:	Thu, 30 Apr 2015 09:17:54 +0000
From:	"Kweh, Hock Leong" <hock.leong.kweh@...el.com>
To:	Andy Lutomirski <luto@...capital.net>
CC:	James Bottomley <James.Bottomley@...senpartnership.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

> -----Original Message-----
> From: Andy Lutomirski [mailto:luto@...capital.net]
> Sent: Thursday, April 30, 2015 2:41 AM
> 
> On Wed, Apr 29, 2015 at 4:23 AM, Kweh, Hock Leong
> <hock.leong.kweh@...el.com> wrote:
> >
> > Dear communities,
> >
> > 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
> 
> If you do this, there's no need for the misc device.

I do this so that in the future when someone want to implement the
Ioctl(), he or she can base on this and expand it.

> 
> > - 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
> 
> Make sure the mutex operation is killable, then, and maybe even
> interruptable.

Okay.

> 
> > - 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.
> >
> 
> If it works (and cat really does fail reliably), then it seems okay to me.
> 
> However, since I like pulling increasing numbers of my hats, someone should
> verify that the common embedded cat implementations are also okay with
> this.  For example, I haven't yet found any code in busybox's cat
> implementation that closes stdout.
> 
> Given that the main targets of this (for now, at least) are embedded, this
> might be a problem.
> 

I think we shouldn't focus on the cat implementation for the close issue.

My understanding about this action:
cat file.bin > /sys/..../capsule_loader
It is actually the ">" (IO redirection) who perform the open write & close
to this "/sys/..../capsule_loader" file note and not the "cat" do it.
So, I think your answer can be found at Shell source code.

More info about the IO redirection can be found at:
http://www.tldp.org/LDP/abs/html/io-redirection.html

Busybox Shell Souce code can be found at:
https://lxr.missinglinkelectronics.com/busybox/shell/ash.c


Regards,
Wilson