linux-kernel - Re: [RFC 7/8] fpga-region: add sysfs interface

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]

Date:   Wed, 15 Feb 2017 11:46:01 -0600
From:   Alan Tull <delicious.quinoa@...il.com>
To:     Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Cc:     Moritz Fischer <moritz.fischer@...us.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-fpga@...r.kernel.org
Subject: Re: [RFC 7/8] fpga-region: add sysfs interface

On Wed, Feb 15, 2017 at 11:21 AM, Jason Gunthorpe
<jgunthorpe@...idianresearch.com> wrote:
> On Wed, Feb 15, 2017 at 10:14:20AM -0600, Alan Tull wrote:
>> Add a sysfs interface to control programming FPGA.
>>
>> Each fpga-region will get the following files which set values
>> in the fpga_image_info struct for that region.  More files will
>> need to be added as fpga_image_info expands.
>>
>> firmware_name
>> * writing a name of a FPGA image file to firmware_name causes the
>>   FPGA region to write the FPGA
>>
>> partial_config
>> * 0 : full reconfiguration
>> * 1 : partial reconfiguration
>
> This is really a property of the bitfile. It would be really nice to
> have a saner system for describing the bitfiles that doesn't rely on
> so much out of band stuff.
>
> Eg when doing partial reconfiguration it would be really sane to have
> some checks that the full bitfile is the correct basis for the partial
> bitfile.
>
> It also seems link Zynq needs an encrypted/not encrypted flag..
>
> I wonder if we should require a Linux specific header on the bitfile
> instead? That would make the bitfile self describing at least.

Hi Jason,

I agree.  I've heard some discussions about adding a header.  We would
want it to not be manufacturer or fpga device specific. That would be
nice and would eliminate some of this struct.  We would need a tool to
add the header, given a bitstream and some info about the bitstream.
If the tool communicated seamlessly with vendor's tools that would be
nice, but that is complicated to get that to happen.  So far nobody
has posted their proposals to the mailing list.

Alan

>
> Jason