Re: [PATCH 00/16] Intel FPGA Device Drivers
From: Moritz Fischer
Date: Wed Apr 12 2017 - 10:46:29 EST
Hi Jerome,
On Wed, Apr 12, 2017 at 6:29 AM, Jerome Glisse <jglisse@xxxxxxxxxx> wrote:
> On Tue, Apr 11, 2017 at 12:38:10PM -0700, Luebbers, Enno wrote:
>> Hi Jerome,
>>
>> On Thu, Apr 06, 2017 at 04:27:00PM -0400, Jerome Glisse wrote:
>>
>> > Do we have an open source toolchain to generate the FPGA configuration
>> > (bitstream) ? As it is required for the GPU sub-system that any driver
>> > API must comes with open source userspace.
I think the comparison lacks. No one seems to be bothered by the fact
that the GPUs
hardware is built using closed source CAD tools, even if open source drivers are
available. From an OS perspective the FPGA is hardware.
(Reconfigurable) but hardware.
A better comparison from my point of view would be loading a binary
firmware image ...
>> As far as I know, no FPGA vendor currently provides an open-source version of
>> their FPGA synthesis tools - there are, however, free (as in beer) versions
>> available for download that can be used for generating FPGA bitstreams. Also,
>> there are a number of projects to replace parts of the vendor tools with open
>> alternatives (yosys comes to mind, which I believe recently added initial
>> support for synthesizing logic for Intel FPGAs).
>>
>> As an aside, we are also working on an open-source user-space library that would
>> allow you to use this driver to load existing accelerator bitstreams as well as
>> enumerate and access accelerators present in the system. This would enable
>> workflows where users have access to e.g. a library of FPGA accelerator
>> bitstreams and want to write applications that take advantage of these
>> accelerators, even without having access to an FPGA synthesis tool.
>
> Yosys is not an open source toolchain is use quartus at least that is my
> understand from this commit:
> https://github.com/cliffordwolf/yosys/commit/c27dcc1e47fa00cd415893c9d3f637a5d5865988
>
>
> It is like if on GPU we only had close source compiler for the GPU
> instructions set. So FPGA is definitly following different rules than
> open source upstream GPU kernel driver abides to.
>
> I see this as highly problematic if not only for security purposes
> there is no way for anyone to audit how secure and sane the API you
> want to expose to userspace. Those FPGA might have connection to
> memory bus or device bus and thus they might get access to any memory.
It's up to the user to plug a specific piece of hardware into their
machine. After that it is
up to the user to decide whether he wants to load a bitstream that he
doesn't have the
source code for and that he needs to compile with closed source software.
Do you know if NVIDIA has backdoors in their GPU, Intel in their NIC,
or AMD in their
processor? What about that RTC, do you have the source code they
synthesized their
ASIC design from?
Maybe my mental model on FPGAs is different from yours so feel free to
disagree ;-)
Moritz