Message-ID: <20170414204955.GA4805@redhat.com>
Date:   Fri, 14 Apr 2017 16:49:56 -0400
From:   Jerome Glisse <jglisse@...hat.com>
To:     "Luebbers, Enno" <enno.luebbers@...el.com>
Cc:     Moritz Fischer <moritz.fischer@...us.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 Fri, Apr 14, 2017 at 12:48:17PM -0700, Luebbers, Enno wrote:
> On Wed, Apr 12, 2017 at 11:37:49AM -0400, Jerome Glisse wrote:
> > On Wed, Apr 12, 2017 at 07:46:19AM -0700, Moritz Fischer wrote:
> > > On Wed, Apr 12, 2017 at 6:29 AM, Jerome Glisse <jglisse@...hat.com> wrote:
> > >
> > > > 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.
> 
> If you're worried about an accelerator on an FPGA going rogue and accessing
> arbitrary host memory, consider that other (non-FPGA) hardware devices could
> potentially do that, too (e.g. a PCIe device with a programmable DMA engine).
> So this is not really an FPGA-specific concern.

Yes but linux kernel driver for those is auditable we can check how such DMA
engine are programmed and in many case userspace do not even have any control
on those (nor indirect nor direct). For the few driver that expose such DMA
engine to userspace we can audit the ioctl and see if they can be abuse to do
rogue DMA.


> Also, I don't think having an open-source toolchain would help defend against
> these kind of attacks at all. Just because you can generate bitstreams with an
> open-source tool doesn't prevent the attacker from loading his own bitstreams.
> Instead, you'll need to make sure that their bitstream (open-source or not), or,
> in fact, any device, is prevented from accessing memory it's not authorized to
> access, e.g. with an IOMMU programmed via the kernel's DMA API.
> 
> But that's not a toolchain issue.

Open source toolchain allows to audit all the in and out of the fpga, to know
how you can connect the fpga logic to the outside world and to know how this
inter-connect interface with the fpga fabrics. Without such knowledge we are
left to believe that the fpga logic can only go through some dedicated block
that itself have to go through IOMMU. So it is security through obscurity.


Note that security is just an example of why open source toolchain matter.
But this is a more fundamental issue in respect to linux kernel rules. Like
i said such thing would be totaly forbidden for the GPU driver and for any
other upstream driver in the linux kernel. It seems that the FPGA folks got
granted an exception that was never granted to anyone else and i would like
to know why.

No driver in kernel without open source userspace have been the rule for all
the other drivers. Just open sourcing some helper that load the bitstream does
not cut it in my view.

Jérôme

Powered by blists - more mailing lists