STM32H7 RNG driver should be more robust

[mkeeter]

On a recent manufacturing build, we tried to unlock a tech port and encountered

Dec 12 20:19:09.462 INFO creating SP handle on interface port5, component: faux-mgs
Dec 12 20:19:09.463 INFO initial discovery complete, addr: [fe80::aa40:25ff:fe05:3b00%4]:11111, interface: port5, component: faux-mgs
Error: Error response from SP: monorail: could not create challenge

This indicates that we were unable to read a nonce from the RNG:

fn get_ecdsa_challenge() -> Result<EcdsaSha2Nistp256Challenge, SpError> {
    // Get a nonce from our RNG driver
    let rng = drv_rng_api::Rng::from(RNG.get_task_id());
    let mut nonce = [0u8; 32];
    rng.fill(&mut nonce).map_err(|e| {
        ringbuf_entry!(Trace::RngFillFailed(e));
        SpError::Monorail(GwMonorailError::GetChallengeFailed)
    })?;

Looking at the ringbuf, the specific error is RngError::SeedError.

Doing a soft reset of the SP caused the error to resolve itself. However, that required connecting through the second tech port; if both tech ports were down, this could be a problem!

Looking at the stm32h7-rng driver, this error is returned this if RNG_SR.SEIS is set. However, we make no attempts at recovering.

The datasheet specifies a recovery procedure, which we should implement:

[cbiffle]

Concretely, what I would propose is:

• Implement the recovery logic described in the manual.
• Do that if we go to get data and SEIS is set.
• Continue filling out the client buffer as long as the RNG makes forward progress between SEIS events. So if you can get at least 64 bits or whatever, great, keep doing the recovery.
• Return a SeedError only if we get two successive SEIS events with no forward progress.

In the case of a client who sends e.g. a 128-byte buffer to fill out, this ensures that we'll fill the whole buffer if possible, even if we're seeing errors every 64 bytes or whatever. The alternative would be to extend the error type to indicate how many bytes were filled in before the RNG failed, but then clients would have to call back; better to do that in the driver, IMO.

[cbiffle]

Note that once ereport facilities are available, the SEIS event should probably produce an ereport.

[cbiffle]

We believe this to have been fixed by #1945 .