From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Machek Subject: Re: [PATCH v2 2/3] fpga manager: framework core Date: Sat, 6 Dec 2014 15:02:18 +0100 Message-ID: <20141206140218.GB19672@amd> References: <1414007405-32186-1-git-send-email-atull@opensource.altera.com> <1414007405-32186-3-git-send-email-atull@opensource.altera.com> <20141024105200.GA20775@amd> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-doc-owner@vger.kernel.org To: Grant Likely Cc: atull@opensource.altera.com, Greg Kroah-Hartman , Jason Gunthorpe , "H. Peter Anvin" , Michal Simek , Michal Simek , Randy Dunlap , Linux Kernel Mailing List , "devicetree@vger.kernel.org" , Pantelis Antoniou , Rob Herring , Ira Snyder , "linux-doc@vger.kernel.org" , Mark Brown , philip@balister.org, rubini , Steffen Trumtrar , Jason , kyle.teske@ni.com, Nicolas Pitre , "Balbi, Felipe" , Mauro Carvalho Chehab , David Brown List-Id: devicetree@vger.kernel.org On Sat 2014-12-06 13:00:17, Grant Likely wrote: > On Fri, Oct 24, 2014 at 11:52 AM, Pavel Machek wrote: > > Hi! > > > >> * /sys/class/fpga_manager//firmware > >> Name of FPGA image file to load using firmware class. > >> $ echo image.rbf > /sys/class/fpga_manager//firmware > > > > I .. still don't think this is good idea. What about namespaces? > > The path corresponds to path in which namespace? > > I don't understand your concern here. This allows userspace to name > the FPGA bitstream that the kernel will use during request_firmware(), > and it will show up as the $FIRMWARE value in the uevent file, but it > is still the responsibility of userspace to choose what to load, and > it can freely ignore the setting of $FIRMWARE if it needs to. Well, consider chroot. I echo some filename but the file does not exist for the userspace listening for the uevent. > The process that actually loads the firmware into the kernel pretty > much has to run in the normal linux environment. How do namespaces > come into it? What exact problem do you see? > > This shows why the interface is not right... Valid filename may > > contain \n, right? It may even end with \n. > > That's not an interface problem, it implementation problem. The > function absolutely should scrub and validate it's input. It should > also make sure that the string doesn't have any special characters so > that /bin/sh doesn't barf on it (because the string will appear in the > uevent file). I would check other users of request_firmware() to see > if any of them allow userspace to specify the filename. > That said, the other way to handle this is not to specify a valid > filename through this interface at all. Just use a dummy placeholder > name and expect userspace to load the correct file when the request is > posted. I'd go for that -- "dummy" works. Kernel is not a place to know shell limitations for all possible shells. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html