> -----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
