linux-kernel - Re: [PATCHv1 3/4] dt-bindings: fpga: add authenticate-fpga-config property

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20201119111430.GB26472@yilunxu-OptiPlex-7050>
Date:   Thu, 19 Nov 2020 19:14:30 +0800
From:   Xu Yilun <yilun.xu@...el.com>
To:     Richard Gong <richard.gong@...ux.intel.com>
Cc:     Moritz Fischer <mdf@...nel.org>, trix@...hat.com,
        linux-fpga@...r.kernel.org, linux-kernel@...r.kernel.org,
        dinguyen@...nel.org, sridhar.rajagopal@...el.com,
        Richard Gong <richard.gong@...el.com>
Subject: Re: [PATCHv1 3/4] dt-bindings: fpga: add authenticate-fpga-config
  property

On Wed, Nov 18, 2020 at 07:38:31AM -0600, Richard Gong wrote:
> 
> 
> On 11/17/20 11:47 PM, Xu Yilun wrote:
> >On Tue, Nov 17, 2020 at 09:39:55AM -0600, Richard Gong wrote:
> >>
> >>
> >>On 11/16/20 8:24 PM, Xu Yilun wrote:
> >>>On Mon, Nov 16, 2020 at 08:14:52AM -0600, Richard Gong wrote:
> >>>>
> >>>>Hi Yilun,
> >>>>
> >>>>On 11/15/20 8:47 PM, Xu Yilun wrote:
> >>>>>On Sun, Nov 15, 2020 at 11:21:06AM -0800, Moritz Fischer wrote:
> >>>>>>Hi Richard,
> >>>>>>
> >>>>>>On Thu, Nov 12, 2020 at 12:06:42PM -0600, richard.gong@...ux.intel.com wrote:
> >>>>>>>From: Richard Gong <richard.gong@...el.com>
> >>>>>>>
> >>>>>>>Add authenticate-fpga-config property for FPGA bitstream authentication.
> >>>>>>>
> >>>>>>>Signed-off-by: Richard Gong <richard.gong@...el.com>
> >>>>>>>---
> >>>>>>>  Documentation/devicetree/bindings/fpga/fpga-region.txt | 1 +
> >>>>>>>  1 file changed, 1 insertion(+)
> >>>>>>>
> >>>>>>>diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt b/Documentation/devicetree/bindings/fpga/fpga-region.txt
> >>>>>>>index e811cf8..7a512bc 100644
> >>>>>>>--- a/Documentation/devicetree/bindings/fpga/fpga-region.txt
> >>>>>>>+++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt
> >>>>>>>@@ -187,6 +187,7 @@ Optional properties:
> >>>>>>>  - external-fpga-config : boolean, set if the FPGA has already been configured
> >>>>>>>  	prior to OS boot up.
> >>>>>>>  - encrypted-fpga-config : boolean, set if the bitstream is encrypted
> >>>>>>>+- authenticate-fpga-config : boolean, set if do bitstream authentication
> >>>>>>It is unclear to me from the description whether this entails
> >>>>>>authentication + reconfiguration or just authentication.
> >>>>>>
> >>>>>>If the latter is the case this should probably be described as such.
> >>>>>
> >>>>>If it is just authentication, do we still need to disable bridges in
> >>>>>fpga_region_program_fpga?
> >>>>>
> >>>>
> >>>>Yes.
> >>>>
> >>>>Except for the actual configuration of the device, the authentication
> >>>>feature is the same as FPGA configuration.
> >>>
> >>>FPGA Bridges gate bus signals between a host and FPGA. So the FPGA
> >>>region could not be accessed by host when doing configuration. But for
> >>>this authentication, we are just writing the flash, we don't actually
> >>>touch the FPGA soft logic. The host should still be able to operate on
> >>>the old logic before reboot, is it?
> >>>
> >>Yes, it's feasible in theory but doesn't make much sense in practice. I
> >>prefer to keep fpga_region_program_fpga() unchanged.
> >
> >I'm thinking of the case of inband reprograming, that the QSPI flash
> >controller itself is embedded in FPGA soft logic, then maybe host still
> >need to access FPGA on authentication.
> 
> We can decide whether we should update fpga_region_program_fpga() function
> when you update for inband reprogramming case.

Sure, we could think about it later.

Thanks,
Yilun

> 
> Regards,
> Richard
> >
> >Thanks,
> >Yilun
> >
> >>>>
> >>>>>I'm wondering if the FPGA functionalities could still be working when
> >>>>>the authenticating is ongoing, or when the authenticating is failed.
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>>Thanks,
> >>>>>Yilun
> >>>>>
> >>>>>>
> >>>>>>>  - region-unfreeze-timeout-us : The maximum time in microseconds to wait for
> >>>>>>>  	bridges to successfully become enabled after the region has been
> >>>>>>>  	programmed.
> >>>>>>>-- 
> >>>>>>>2.7.4
> >>>>>>>
> >>>>>>
> >>>>>>Thanks