RE: [RFC PATCH Xilinx Alveo 0/6] Xilinx PCIe accelerator driver

[Sonal Santan]

> -----Original Message-----
> From: Jerome Glisse [mailto:jglisse@xxxxxxxxxx]
> Sent: Wednesday, April 03, 2019 8:48 AM
> To: Ronan KERYELL <ronan@xxxxxxxxxx>
> Cc: Dave Airlie <airlied@xxxxxxxxx>; Sonal Santan <sonals@xxxxxxxxxx>;
> Daniel Vetter <daniel@xxxxxxxx>; dri-devel@xxxxxxxxxxxxxxxxxxxxx;
> gregkh@xxxxxxxxxxxxxxxxxxx; Cyril Chemparathy <cyrilc@xxxxxxxxxx>; linux-
> kernel@xxxxxxxxxxxxxxx; Lizhi Hou <lizhih@xxxxxxxxxx>; Michal Simek
> <michals@xxxxxxxxxx>; airlied@xxxxxxxxxx; linux-fpga@xxxxxxxxxxxxxxx; Ralph
> Wittig <wittig@xxxxxxxxxx>; Ronan Keryell <rkeryell@xxxxxxxxxx>
> 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@xxxxxxxxxxxxxxx, since this is why I missed
> > this thread in the first place...
> > >>>>> On Fri, 29 Mar 2019 14:56:17 +1000, Dave Airlie <airlied@xxxxxxxxx>
> said:
> >     Dave> On Thu, 28 Mar 2019 at 10:14, Sonal Santan <sonals@xxxxxxxxxx>
> wrote:
> >     >>> From: Daniel Vetter [mailto:daniel.vetter@xxxxxxxx]
> 
> [...]
> 
> > 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