qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Troy Lee <leetroy@gmail.com>
To: Klaus Heinrich Kiwi <klaus@klauskiwi.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Andrew Jeffery" <andrew@aj.id.au>,
	"Troy Lee" <troy_lee@aspeedtech.com>,
	qemu-devel@nongnu.org,
	"open list:ASPEED BMCs" <qemu-arm@nongnu.org>,
	"Joel Stanley" <joel@jms.id.au>,
	"Cédric Le Goater" <clg@kaod.org>
Subject: Re: [PATCH] Supporting AST2600 HACE engine accumulative mode
Date: Tue, 28 Dec 2021 11:34:05 +0800	[thread overview]
Message-ID: <CAN9Jwz3gv5V2jPvW0mp7f_XKW=d3UtE9ROMcg4wLBR7D67+KiQ@mail.gmail.com> (raw)
In-Reply-To: <CAJOFXWgEqYTAL59Z2CPzQTedYqN9pWuyiEt7jbG1ENZinNj=2w@mail.gmail.com>

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:
> > > Accumulative mode will supply a initial state and append padding bit at
> > > the end of hash stream.  However, the crypto library will padding those
> > > bit automatically, so ripped it off from iov array.
> > >
> > > Signed-off-by: Troy Lee <troy_lee@aspeedtech.com>
> > > ---
> > >   hw/misc/aspeed_hace.c         | 30 ++++++++++++++++++++++++++++--
> > >   include/hw/misc/aspeed_hace.h |  1 +
> > >   2 files changed, 29 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/hw/misc/aspeed_hace.c b/hw/misc/aspeed_hace.c
> > > index 10f00e65f4..7c1794d6d0 100644
> > > --- a/hw/misc/aspeed_hace.c
> > > +++ b/hw/misc/aspeed_hace.c
> > > @@ -27,6 +27,7 @@
> > >
> > >   #define R_HASH_SRC      (0x20 / 4)
> > >   #define R_HASH_DEST     (0x24 / 4)
> > > +#define R_HASH_KEY_BUFF (0x28 / 4)
> > >   #define R_HASH_SRC_LEN  (0x2c / 4)
> > >
> > >   #define R_HASH_CMD      (0x30 / 4)
> > > @@ -94,7 +95,10 @@ static int hash_algo_lookup(uint32_t reg)
> > >       return -1;
> > >   }
> > >
> > > -static void do_hash_operation(AspeedHACEState *s, int algo, bool sg_mode)
> > > +static void do_hash_operation(AspeedHACEState *s,
> > > +                              int algo,
> > > +                              bool sg_mode,
> > > +                              bool acc_mode)
> > >   {
> > >       struct iovec iov[ASPEED_HACE_MAX_SG];
> > >       g_autofree uint8_t *digest_buf;
> > > @@ -103,6 +107,7 @@ static void do_hash_operation(AspeedHACEState *s, int algo, bool sg_mode)
> > >
> > >       if (sg_mode) {
> > >           uint32_t len = 0;
> > > +        uint32_t total_len = 0;
> > >
> > >           for (i = 0; !(len & SG_LIST_LEN_LAST); i++) {
> > >               uint32_t addr, src;
> > > @@ -127,6 +132,21 @@ static void do_hash_operation(AspeedHACEState *s, int algo, bool sg_mode)
> > >               plen = iov[i].iov_len;
> > >               iov[i].iov_base = address_space_map(&s->dram_as, addr, &plen, false,
> > >                                                   MEMTXATTRS_UNSPECIFIED);
> > > +
> > > +            total_len += plen;
> > > +            if (acc_mode && len & SG_LIST_LEN_LAST) {
> I think we should make the precedence here explicit (with the use of
> ()) instead of implicit. Also, isn't (len * SGL_LIST_LEN_LAST) always
> true inside this for loop?
I'll change it to have explicit precedence.
No, the *len* will be assigned after goes into the loop, and the
SG_LAST_LEN_LAST will be raise at the last of scatter-gather list.

> > > +                /*
> > > +                 * 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.

The aspeed ast2600 acculumative mode is described in datasheet
ast2600v10.pdf section 25.6.4:
1. Allocationg and initiating accumulative hash digest write buffer
with initial state.
   * Since QEMU crypto/hash api doesn't provide the API to set initial
state of hash library,
     and the initial state is already setted by crypto library
(gcrypt/glib/...), so skip this step.
2. Calculating accumulative hash digest.
   (a) When receiving the last accumulative data, software need to add
padding message
       at the end of the accumulative data. Padding message described
in specific of MD5,
       SHA-1, SHA224, SHA256, SHA512, SHA512/224, SHA512/256.
       * Since the crypto library (gcrypt/glib) already pad the
padding message internally,
         This patch is to remove the padding message which fed by
guest machine driver.

I'll update the message length calcuation to 64/128 bit depending on
the hash algorithm.

> > > +                if (total_len > stream_len)
> > > +                    iov[i].iov_len -= total_len - stream_len;
> > > +            }
>
> I guess you're not using total_len except for this comparison? Feels
> like there's a better way to first compare and then assign the value,
> other than assign, compare, re-assign etc.
Got it. I'll see how it be done better.

> The rest of it looks fine apparently. Are you planning on adding to
> the testcases are well?
Got it.

Thanks for reviewing.
Troy Lee

> Thanks,
>
>  -Klaus
>
>  /*
>  <klaus@klauskiwi.com> - http://blog.klauskiwi.com
>  */
>
> > >           }
> > >       } else {
> > >           hwaddr len = s->regs[R_HASH_SRC_LEN];
> > > @@ -210,6 +230,9 @@ static void aspeed_hace_write(void *opaque, hwaddr addr, uint64_t data,
> > >       case R_HASH_DEST:
> > >           data &= ahc->dest_mask;
> > >           break;
> > > +    case R_HASH_KEY_BUFF:
> > > +        data &= ahc->key_mask;
> > > +        break;
> > >       case R_HASH_SRC_LEN:
> > >           data &= 0x0FFFFFFF;
> > >           break;
> > > @@ -234,7 +257,7 @@ static void aspeed_hace_write(void *opaque, hwaddr addr, uint64_t data,
> > >                           __func__, data & ahc->hash_mask);
> > >                   break;
> > >           }
> > > -        do_hash_operation(s, algo, data & HASH_SG_EN);
> > > +        do_hash_operation(s, algo, data & HASH_SG_EN, data & HASH_DIGEST_ACCUM);
> > >
> > >           if (data & HASH_IRQ_EN) {
> > >               qemu_irq_raise(s->irq);
> > > @@ -333,6 +356,7 @@ static void aspeed_ast2400_hace_class_init(ObjectClass *klass, void *data)
> > >
> > >       ahc->src_mask = 0x0FFFFFFF;
> > >       ahc->dest_mask = 0x0FFFFFF8;
> > > +    ahc->key_mask = 0x0FFFFFC0;
> > >       ahc->hash_mask = 0x000003ff; /* No SG or SHA512 modes */
> > >   }
> > >
> > > @@ -351,6 +375,7 @@ static void aspeed_ast2500_hace_class_init(ObjectClass *klass, void *data)
> > >
> > >       ahc->src_mask = 0x3fffffff;
> > >       ahc->dest_mask = 0x3ffffff8;
> > > +    ahc->key_mask = 0x3FFFFFC0;
> > >       ahc->hash_mask = 0x000003ff; /* No SG or SHA512 modes */
> > >   }
> > >
> > > @@ -369,6 +394,7 @@ static void aspeed_ast2600_hace_class_init(ObjectClass *klass, void *data)
> > >
> > >       ahc->src_mask = 0x7FFFFFFF;
> > >       ahc->dest_mask = 0x7FFFFFF8;
> > > +    ahc->key_mask = 0x7FFFFFF8;
> > >       ahc->hash_mask = 0x00147FFF;
> > >   }
> > >
> > > diff --git a/include/hw/misc/aspeed_hace.h b/include/hw/misc/aspeed_hace.h
> > > index 94d5ada95f..2242945eb4 100644
> > > --- a/include/hw/misc/aspeed_hace.h
> > > +++ b/include/hw/misc/aspeed_hace.h
> > > @@ -37,6 +37,7 @@ struct AspeedHACEClass {
> > >
> > >       uint32_t src_mask;
> > >       uint32_t dest_mask;
> > > +    uint32_t key_mask;
> > >       uint32_t hash_mask;
> > >   };
> > >
> > >
> >


  reply	other threads:[~2021-12-28  3:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-22  2:22 [PATCH] Supporting AST2600 HACE engine accumulative mode Troy Lee
2021-12-23 12:54 ` Cédric Le Goater
2021-12-23 15:57   ` Klaus Heinrich Kiwi
2021-12-28  3:34     ` Troy Lee [this message]
2022-01-06 15:27       ` Peter Maydell
2022-01-07  1:46         ` Troy Lee

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAN9Jwz3gv5V2jPvW0mp7f_XKW=d3UtE9ROMcg4wLBR7D67+KiQ@mail.gmail.com' \
    --to=leetroy@gmail.com \
    --cc=andrew@aj.id.au \
    --cc=clg@kaod.org \
    --cc=joel@jms.id.au \
    --cc=klaus@klauskiwi.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=troy_lee@aspeedtech.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).