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

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: <CACxGe6uy7FhAPC4PU8ciNEgg7d+oV+GR=8wYrO1YD7UuUfy7Bw@mail.gmail.com>
Date:	Mon, 8 Dec 2014 18:30:56 +0000
From:	Grant Likely <grant.likely@...aro.org>
To:	Pantelis Antoniou <pantelis.antoniou@...sulko.com>
Cc:	Pavel Machek <pavel@...x.de>, atull <atull@...nsource.altera.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	"H. Peter Anvin" <hpa@...or.com>, Michal Simek <monstr@...str.eu>,
	Michal Simek <michal.simek@...inx.com>,
	Randy Dunlap <rdunlap@...radead.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Rob Herring <robh+dt@...nel.org>,
	Ira Snyder <iws@...o.caltech.edu>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	Mark Brown <broonie@...nel.org>,
	Philip Balister <philip@...ister.org>,
	rubini <rubini@...dd.com>,
	Steffen Trumtrar <s.trumtrar@...gutronix.de>,
	Jason <jason@...edaemon.net>, kyle.teske@...com,
	Nicolas Pitre <nico@...aro.org>, Felipe Balbi <balbi@...com>,
	Mauro Carvalho Chehab <m.chehab@...sung.com>,
	David Brown <davidb@...eaurora.org>,
	Rob Landley <rob@...dley.net>,
	David Miller <davem@...emloft.net>, cesarb@...arb.net,
	"sameo@...ux.intel.com" <sameo@...ux.intel.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	Alan Tull <delicious.quinoa@...il.com>,
	dinguyen@...nsource.altera.com,
	Yves Vandervennet <yvanderv@...nsource.altera.com>
Subject: Re: [PATCH v2 2/3] fpga manager: framework core

On Mon, Dec 8, 2014 at 5:56 PM, Pantelis Antoniou
<pantelis.antoniou@...sulko.com> wrote:
> Hi Grant,
>
>> On Dec 8, 2014, at 19:50 , Grant Likely <grant.likely@...aro.org> wrote:
>>
>> On Sat, 6 Dec 2014 14:55:33 +0100
>> , Pavel Machek <pavel@...x.de>
>> 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.
>>
>
> Please, lets not depend at all on udev. Firmware can be embedded in the kernel
> image, which is pretty important to work before userland if you have to have
> the rootfs on a device that's instantiated via an FPGA bitstream.

It sounds like there are two issues here. One is the loading of a
default image (like when built into the kernel), and the other is
selecting between multiple firmware files, but the kernel won't know
which without either userspace or firmware assistance. For the second
issue is sounds to me like the rules for choosing between multiple
images needs to be well defined. Echoing an arbitrary filename into
the sysfs interface is too loosely defined.

g.
--
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/