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: <20150417134924.GB19794@kroah.com>
Date:	Fri, 17 Apr 2015 15:49:24 +0200
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	"Kweh, Hock Leong" <hock.leong.kweh@...el.com>
Cc:	Ming Lei <ming.lei@...onical.com>,
	Matt Fleming <matt@...sole-pimps.org>,
	"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>,
	Peter Jones <pjones@...hat.com>,
	Andy Lutomirski <luto@...capital.net>,
	Roy Franz <roy.franz@...aro.org>,
	Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi
 firmware

On Thu, Apr 16, 2015 at 09:42:31AM +0000, Kweh, Hock Leong wrote:
> > -----Original Message-----
> > From: Greg Kroah-Hartman [mailto:gregkh@...uxfoundation.org]
> > Sent: Wednesday, April 15, 2015 9:19 PM
> > 
> > On Wed, Apr 15, 2015 at 11:32:29AM +0000, Kweh, Hock Leong wrote:
> > > > -----Original Message-----
> > > > From: Greg Kroah-Hartman [mailto:gregkh@...uxfoundation.org]
> > > > Sent: Tuesday, April 14, 2015 10:09 PM
> > > >
> > > > On Tue, Apr 14, 2015 at 05:44:56PM +0800, Kweh, Hock Leong wrote:
> > > > > From: "Kweh, Hock Leong" <hock.leong.kweh@...el.com>
> > > > >
> > > > > Introducing a kernel module to expose capsule loader interface
> > > > > for user to upload capsule binaries. This module leverage the
> > > > > request_firmware_direct_full_path() to obtain the binary at a
> > > > > specific path input by user.
> > > > >
> > > > > Example method to load the capsule binary:
> > > > > echo -n "/path/to/capsule/binary" >
> > > > /sys/devices/platform/efi_capsule_loader/capsule_loader
> > > >
> > > > Ick, why not just have the firmware file location present, and copy it
> > > > to the sysfs file directly from userspace, instead of this two-step
> > > > process?
> > >
> > > Err .... I may not catch your meaning correctly. Are you trying to say
> > > that you would prefer the user to perform:
> > >
> > > cat file.bin > /sys/.../capsule_loader
> > >
> > > instead of
> > >
> > > echo -n "/path/to/binary" > /sys/..../capsule_laoder
> > 
> > Yes.  What's the namespace of your /path/to/binary/ and how do you know
> > the kernel has the same one when it does the firmware load call?  By
> > just copying the data with 'cat', you don't have to worry about
> > namespace issues at all.
> 
> Hi Greg,
> 
> Let me double confirm that I understand your concern correctly. You are
> trying to tell that some others module may use a 'same' namespace to
> request the firmware but never release it. Then when our module trying
> to request the firmware by passing in the 'same' namespace, I will get the
> previous data instead of the current binary data from the path I want.

Yes.

> Hmm .... I believe this concern also apply to all the current request_firmware
> APIs right? And I believe the coincidence to have 'same' file name namespace
> would be higher than full path namespace.

Not really, the kernel namespace is what matters at that point in time.

And maybe it does matter, I haven't thought through all of the issues.
But passing a path from userspace, to the kernel, to have the kernel
turn around again and use that path is full of nasty consequences at
times due to namespaces, let's avoid all of that please.

thanks,

greg k-h
--
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/