2417695_en-US

[#1]

HSE-B SHA-512 / Ed25519 verify timings on S32K344 – are these figures expected?

Hi Lukas (@lukaszadrapa)

Referring to Solved: Clarification on HSE support for ED25519 and SHA-512 (S32K394) - NXP Community, 

Thanks for the clarification on SHA-384/512 being emulated in software on HSE-B. We ran into exactly this on an S32K344 bootloader and would like to know whether our measurements are representative.

Setup

• S32K344, CORE_CLK 160 MHz, HSE_CLK 80 MHz (CORE_CLK/2, as configured in Clock_Ip)
• HSE host interface/headers from package 0.2.55.0, HSE FW 0.2.40.0 installed (we are on SBAF 0.10.0, so we cannot move to 0.2.55.0 yet)
• Message: application image in PFLASH, 2,965,376 bytes (0x00500000–0x007D3F7F), passed by address (no RAM copy)
• One-pass requests, MU0 channel 1, synchronous polling; descriptors and output buffers in non-cacheable SRAM
• Timing taken on the M7 with the PIT (40 MHz) around HSE_Send()

Measurement code

c

static uint8_t  digest[64]  __attribute__((aligned(32), section(".mcal_bss_no_cacheable")));
static uint32_t digest_len  __attribute__((aligned(32), section(".mcal_bss_no_cacheable")));

static uint32_t hash_time_ms(hseHashAlgo_t algo, const uint8_t *msg, uint32_t len, uint32_t *rsp)
{
    hseSrvDescriptor_t *desc = &gHseSrvDesc[0][1];
    hseHashSrv_t *hsh = &desc->hseSrv.hashReq;

    digest_len = sizeof(digest);
    memset(desc, 0, sizeof(*desc));
    desc->srvId      = HSE_SRV_ID_HASH;
    hsh->accessMode  = HSE_ACCESS_MODE_ONE_PASS;
    hsh->hashAlgo    = algo;
    hsh->sgtOption   = HSE_SGT_OPTION_NONE;
    hsh->inputLength = len;
    hsh->pInput      = HSE_PTR_TO_HOST_ADDR(msg);        /* PFLASH */
    hsh->pHashLength = HSE_PTR_TO_HOST_ADDR(&digest_len);
    hsh->pHash       = HSE_PTR_TO_HOST_ADDR(digest);

    uint32_t t0 = ~IP_PIT_0->TIMER[1].CVAL;              /* 40 MHz up-counter */
    *rsp = HSE_Send(0, 1, gSyncTxOption, desc);
    return ((~IP_PIT_0->TIMER[1].CVAL) - t0) / 40000u;   /* ms */
}

t256 = hash_time_ms(HSE_HASH_ALGO_SHA2_256, (const uint8_t *)0x00500000, 0x2D3F80, &rsp256);
t512 = hash_time_ms(HSE_HASH_ALGO_SHA2_512, (const uint8_t *)0x00500000, 0x2D3F80, &rsp512);

The EdDSA verify is a one-pass HSE_SRV_ID_SIGN request with HSE_SIGN_EDDSA, bHashEddsa = FALSE (pure Ed25519), bInputIsHashed = FALSE, and the same message pointer and length. The key is an ED25519 public key imported into a RAM slot.

Results (all requests returned HSE_SRV_RSP_OK)

Operation, 2,965,376 bytes Engine Time

SHA-256	HSE-B (HW)	38 ms
SHA-512	HSE-B (SW emulation)	26,010 ms
Ed25519 verify (pure)	HSE-B	26,019 ms
Ed25519 verify (pure)	Cortex-M7 software, 160 MHz, -O2, D-cache on	952 ms

So the HSE verify is about 27x slower than the M7 software implementation. Almost all of the time is the SHA-512 over the message: verify minus SHA-512 is about 9 ms.

Questions

1. Is ~114 KB/s (≈700 HSE cycles/byte at 80 MHz) the expected SHA-512 throughput on HSE-B, or does it point to a configuration issue on our side (for example the flash read path from HSE)?
2. Could FW 0.2.40.0 behave differently from 0.2.55.0 for SHA-512/EdDSA performance? Is running 0.2.55.0 interface headers against FW 0.2.40.0 supported for the HASH and SIGN services?
3. For fast image authentication on HSE-B, is the recommended approach ECDSA P-256 with SHA-256, or is there a supported way to use Ed25519 with a hardware-accelerated digest?

Note on our silicon
Our parts are early silicon with SBAF 0.10.0, which is why we could not install HSE FW 0.2.55.0 and are limited to 0.2.40.0. We would like to know whether this older SBAF/FW combination could make the SHA-512 software emulation slower than on current parts. That said, our understanding is that even with a newer FW, a SHA-512 emulated on the HSE core at 80 MHz cannot get close to the same computation on the Cortex-M7 at 160 MHz (952 ms for the complete Ed25519 verify, against about 26 s on HSE). Unless you see something wrong in our setup, we plan to keep Ed25519 verification on the M7 and use HSE only where it is hardware accelerated (AES, SHA-256). Please correct us if this conclusion is wrong.

Thanks in advance,

Fabio

Re: HSE-B SHA-512 / Ed25519 verify timings on S32K344 – are these figures expected?

Hi @FabioG 

The measured results look reasonable. The long Ed25519 verification time is caused almost entirely by SHA-512 processing of the ~2.97 MB message.

I have some benchmark data which corresponds to your results. Hash operation on 24KB of data should take about 140ms when HSE_CLK = 120MHz. Scaling this to 80MHz and ~2.97 MB message size, it gives approximately 26.5 s, which is very close to your measured value.

There’s no performance difference between mentioned HSE FW versions. There are just some minor updates and several bug fixes. It’s completely caused by SW emulation.

If image authentication performance is important, ECDSA P-256 with SHA-256 would be a much faster option on HSE-B. SHA-256 is hardware accelerated. Based on benchmark data I have, ECDSA P-256/SHA-256 verification of the same ~2.97 MB image at 80 MHz can be estimated at approximately 0.3 s, compared with ~26 s for Ed25519. Please notice that this is just simple scaling, I haven’t confirmed this on HW.

Regards,

Lukas