| Message ID | 20210217032042.425512-4-joel@jms.id.au |
|---|---|
| State | Accepted |
| Commit | a479f103dc1c801d0c6fe90bbaf99ae1700a84dc |
| Headers | show |
| Series | Improvements to FIT hashing | expand |
On Wed, Feb 17, 2021 at 01:50:42PM +1030, 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@jms.id.au> Applied to u-boot/master, thanks! -- Tom
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@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? Best regards Heinrich > --- > common/hash.c | 24 ++++++++++++++++++++++-- > include/hw_sha.h | 26 ++++++++++++++++++++++++++ > lib/Kconfig | 15 +++++++-------- > 3 files changed, 55 insertions(+), 10 deletions(-) > > diff --git a/common/hash.c b/common/hash.c > index fc64002f736a..10dff7ddb0e7 100644 > --- a/common/hash.c > +++ b/common/hash.c > @@ -97,7 +97,7 @@ static int hash_finish_sha256(struct hash_algo *algo, void *ctx, void > } > #endif > > -#if defined(CONFIG_SHA384) > +#if defined(CONFIG_SHA384) && !defined(CONFIG_SHA_PROG_HW_ACCEL) > static int hash_init_sha384(struct hash_algo *algo, void **ctxp) > { > sha512_context *ctx = malloc(sizeof(sha512_context)); > @@ -125,7 +125,7 @@ static int hash_finish_sha384(struct hash_algo *algo, void *ctx, void > } > #endif > > -#if defined(CONFIG_SHA512) > +#if defined(CONFIG_SHA512) && !defined(CONFIG_SHA_PROG_HW_ACCEL) > static int hash_init_sha512(struct hash_algo *algo, void **ctxp) > { > sha512_context *ctx = malloc(sizeof(sha512_context)); > @@ -260,10 +260,20 @@ static struct hash_algo hash_algo[] = { > .name = "sha384", > .digest_size = SHA384_SUM_LEN, > .chunk_size = CHUNKSZ_SHA384, > +#ifdef CONFIG_SHA_HW_ACCEL > + .hash_func_ws = hw_sha384, > +#else > .hash_func_ws = sha384_csum_wd, > +#endif > +#ifdef CONFIG_SHA_PROG_HW_ACCEL > + .hash_init = hw_sha_init, > + .hash_update = hw_sha_update, > + .hash_finish = hw_sha_finish, > +#else > .hash_init = hash_init_sha384, > .hash_update = hash_update_sha384, > .hash_finish = hash_finish_sha384, > +#endif > }, > #endif > #ifdef CONFIG_SHA512 > @@ -271,10 +281,20 @@ static struct hash_algo hash_algo[] = { > .name = "sha512", > .digest_size = SHA512_SUM_LEN, > .chunk_size = CHUNKSZ_SHA512, > +#ifdef CONFIG_SHA_HW_ACCEL > + .hash_func_ws = hw_sha512, > +#else > .hash_func_ws = sha512_csum_wd, > +#endif > +#ifdef CONFIG_SHA_PROG_HW_ACCEL > + .hash_init = hw_sha_init, > + .hash_update = hw_sha_update, > + .hash_finish = hw_sha_finish, > +#else > .hash_init = hash_init_sha512, > .hash_update = hash_update_sha512, > .hash_finish = hash_finish_sha512, > +#endif > }, > #endif > { > diff --git a/include/hw_sha.h b/include/hw_sha.h > index 15b1a1c79836..d4f3471c4308 100644 > --- a/include/hw_sha.h > +++ b/include/hw_sha.h > @@ -8,6 +8,32 @@ > #define __HW_SHA_H > #include <hash.h> > > +/** > + * Computes hash value of input pbuf using h/w acceleration > + * > + * @param in_addr A pointer to the input buffer > + * @param bufleni Byte length of input buffer > + * @param out_addr A pointer to the output buffer. When complete > + * 64 bytes are copied to pout[0]...pout[63]. Thus, a user > + * should allocate at least 64 bytes at pOut in advance. > + * @param chunk_size chunk size for sha512 > + */ > +void hw_sha512(const uchar *in_addr, uint buflen, uchar *out_addr, > + uint chunk_size); > + > +/** > + * Computes hash value of input pbuf using h/w acceleration > + * > + * @param in_addr A pointer to the input buffer > + * @param bufleni Byte length of input buffer > + * @param out_addr A pointer to the output buffer. When complete > + * 48 bytes are copied to pout[0]...pout[47]. Thus, a user > + * should allocate at least 48 bytes at pOut in advance. > + * @param chunk_size chunk size for sha384 > + */ > +void hw_sha384(const uchar *in_addr, uint buflen, uchar *out_addr, > + uint chunk_size); > + > /** > * Computes hash value of input pbuf using h/w acceleration > * > diff --git a/lib/Kconfig b/lib/Kconfig > index b35a71ac368b..0d753eedeced 100644 > --- a/lib/Kconfig > +++ b/lib/Kconfig > @@ -389,19 +389,18 @@ config SHA384 > config SHA_HW_ACCEL > bool "Enable hashing using hardware" > help > - This option enables hardware acceleration > - for SHA1/SHA256 hashing. > - This affects the 'hash' command and also the > - hash_lookup_algo() function. > + This option enables hardware acceleration for SHA hashing. > + This affects the 'hash' command and also the hash_lookup_algo() > + function. > > config SHA_PROG_HW_ACCEL > bool "Enable Progressive hashing support using hardware" > depends on SHA_HW_ACCEL > help > - This option enables hardware-acceleration for > - SHA1/SHA256 progressive hashing. > - Data can be streamed in a block at a time and the hashing > - is performed in hardware. > + This option enables hardware-acceleration for SHA progressive > + hashing. > + Data can be streamed in a block at a time and the hashing is > + performed in hardware. > > config MD5 > bool "Support MD5 algorithm" >
Hi Heinrich, On Wed, 12 May 2021 at 10:01, Heinrich Schuchardt <xypron.glpk@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@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. Regards, Simon
On 12.05.21 18:05, Simon Glass wrote: > Hi Heinrich, > > On Wed, 12 May 2021 at 10:01, Heinrich Schuchardt <xypron.glpk@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@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
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@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@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.
Hi Heinrich, On Wed, 12 May 2021 at 10:25, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > > On 12.05.21 18:05, Simon Glass wrote: > > Hi Heinrich, > > > > On Wed, 12 May 2021 at 10:01, Heinrich Schuchardt <xypron.glpk@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@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. Indeed, but we can still have an option for enabling the progressive interface. My point is that the implementation (software or hardware) should use a driver. Regards, Simon > Heinrich
Am 12. Mai 2021 19:32:42 MESZ schrieb Simon Glass <sjg@chromium.org>: >Hi Heinrich, > >On Wed, 12 May 2021 at 10:25, Heinrich Schuchardt <xypron.glpk@gmx.de> >wrote: >> >> On 12.05.21 18:05, Simon Glass wrote: >> > Hi Heinrich, >> > >> > On Wed, 12 May 2021 at 10:01, Heinrich Schuchardt ><xypron.glpk@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@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. > >Indeed, but we can still have an option for enabling the progressive >interface. My point is that the implementation (software or hardware) >should use a driver. > >Regards, >Simon Anyway that should not stop us from reverting a problematic patch. We can work on refactoring afterwards. Best regards Heinrich
Hi Heinrich, On Wed, 12 May 2021 at 15:27, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > > Am 12. Mai 2021 19:32:42 MESZ schrieb Simon Glass <sjg@chromium.org>: > >Hi Heinrich, > > > >On Wed, 12 May 2021 at 10:25, Heinrich Schuchardt <xypron.glpk@gmx.de> > >wrote: > >> > >> On 12.05.21 18:05, Simon Glass wrote: > >> > Hi Heinrich, > >> > > >> > On Wed, 12 May 2021 at 10:01, Heinrich Schuchardt > ><xypron.glpk@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@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. > > > >Indeed, but we can still have an option for enabling the progressive > >interface. My point is that the implementation (software or hardware) > >should use a driver. > > > >Regards, > >Simon > > Anyway that should not stop us from reverting a problematic patch. We can work on refactoring afterwards. Well the patch was applied because tests passed. We should be careful about reverting a patch due to problems it causes in the future. Regards, Simon
On 5/13/21 4:36 PM, Simon Glass wrote: > Hi Heinrich, > > On Wed, 12 May 2021 at 15:27, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: >> >> Am 12. Mai 2021 19:32:42 MESZ schrieb Simon Glass <sjg@chromium.org>: >>> Hi Heinrich, >>> >>> On Wed, 12 May 2021 at 10:25, Heinrich Schuchardt <xypron.glpk@gmx.de> >>> wrote: >>>> >>>> On 12.05.21 18:05, Simon Glass wrote: >>>>> Hi Heinrich, >>>>> >>>>> On Wed, 12 May 2021 at 10:01, Heinrich Schuchardt >>> <xypron.glpk@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@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. >>> >>> Indeed, but we can still have an option for enabling the progressive >>> interface. My point is that the implementation (software or hardware) >>> should use a driver. >>> >>> Regards, >>> Simon >> >> Anyway that should not stop us from reverting a problematic patch. We can work on refactoring afterwards. > > Well the patch was applied because tests passed. We should be careful > about reverting a patch due to problems it causes in the future. The code compiled because SHA384 and SHA512 were not used together with CONFIG_SHA_HW_ACCEL=y. But we need these functions to implement the TCG2 protocol on boards with TPMv2. Gitlab CI had no issues with reverting the patch. Best regards Heinrich
Hi Heinrich, On Thu, 13 May 2021 at 09:38, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > > On 5/13/21 4:36 PM, Simon Glass wrote: > > Hi Heinrich, > > > > On Wed, 12 May 2021 at 15:27, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote: > >> > >> Am 12. Mai 2021 19:32:42 MESZ schrieb Simon Glass <sjg@chromium.org>: > >>> Hi Heinrich, > >>> > >>> On Wed, 12 May 2021 at 10:25, Heinrich Schuchardt <xypron.glpk@gmx.de> > >>> wrote: > >>>> > >>>> On 12.05.21 18:05, Simon Glass wrote: > >>>>> Hi Heinrich, > >>>>> > >>>>> On Wed, 12 May 2021 at 10:01, Heinrich Schuchardt > >>> <xypron.glpk@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@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. > >>> > >>> Indeed, but we can still have an option for enabling the progressive > >>> interface. My point is that the implementation (software or hardware) > >>> should use a driver. > >>> > >>> Regards, > >>> Simon > >> > >> Anyway that should not stop us from reverting a problematic patch. We can work on refactoring afterwards. > > > > Well the patch was applied because tests passed. We should be careful > > about reverting a patch due to problems it causes in the future. > > The code compiled because SHA384 and SHA512 were not used together with > CONFIG_SHA_HW_ACCEL=y. But we need these functions to implement the TCG2 > protocol on boards with TPMv2. Let's fix it then. The patch makes all the hashing algorithms work the same, which seems right to me. If we come to converting this to a linker list, which we should, then it will be easier with this patch applied than not. > > Gitlab CI had no issues with reverting the patch. OK. It's up to Tom what he wants to do. But how about sending a patch to do what you want, instead? Regards, SImon
diff --git a/common/hash.c b/common/hash.c index fc64002f736a..10dff7ddb0e7 100644 --- a/common/hash.c +++ b/common/hash.c @@ -97,7 +97,7 @@ static int hash_finish_sha256(struct hash_algo *algo, void *ctx, void } #endif -#if defined(CONFIG_SHA384) +#if defined(CONFIG_SHA384) && !defined(CONFIG_SHA_PROG_HW_ACCEL) static int hash_init_sha384(struct hash_algo *algo, void **ctxp) { sha512_context *ctx = malloc(sizeof(sha512_context)); @@ -125,7 +125,7 @@ static int hash_finish_sha384(struct hash_algo *algo, void *ctx, void } #endif -#if defined(CONFIG_SHA512) +#if defined(CONFIG_SHA512) && !defined(CONFIG_SHA_PROG_HW_ACCEL) static int hash_init_sha512(struct hash_algo *algo, void **ctxp) { sha512_context *ctx = malloc(sizeof(sha512_context)); @@ -260,10 +260,20 @@ static struct hash_algo hash_algo[] = { .name = "sha384", .digest_size = SHA384_SUM_LEN, .chunk_size = CHUNKSZ_SHA384, +#ifdef CONFIG_SHA_HW_ACCEL + .hash_func_ws = hw_sha384, +#else .hash_func_ws = sha384_csum_wd, +#endif +#ifdef CONFIG_SHA_PROG_HW_ACCEL + .hash_init = hw_sha_init, + .hash_update = hw_sha_update, + .hash_finish = hw_sha_finish, +#else .hash_init = hash_init_sha384, .hash_update = hash_update_sha384, .hash_finish = hash_finish_sha384, +#endif }, #endif #ifdef CONFIG_SHA512 @@ -271,10 +281,20 @@ static struct hash_algo hash_algo[] = { .name = "sha512", .digest_size = SHA512_SUM_LEN, .chunk_size = CHUNKSZ_SHA512, +#ifdef CONFIG_SHA_HW_ACCEL + .hash_func_ws = hw_sha512, +#else .hash_func_ws = sha512_csum_wd, +#endif +#ifdef CONFIG_SHA_PROG_HW_ACCEL + .hash_init = hw_sha_init, + .hash_update = hw_sha_update, + .hash_finish = hw_sha_finish, +#else .hash_init = hash_init_sha512, .hash_update = hash_update_sha512, .hash_finish = hash_finish_sha512, +#endif }, #endif { diff --git a/include/hw_sha.h b/include/hw_sha.h index 15b1a1c79836..d4f3471c4308 100644 --- a/include/hw_sha.h +++ b/include/hw_sha.h @@ -8,6 +8,32 @@ #define __HW_SHA_H #include <hash.h> +/** + * Computes hash value of input pbuf using h/w acceleration + * + * @param in_addr A pointer to the input buffer + * @param bufleni Byte length of input buffer + * @param out_addr A pointer to the output buffer. When complete + * 64 bytes are copied to pout[0]...pout[63]. Thus, a user + * should allocate at least 64 bytes at pOut in advance. + * @param chunk_size chunk size for sha512 + */ +void hw_sha512(const uchar *in_addr, uint buflen, uchar *out_addr, + uint chunk_size); + +/** + * Computes hash value of input pbuf using h/w acceleration + * + * @param in_addr A pointer to the input buffer + * @param bufleni Byte length of input buffer + * @param out_addr A pointer to the output buffer. When complete + * 48 bytes are copied to pout[0]...pout[47]. Thus, a user + * should allocate at least 48 bytes at pOut in advance. + * @param chunk_size chunk size for sha384 + */ +void hw_sha384(const uchar *in_addr, uint buflen, uchar *out_addr, + uint chunk_size); + /** * Computes hash value of input pbuf using h/w acceleration * diff --git a/lib/Kconfig b/lib/Kconfig index b35a71ac368b..0d753eedeced 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -389,19 +389,18 @@ config SHA384 config SHA_HW_ACCEL bool "Enable hashing using hardware" help - This option enables hardware acceleration - for SHA1/SHA256 hashing. - This affects the 'hash' command and also the - hash_lookup_algo() function. + This option enables hardware acceleration for SHA hashing. + This affects the 'hash' command and also the hash_lookup_algo() + function. config SHA_PROG_HW_ACCEL bool "Enable Progressive hashing support using hardware" depends on SHA_HW_ACCEL help - This option enables hardware-acceleration for - SHA1/SHA256 progressive hashing. - Data can be streamed in a block at a time and the hashing - is performed in hardware. + This option enables hardware-acceleration for SHA progressive + hashing. + Data can be streamed in a block at a time and the hashing is + performed in hardware. config MD5 bool "Support MD5 algorithm"
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@jms.id.au> --- common/hash.c | 24 ++++++++++++++++++++++-- include/hw_sha.h | 26 ++++++++++++++++++++++++++ lib/Kconfig | 15 +++++++-------- 3 files changed, 55 insertions(+), 10 deletions(-) -- 2.30.0