[PATCH 3/3] hash: Allow for SHA512 hardware implementations

[Ilias Apalodimas]

Hi, 

On Wed, May 12, 2021 at 06:19:58PM +0200, Heinrich Schuchardt wrote:
> On 12.05.21 18:05, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Wed, 12 May 2021 at 10:01, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> >>
> >> On 17.02.21 04:20, Joel Stanley wrote:
> >>> Similar to support for SHA1 and SHA256, allow the use of hardware hashing
> >>> engine by enabling the algorithm and setting  CONFIG_SHA_HW_ACCEL /
> >>> CONFIG_SHA_PROG_HW_ACCEL.
> >>>
> >>> Signed-off-by: Joel Stanley <joel at jms.id.au>
> >>
> >> This merged patch leads to errors compiling the EFI TCG2 protocol on
> >> boards with CONFIG_SHA_HW_ACCEL.
> >>
> >> There is not as single implementation of hw_sha384 and hw_sha512. You
> >> could only use CONFIG_SHA_HW_ACCEL for selecting these functions if
> >> these were implemented for *all* boards with CONFIG_SHA_HW_ACCEL=y. But
> >> this will never happen.
> >>
> >> *This patch needs to be reverted.*
> >>
> >> Why do we have CONFIG_SHA_HW_ACCEL at all and don't use weak functions
> >> instead?
> >
> > This is all a mess. We should not use weak functions IMO, but instead
> > have a driver interface, like we do with filesystems.
> >
> > Part of the challenge is the need to keep code size small for
> > platforms that only need one algorithm.
> 
> If a function is not referenced, the linker will eliminate it. But with
> a driver interface every function in the interface is referenced.
> 
> Best regards
> 
> Heinrich

There's a fundamental problem with TCG2. The algorithms you need to support
and log are dictated by the TPM2 hardware and it's configuration. That's a
thing we can't detect at build time.  

So since we don't know that, we are requiring support for all the known
algorithms U-Boot supports and are mandated from the spec (SHA1/256/384/512).
One way to solve this is move the 'select' to 'depends', and only allow for
the protocol,  if all the algorithms we need are present in the .config. 
But this is just a way to sidestep the problem for now.  I agree with Heinrich 
that using a single Kconfig isn't realistic.