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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <X7m6gy/B8DiafyYQ@archbook>
Date:   Sat, 21 Nov 2020 17:10:27 -0800
From:   Moritz Fischer <mdf@...nel.org>
To:     Richard Gong <richard.gong@...ux.intel.com>
Cc:     Moritz Fischer <mdf@...nel.org>, gregkh@...uxfoundation.org,
        trix@...hat.com, linux-fpga@...r.kernel.org,
        linux-kernel@...r.kernel.org, dinguyen@...nel.org,
        sridhar.rajagopal@...el.com, richard.gong@...el.com
Subject: Re: [PATCHv2 1/5] firmware: stratix10-svc: add
 COMMAND_AUTHENTICATE_BITSTREAM flag

Richard,

On Wed, Nov 18, 2020 at 12:16:09PM -0600, Richard Gong wrote:

> > > -#define COMMAND_RECONFIG_FLAG_PARTIAL	1
> > > +#define COMMAND_RECONFIG_FLAG_PARTIAL	0
> > > +#define COMMAND_AUTHENTICATE_BITSTREAM	1
> > 
> > Can you explain how this commit by itself doesn't break things?
> > 
> > Before this change firmware expected BIT(0) to be set for partial
> > reconfiguration, now BIT(0) suddenly means authentication? How doest his
> > work? :)
> >  > Was there a firmware version change? Did this never work before?
> > 
> > If this is version depenedent for firmware, then this might need a
> > different compatible string / id / some form of probing?
> > 
> > Entirely possible that I'm missing something, but it doesn't *seem*
> > right.
> 
> It did work before.
> 
> Before this change, firmware only checks if the received flag value is zero.
> If the value is zero, it preforms full reconfiguration. Otherwise it does
> partial reconfiguration.
> 
> To support bitstream authentication feature, firmware is updated to check
> the received flag value as below:
> 	0	--- full reconfiguration
> 	BIT(0) 	--- partial reconfiguration
> 	BIT(1) 	--- bitstream authentication

So there are two different versions of firmware involved that behave
differently? 

Old firmware:
- ctype.flags  = 0x0 -> Full reconfig
- ctype.flags != 0 -> Partial reconfig

New firmware:
- ctype.flags = 0x0 -> Full reconfig
- ctype.flags = 0x1 -> Partial reconfig
- ctype.flags = 0x2 -> Authenticate

Old software:
- Send 0x0 for Full
- Send 0x1 for Partial

New software:
- Send 0x0 for Full
- Send 0x1 for Partial
- Send 0x2 for Auth

If I send request for authentication BIT(1) (new software) to old
firmware it'd try and attempt a partial reconfiguration with the data I
send? Is that safe?

Is there a way for software to figure out the firmware version and do
the right thing?

> Therefore I have updated the command flag setting at Intel service layer
> driver to align with firmware.
> 
> Regards,
> Richard
> 
> > >   /**
> > >    * Timeout settings for service clients:
> > > -- 
> > > 2.7.4
> > > 
> > 
> > Cheers,
> > Moritz
> > 

Thanks,
Moritz

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ