Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754586AbdDNUuC (ORCPT ); Fri, 14 Apr 2017 16:50:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47604 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751578AbdDNUuA (ORCPT ); Fri, 14 Apr 2017 16:50:00 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8AFAF85542 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jglisse@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 8AFAF85542 Date: Fri, 14 Apr 2017 16:49:56 -0400 From: Jerome Glisse To: "Luebbers, Enno" Cc: Moritz Fischer , Wu Hao , Alan Tull , linux-fpga@vger.kernel.org, Linux Kernel Mailing List , luwei.kang@intel.com, yi.z.zhang@intel.com Subject: Re: [PATCH 00/16] Intel FPGA Device Drivers Message-ID: <20170414204955.GA4805@redhat.com> References: <1490875696-15145-1-git-send-email-hao.wu@intel.com> <20170406202700.GA3674@redhat.com> <20170411193806.GA33858@eluebber-mac02.jf.intel.com> <20170412132919.GA16072@redhat.com> <20170412153746.GA17158@redhat.com> <20170414194817.GA27424@eluebber-mac02.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170414194817.GA27424@eluebber-mac02.jf.intel.com> User-Agent: Mutt/1.8.0 (2017-02-23) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Fri, 14 Apr 2017 20:49:59 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4075 Lines: 74 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 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