linux-kernel - Re: [PATCH 00/16] Intel FPGA Device Drivers

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: <20170414194817.GA27424@eluebber-mac02.jf.intel.com>
Date:   Fri, 14 Apr 2017 12:48:17 -0700
From:   "Luebbers, Enno" <enno.luebbers@...el.com>
To:     Jerome Glisse <jglisse@...hat.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 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.

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.

Thanks
- Enno