Re: [PATCH v2 2/3] fpga manager: framework core

[Grant Likely]

On Sat, 6 Dec 2014 14:55:33 +0100
, Pavel Machek <pavel@xxxxxxx>
 wrote:
> Hi!
> 
> > > I am accustomed to doing 'echo -n' for most of sysfs anyway.  Once in a
> > > while I am a bonehead and forget the '-n' and spend a few minutes
> > > wondering why this thing that worked last week suddenly rejects all
> > > commands.  I'm just trying to make my user interface a bit user-friendly.
> > >
> > > I will take out the '\n' stripping and update the documentation.  I didn't
> > > realize this would be controversial.
> > 
> > Don't. You're doing the right thing by scrubbing your input. Requiring
> > 'echo -n' is just stupid when it is so easy to make work easily.
> 
> 'foo\nbar\n' is unusual but valid filename in linux. It is bad idea to
> echo filenames into files in the first place... and arbitrarily
> disallowing certain filenames is not helping.

Meh. Just because it is a valid linux filename doesn't mean this
interface is forced to accept it. There should be tighter rules about
how the filename can be constructed. Allowing any arbitrary path for any
arbitrary valid linux filename makes for a large attack surface.

I would like to know, what is the purpose of the interface? Why is it
important to provide the firmware filename in this manor? Are there
going to be a lot of different FPGA bitstreams that may need to be
loaded? How does userspace choose between them, and is there a better
way to do the selection without passing the firmware filename through
the kernel? Is this merely intended to get udev to behave in a certain
way? If so, then maybe there is a better way to go about it.

We could for example use a UDEV 'PROGRAM=' rule to execute a userspace
app and have that program figure out which firmware file to provide to
the kernel.

g.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/