Re: [PATCH] Supporting AST2600 HACE engine accumulative mode

[Troy Lee <leetroy@gmail.com>]

On Thu, Jan 6, 2022 at 11:27 PM Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Tue, 28 Dec 2021 at 03:34, Troy Lee <leetroy@gmail.com> wrote:
> >
> > Hi Klaus,
> >
> > On Thu, Dec 23, 2021 at 11:57 PM Klaus Heinrich Kiwi
> > <klaus@klauskiwi.com> wrote:
> > >
> > > Em qui., 23 de dez. de 2021 às 09:54, Cédric Le Goater <clg@kaod.org> escreveu:
> > > >
> > > > [ Adding Klaus ]
> > >
> > > Thanks Cedric. It's been a while since I've looked at this but I'll do my best..
> > >
> > > >
> > > > On 12/22/21 03:22, Troy Lee wrote:
>
>
> > > > > +                /*
> > > > > +                 * Read the message length in bit from last 64/128 bits
> > > > > +                 * and tear the padding bits from iov
> > > > > +                 */
> > > > > +                uint64_t stream_len;
> > > > > +
> > > > > +                memcpy(&stream_len, iov[i].iov_base + iov[i].iov_len - 8, 8);
> > > > > +                stream_len = __bswap_64(stream_len) / 8;
> > > > > +
> > >
> > > I no longer have access to the aspeed workbook I guess, but what is
> > > the actual specification here? is the message length 64 or 128 bits?
> > > and bswap seems arch-dependent - you probably want to be explicit if
> > > this is big or little-endian and use the appropriate conversion
> > > function.
> > The message length is described in RFC4634:
> > - SHA224 or SHA256 should be 64-bit.
> > - SHA384 or SHA512 should be 128-bit.
> > And it should be in big-endian.
>
> You can read a 64-bit BE value with
>  uint64_t val = ldq_be_p(iov[i].iov_base + iov[i].iov_len - 8);
> or similar. (We don't have a similar function for 128 bits because
> there's no fully-portable native C data type for that.)
>
> -- PMM

Thanks for the suggestion!
Troy Lee