Date:   Fri, 5 Apr 2019 22:15:21 +0000
From:   Sonal Santan <sonals@...inx.com>
To:     Jerome Glisse <jglisse@...hat.com>,
        Ronan KERYELL <ronan@...yell.fr>
CC:     Dave Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        Cyril Chemparathy <cyrilc@...inx.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Lizhi Hou <lizhih@...inx.com>,
        Michal Simek <michals@...inx.com>,
        "airlied@...hat.com" <airlied@...hat.com>,
        "linux-fpga@...r.kernel.org" <linux-fpga@...r.kernel.org>,
        Ralph Wittig <wittig@...inx.com>,
        Ronan Keryell <rkeryell@...inx.com>
Subject: RE: [RFC PATCH Xilinx Alveo 0/6] Xilinx PCIe accelerator driver



> -----Original Message-----
> From: Jerome Glisse [mailto:jglisse@...hat.com]
> Sent: Wednesday, April 03, 2019 8:48 AM
> To: Ronan KERYELL <ronan@...yell.fr>
> Cc: Dave Airlie <airlied@...il.com>; Sonal Santan <sonals@...inx.com>;
> Daniel Vetter <daniel@...ll.ch>; dri-devel@...ts.freedesktop.org;
> gregkh@...uxfoundation.org; Cyril Chemparathy <cyrilc@...inx.com>; linux-
> kernel@...r.kernel.org; Lizhi Hou <lizhih@...inx.com>; Michal Simek
> <michals@...inx.com>; airlied@...hat.com; linux-fpga@...r.kernel.org; Ralph
> Wittig <wittig@...inx.com>; Ronan Keryell <rkeryell@...inx.com>
> Subject: Re: [RFC PATCH Xilinx Alveo 0/6] Xilinx PCIe accelerator driver
> 
> On Fri, Mar 29, 2019 at 06:09:18PM -0700, Ronan KERYELL wrote:
> > I am adding linux-fpga@...r.kernel.org, since this is why I missed
> > this thread in the first place...
> > >>>>> On Fri, 29 Mar 2019 14:56:17 +1000, Dave Airlie <airlied@...il.com>
> said:
> >     Dave> On Thu, 28 Mar 2019 at 10:14, Sonal Santan <sonals@...inx.com>
> wrote:
> >     >>> From: Daniel Vetter [mailto:daniel.vetter@...ll.ch]
> 
> [...]
> 
> > Long answer:
> >
> > - processors, GPU and other digital circuits are designed from a lot of
> >   elementary transistors, wires, capacitors, resistors... using some
> >   very complex (and expensive) tools from some EDA companies but at the
> >   end, after months of work, they come often with a "simple" public
> >   interface, the... instruction set! So it is rather "easy" at the end
> >   to generate some instructions with a compiler such as LLVM from a
> >   description of this ISA or some reverse engineering. Note that even if
> >   the ISA is public, it is very difficult to make another efficient
> >   processor from scratch just from this ISA, so there is often no
> >   concern about making this ISA public to develop the ecosystem ;
> >
> > - FPGA are field-programmable gate arrays, made also from a lot of
> >   elementary transistors, wires, capacitors, resistors... but organized
> >   in billions of very low-level elementary gates, memory elements, DSP
> >   blocks, I/O blocks, clock generators, specific
> >   accelerators... directly exposed to the user and that can be
> >   programmed according to a configuration memory (the bitstream) that
> >   details how to connect each part, routing element, configuring each
> >   elemental piece of hardware.  So instead of just writing instructions
> >   like on a CPU or a GPU, you need to configure each bit of the
> >   architecture in such a way it does something interesting for
> >   you. Concretely, you write some programs in RTL languages (Verilog,
> >   VHDL) or higher-level (C/C++, OpenCL, SYCL...)  and you use some very
> >   complex (and expensive) tools from some EDA companies to generate the
> >   bitstream implementing an equivalent circuit with the same
> >   semantics. Since the architecture is so low level, there is a direct
> >   mapping between the configuration memory (bitstream) and the hardware
> >   architecture itself, so if it is public then it is easy to duplicate
> >   the FPGA itself and to start a new FPGA company. That is unfortunately
> >   something the existing FPGA companies do not want... ;-)
> 
> This is completely bogus argument, all FPGA documentation i have seen so far
> _extensively_ describe _each_ basic blocks within the FGPA, this does include
> the excelent documentation Xilinx provide on the inner working and layout of
> Xilinx FPGA. Same apply to Altera, Atmel, Latice, ...
> 
> The extensive public documentation is enough for anyone with the money
> and with half decent engineers to produce an FPGA.
> 
> The real know how of FPGA vendor is how to produce big chips on small
> process capable to sustain high clock with the best power consumption
> possible. This is the part where the years of experiences of each company pay
> off. The cost for anyone to come to the market is in the hundred of millions
> just in setup cost and to catch with established vendor on the hardware side.
> This without any garanty of revenue at the end.
> 
> The bitstream is only giving away which bits correspond to which wire where
> the LUT boolean table is store  ... Bitstream that have been reverse engineer
> never revealed anything of value that was not already publicly documented.
> 
> 
> So no the bitstream has _no_ value, please prove me wrong with Latice
> bitstream for instance. If anything the fact that Latice has a reverse engineer
> bitstream has made that FPGA popular with the maker community as it allows
> people to do experiment for which the closed source tools are an
> impediment. So i would argue that open bitstream is actualy beneficial.
> 
> 
> The only valid reason i have ever seen for hidding the bitstream is to protect
> the IP of the customer ie those customer that can pour quite a lot of money
> on designing something with an FPGA and then wants to keep the
> VHDL/Verilog protected and "safe" from reverse engineering.
> 
> But this is security by obscurity and FPGA company would be better off
> providing strong bitstream encryption (and most already do but i have seen
> some paper on how to break them).
> 
> 
> I rather not see any bogus argument to try to justify something that is not
> justifiable.
> 
> 
> Daniel already stressed that we need to know what the bitstream can do and
> it is even more important with FPGA where on some FPGA AFAICT the
> bitstream can have total control over the PCIE BUS and thus can be use to
> attack either main memory or other PCIE devices.
> 
> For instance with ATS/PASID you can have the device send pre-translated
> request to the IOMMU and access any memory despite the IOMMU.
> 
> So without total confidence of what the bitstream can and can not do, and
> thus without knowledge of the bitstream format and how it maps to LUT,
> switch, cross- bar, clock, fix block (PCIE, DSP, DAC, ADC, ...) there is no way for
> someone independant to check anything.
> 
> 

Thank you for your time and valuable feedback. I will work on addressing these 
and get back. 

-Sonal
> Cheers,
> Jérôme Glisse

Powered by blists - more mailing lists