From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754559AbdDLOqX (ORCPT ); Wed, 12 Apr 2017 10:46:23 -0400 Received: from mail-qk0-f179.google.com ([209.85.220.179]:35677 "EHLO mail-qk0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754505AbdDLOqU (ORCPT ); Wed, 12 Apr 2017 10:46:20 -0400 MIME-Version: 1.0 In-Reply-To: <20170412132919.GA16072@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> From: Moritz Fischer Date: Wed, 12 Apr 2017 07:46:19 -0700 Message-ID: Subject: Re: [PATCH 00/16] Intel FPGA Device Drivers To: Jerome Glisse 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 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 ... >> 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? Maybe my mental model on FPGAs is different from yours so feel free to disagree ;-) Moritz