Message-ID: <20170412153746.GA17158@redhat.com>
Date:   Wed, 12 Apr 2017 11:37:49 -0400
From:   Jerome Glisse <jglisse@...hat.com>
To:     Moritz Fischer <moritz.fischer@...us.com>
Cc:     "Luebbers, Enno" <enno.luebbers@...el.com>,
        Wu Hao <hao.wu@...el.com>, Alan Tull <atull@...nel.org>,
        linux-fpga@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        luwei.kang@...el.com, yi.z.zhang@...el.com
Subject: Re: [PATCH 00/16] Intel FPGA Device Drivers

On Wed, Apr 12, 2017 at 07:46:19AM -0700, Moritz Fischer wrote:
> Hi Jerome,
> 
> On Wed, Apr 12, 2017 at 6:29 AM, Jerome Glisse <jglisse@...hat.com> 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 ...

I disagree here, Altera or Xilinx provide OpenCL implementation that allows
to use FPGA. Moreover FPGA are way more capable that micro-controller on
which vast majority of firmware are running.


> >> 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?

User do not always know what program their executing. Think someone browsing
some random website, through javascript program you might be able to escape
the web browser and look for fpga device file, if on is present then it
might be able to load a bitstream that would allow it to overwritte system
memory and gain root privilege.

Even if you restrict the ioctl to upload bitstream to root user or some
privilege user, you have to think about VM world. Someone from inside a
vm that has access to an fpga device might be able to upload a bitstream
that would allow to escape the vm and gain root privilege on the host
operating system.

Security expert have proven over and over that no matter how unlikely a
path looks to you, no matter how hard, they will eventualy leverage it.


So you ignoring this issue doesn't make it less real. Pretending that
"secret" bitstream protect you or that only user will load a bitstream
is burying your head in the sand.


So yes knowing the bitstream and links the device has is necessary to be
able to evaluate the security implication of what the kernel fpga driver
are doing.

Cheers,
Jérôme

Powered by blists - more mailing lists