lkml.org 
[lkml]   [2019]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [RFC PATCH Xilinx Alveo 0/6] Xilinx PCIe accelerator driver
Date


> -----Original Message-----
> From: Jerome Glisse [mailto:jglisse@redhat.com]
> Sent: Wednesday, April 03, 2019 8:48 AM
> To: Ronan KERYELL <ronan@keryell.fr>
> Cc: Dave Airlie <airlied@gmail.com>; Sonal Santan <sonals@xilinx.com>;
> Daniel Vetter <daniel@ffwll.ch>; dri-devel@lists.freedesktop.org;
> gregkh@linuxfoundation.org; Cyril Chemparathy <cyrilc@xilinx.com>; linux-
> kernel@vger.kernel.org; Lizhi Hou <lizhih@xilinx.com>; Michal Simek
> <michals@xilinx.com>; airlied@redhat.com; linux-fpga@vger.kernel.org; Ralph
> Wittig <wittig@xilinx.com>; Ronan Keryell <rkeryell@xilinx.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@vger.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@gmail.com>
> said:
> > Dave> On Thu, 28 Mar 2019 at 10:14, Sonal Santan <sonals@xilinx.com>
> wrote:
> > >>> From: Daniel Vetter [mailto:daniel.vetter@ffwll.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

\
 
 \ /
  Last update: 2019-04-06 00:15    [W:0.096 / U:3.852 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site