* [PATCH] Supporting AST2600 HACE engine accumulative mode @ 2021-12-22 2:22 Troy Lee 2021-12-23 12:54 ` Cédric Le Goater 0 siblings, 1 reply; 6+ messages in thread From: Troy Lee @ 2021-12-22 2:22 UTC (permalink / raw) To: qemu-devel Cc: Peter Maydell, Andrew Jeffery, leetroy, open list:ASPEED BMCs, Cédric Le Goater, Joel Stanley 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) { + /* + * 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; + + if (total_len > stream_len) + iov[i].iov_len -= total_len - stream_len; + } } } 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; }; -- 2.25.1 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] Supporting AST2600 HACE engine accumulative mode 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 0 siblings, 1 reply; 6+ messages in thread From: Cédric Le Goater @ 2021-12-23 12:54 UTC (permalink / raw) To: Troy Lee, qemu-devel Cc: Peter Maydell, Andrew Jeffery, leetroy, open list:ASPEED BMCs, Joel Stanley, klaus Heinrich Kiwi [ Adding Klaus ] 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) { > + /* > + * 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; > + > + if (total_len > stream_len) > + iov[i].iov_len -= total_len - stream_len; > + } > } > } 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; > }; > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Supporting AST2600 HACE engine accumulative mode 2021-12-23 12:54 ` Cédric Le Goater @ 2021-12-23 15:57 ` Klaus Heinrich Kiwi 2021-12-28 3:34 ` Troy Lee 0 siblings, 1 reply; 6+ messages in thread From: Klaus Heinrich Kiwi @ 2021-12-23 15:57 UTC (permalink / raw) To: Cédric Le Goater Cc: Peter Maydell, Andrew Jeffery, Troy Lee, qemu-devel, leetroy, open list:ASPEED BMCs, Joel Stanley 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? > > + /* > > + * 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. > > + 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. The rest of it looks fine apparently. Are you planning on adding to the testcases are well? 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; > > }; > > > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Supporting AST2600 HACE engine accumulative mode 2021-12-23 15:57 ` Klaus Heinrich Kiwi @ 2021-12-28 3:34 ` Troy Lee 2022-01-06 15:27 ` Peter Maydell 0 siblings, 1 reply; 6+ messages in thread From: Troy Lee @ 2021-12-28 3:34 UTC (permalink / raw) To: Klaus Heinrich Kiwi Cc: Peter Maydell, Andrew Jeffery, Troy Lee, qemu-devel, open list:ASPEED BMCs, Joel Stanley, Cédric Le Goater 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; > > > }; > > > > > > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Supporting AST2600 HACE engine accumulative mode 2021-12-28 3:34 ` Troy Lee @ 2022-01-06 15:27 ` Peter Maydell 2022-01-07 1:46 ` Troy Lee 0 siblings, 1 reply; 6+ messages in thread From: Peter Maydell @ 2022-01-06 15:27 UTC (permalink / raw) To: Troy Lee Cc: Andrew Jeffery, Troy Lee, qemu-devel, open list:ASPEED BMCs, Joel Stanley, Klaus Heinrich Kiwi, Cédric Le Goater 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] Supporting AST2600 HACE engine accumulative mode 2022-01-06 15:27 ` Peter Maydell @ 2022-01-07 1:46 ` Troy Lee 0 siblings, 0 replies; 6+ messages in thread From: Troy Lee @ 2022-01-07 1:46 UTC (permalink / raw) To: Peter Maydell Cc: Andrew Jeffery, Troy Lee, qemu-devel, open list:ASPEED BMCs, Joel Stanley, Klaus Heinrich Kiwi, Cédric Le Goater 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-01-07 1:53 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 2022-01-06 15:27 ` Peter Maydell 2022-01-07 1:46 ` Troy Lee
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.