From: Pavel Machek <pavel@denx.de>
To: Grant Likely <grant.likely@linaro.org>
Cc: atull@opensource.altera.com,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
"H. Peter Anvin" <hpa@zytor.com>, Michal Simek <monstr@monstr.eu>,
Michal Simek <michal.simek@xilinx.com>,
Randy Dunlap <rdunlap@infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Pantelis Antoniou <pantelis.antoniou@konsulko.com>,
Rob Herring <robh+dt@kernel.org>,
Ira Snyder <iws@ovro.caltech.edu>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
Mark Brown <broonie@kernel.org>,
philip@balister.org, rubini <rubini@gnudd.com>,
Steffen Trumtrar <s.trumtrar@pengutronix.de>,
Jason <jason@lakedaemon.net>,
kyle.teske@ni.com, Nicolas Pitre <nico@linaro.org>,
"Balbi, Felipe" <balbi@ti.com>,
Mauro Carvalho Chehab <m.chehab@samsung.com>,
David Brown <davidb@c>
Subject: Re: [PATCH v2 2/3] fpga manager: framework core
Date: Sat, 6 Dec 2014 15:02:18 +0100 [thread overview]
Message-ID: <20141206140218.GB19672@amd> (raw)
In-Reply-To: <CACxGe6sa=ysJAjx5TQZH5sKoas1PkoUUR4zT=Z35+uF6rrk-vw@mail.gmail.com>
On Sat 2014-12-06 13:00:17, Grant Likely wrote:
> On Fri, Oct 24, 2014 at 11:52 AM, Pavel Machek <pavel@denx.de> 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
WARNING: multiple messages have this Message-ID (diff)
From: Pavel Machek <pavel@denx.de>
To: Grant Likely <grant.likely@linaro.org>
Cc: atull@opensource.altera.com,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
"H. Peter Anvin" <hpa@zytor.com>, Michal Simek <monstr@monstr.eu>,
Michal Simek <michal.simek@xilinx.com>,
Randy Dunlap <rdunlap@infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Pantelis Antoniou <pantelis.antoniou@konsulko.com>,
Rob Herring <robh+dt@kernel.org>,
Ira Snyder <iws@ovro.caltech.edu>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
Mark Brown <broonie@kernel.org>,
philip@balister.org, rubini <rubini@gnudd.com>,
Steffen Trumtrar <s.trumtrar@pengutronix.de>,
Jason <jason@lakedaemon.net>,
kyle.teske@ni.com, Nicolas Pitre <nico@linaro.org>,
"Balbi, Felipe" <balbi@ti.com>,
Mauro Carvalho Chehab <m.chehab@samsung.com>,
David Brown <davidb@codeaurora.org>,
Rob Landley <rob@landley.net>, David Miller <davem@davemloft.net>,
cesarb@cesarb.net,
"sameo@linux.intel.com" <sameo@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Walleij <linus.walleij@linaro.org>,
Alan Tull <delicious.quinoa@gmail.com>,
dinguyen@opensource.altera.com,
Yves Vandervennet <yvanderv@opensource.altera.com>
Subject: Re: [PATCH v2 2/3] fpga manager: framework core
Date: Sat, 6 Dec 2014 15:02:18 +0100 [thread overview]
Message-ID: <20141206140218.GB19672@amd> (raw)
In-Reply-To: <CACxGe6sa=ysJAjx5TQZH5sKoas1PkoUUR4zT=Z35+uF6rrk-vw@mail.gmail.com>
On Sat 2014-12-06 13:00:17, Grant Likely wrote:
> On Fri, Oct 24, 2014 at 11:52 AM, Pavel Machek <pavel@denx.de> 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
next prev parent reply other threads:[~2014-12-06 14:02 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-22 19:50 [PATCH v2 0/3] FPGA Framework with DT and sysfs support atull-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx
2014-10-22 19:50 ` atull
2014-10-22 19:50 ` [PATCH v2 1/3] fpga manager: add sysfs interface document atull
2014-10-22 19:50 ` atull
2014-10-22 19:50 ` [PATCH v2 2/3] fpga manager: framework core atull
2014-10-22 19:50 ` atull
2014-10-24 10:52 ` Pavel Machek
2014-10-24 10:55 ` Pantelis Antoniou
2014-10-24 10:55 ` Pantelis Antoniou
2014-10-24 14:54 ` atull
2014-10-24 14:54 ` atull
2014-12-06 13:01 ` Grant Likely
2014-12-06 13:01 ` Grant Likely
2014-12-06 13:55 ` Pavel Machek
2014-12-06 13:55 ` Pavel Machek
2014-12-08 17:50 ` Grant Likely
2014-12-08 17:50 ` Grant Likely
2014-12-08 17:56 ` Grant Likely
2014-12-08 17:56 ` Grant Likely
2014-12-08 17:56 ` Pantelis Antoniou
2014-12-08 17:56 ` Pantelis Antoniou
2014-12-08 18:30 ` Grant Likely
2014-12-08 18:30 ` Grant Likely
2014-12-08 20:53 ` Rob Landley
2014-12-08 20:53 ` Rob Landley
2014-10-24 21:00 ` One Thousand Gnomes
2014-12-06 13:00 ` Grant Likely
2014-12-06 13:00 ` Grant Likely
2014-12-06 14:02 ` Pavel Machek [this message]
2014-12-06 14:02 ` Pavel Machek
[not found] ` <CACxGe6sa=ysJAjx5TQZH5sKoas1PkoUUR4zT=Z35+uF6rrk-vw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-12-08 22:55 ` One Thousand Gnomes
2014-12-08 22:55 ` One Thousand Gnomes
2014-12-09 13:11 ` Grant Likely
2014-12-09 13:11 ` Grant Likely
2014-12-09 13:42 ` Michal Simek
2014-12-09 13:42 ` Michal Simek
2014-12-09 16:07 ` atull
2014-12-09 16:07 ` atull
2014-12-09 21:02 ` One Thousand Gnomes
2014-12-09 21:02 ` One Thousand Gnomes
2014-12-09 22:12 ` atull
2014-12-09 22:12 ` atull
2014-12-12 12:14 ` Pavel Machek
2014-12-12 12:14 ` Pavel Machek
2014-12-18 20:50 ` atull
2014-12-18 20:50 ` atull
2014-10-22 19:50 ` [PATCH v2 3/3] fpga manager: bus driver atull
2014-10-22 19:50 ` atull
2014-10-22 22:22 ` atull
2014-10-22 22:22 ` atull
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141206140218.GB19672@amd \
--to=pavel@denx.de \
--cc=atull@opensource.altera.com \
--cc=balbi@ti.com \
--cc=broonie@kernel.org \
--cc=davidb@c \
--cc=devicetree@vger.kernel.org \
--cc=grant.likely@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=iws@ovro.caltech.edu \
--cc=jason@lakedaemon.net \
--cc=jgunthorpe@obsidianresearch.com \
--cc=kyle.teske@ni.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.chehab@samsung.com \
--cc=michal.simek@xilinx.com \
--cc=monstr@monstr.eu \
--cc=nico@linaro.org \
--cc=pantelis.antoniou@konsulko.com \
--cc=philip@balister.org \
--cc=rdunlap@infradead.org \
--cc=robh+dt@kernel.org \
--cc=rubini@gnudd.com \
--cc=s.trumtrar@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.