From: Jerome Glisse <jglisse@redhat.com> 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" <dri-devel@lists.freedesktop.org>, "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>, Cyril Chemparathy <cyrilc@xilinx.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Lizhi Hou <lizhih@xilinx.com>, Michal Simek <michals@xilinx.com>, "airlied@redhat.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 Date: Wed, 3 Apr 2019 11:47:36 -0400 [thread overview] Message-ID: <20190403154734.GA12818@redhat.com> (raw) In-Reply-To: <871s2pw4ld.fsf@fisel.enstb.org> 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. Cheers, Jérôme Glisse
WARNING: multiple messages have this Message-ID (diff)
From: Jerome Glisse <jglisse@redhat.com> 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" <dri-devel@lists.freedesktop.org>, "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>, Cyril Chemparathy <cyrilc@xilinx.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Lizhi Hou <lizhih@xilinx.com>, Michal Simek <michals@xilinx.com>, "airlied@redhat.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 Date: Wed, 3 Apr 2019 11:47:36 -0400 [thread overview] Message-ID: <20190403154734.GA12818@redhat.com> (raw) In-Reply-To: <871s2pw4ld.fsf@fisel.enstb.org> 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. Cheers, J�r�me Glisse
next prev parent reply other threads:[~2019-04-03 15:47 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-03-19 21:53 [RFC PATCH Xilinx Alveo 0/6] Xilinx PCIe accelerator driver sonal.santan 2019-03-19 21:53 ` sonal.santan 2019-03-19 21:53 ` [RFC PATCH Xilinx Alveo 1/6] Add skeleton code: ioctl definitions and build hooks sonal.santan 2019-03-19 21:53 ` sonal.santan 2019-03-19 21:53 ` [RFC PATCH Xilinx Alveo 2/6] Global data structures shared between xocl and xmgmt drivers sonal.santan 2019-03-19 21:53 ` sonal.santan 2019-03-19 21:53 ` [RFC PATCH Xilinx Alveo 3/6] Add platform drivers for various IPs and frameworks sonal.santan 2019-03-19 21:53 ` sonal.santan 2019-03-19 21:53 ` [RFC PATCH Xilinx Alveo 4/6] Add core of XDMA driver sonal.santan 2019-03-19 21:53 ` sonal.santan 2019-03-19 21:54 ` [RFC PATCH Xilinx Alveo 5/6] Add management driver sonal.santan 2019-03-19 21:54 ` sonal.santan 2019-03-19 21:54 ` [RFC PATCH Xilinx Alveo 6/6] Add user physical function driver sonal.santan 2019-03-19 21:54 ` sonal.santan 2019-03-25 20:28 ` [RFC PATCH Xilinx Alveo 0/6] Xilinx PCIe accelerator driver Daniel Vetter 2019-03-25 20:28 ` Daniel Vetter 2019-03-26 23:30 ` Sonal Santan 2019-03-27 8:22 ` Daniel Vetter 2019-03-27 12:50 ` Sonal Santan 2019-03-27 14:11 ` Daniel Vetter 2019-03-27 14:11 ` Daniel Vetter 2019-03-28 0:13 ` Sonal Santan 2019-03-29 4:56 ` Dave Airlie 2019-03-30 1:09 ` Ronan KERYELL 2019-03-30 1:09 ` Ronan KERYELL 2019-04-03 13:14 ` Daniel Vetter 2019-04-03 13:14 ` Daniel Vetter 2019-04-03 14:17 ` Moritz Fischer 2019-04-03 14:53 ` Daniel Vetter 2019-04-03 15:47 ` Jerome Glisse [this message] 2019-04-03 15:47 ` Jerome Glisse 2019-04-05 22:15 ` Sonal Santan
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190403154734.GA12818@redhat.com \ --to=jglisse@redhat.com \ --cc=airlied@gmail.com \ --cc=airlied@redhat.com \ --cc=cyrilc@xilinx.com \ --cc=daniel@ffwll.ch \ --cc=dri-devel@lists.freedesktop.org \ --cc=gregkh@linuxfoundation.org \ --cc=linux-fpga@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lizhih@xilinx.com \ --cc=michals@xilinx.com \ --cc=rkeryell@xilinx.com \ --cc=ronan@keryell.fr \ --cc=sonals@xilinx.com \ --cc=wittig@xilinx.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.