Re: [PATCH] Supporting AST2600 HACE engine accumulative mode

[Peter Maydell]

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