On Sat 2014-12-06 13:00:17, Grant Likely wrote: > On Fri, Oct 24, 2014 at 11:52 AM, Pavel Machek <pavel@xxxxxxx> wrote: > > Hi! > > > >> * /sys/class/fpga_manager/<fpga>/firmware > >> Name of FPGA image file to load using firmware class. > >> $ echo image.rbf > /sys/class/fpga_manager/<fpga>/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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
