Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754247AbdDLPhz (ORCPT ); Wed, 12 Apr 2017 11:37:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38400 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752384AbdDLPhx (ORCPT ); Wed, 12 Apr 2017 11:37:53 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2B854C057FA6 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jglisse@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 2B854C057FA6 Date: Wed, 12 Apr 2017 11:37:49 -0400 From: Jerome Glisse To: Moritz Fischer Cc: "Luebbers, Enno" , 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: <20170412153746.GA17158@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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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.32]); Wed, 12 Apr 2017 15:37:52 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4322 Lines: 89 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 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