[qemu] Earlgrey 1.0.0 `rom_ext` support

[moidx]

Description

Enable the following features:

• Support booting into Silicon Owner code
• DICE attestation
• Boot services - including ownership transfer via UART

Depends on:

• [qemu] Earlgrey 1.0.0 keymgr implementation #27894
• [qemu] Earlgrey 1.0.0 hmac implementation #27910
• [qemu] Earlgrey 1.0.0 kmac updates #27928

[AlexJones0]

I was looking into this and one issue that cropped up (outside of the keymgr etc. implementation) was that the ROM_EXT detects a RESCUE 1.0 (UART Break condition) by reading the oversampled VAL register of the UART, which is unimplemented on QEMU due to the way it implements UART as a CharDev. This meant the register always read 0, which looks like a break condition to the ROM_EXT. I made PR lowRISC/qemu#169 to work around this issue.

[AlexJones0]

Another problem that has cropped up (outside of implementing the different QEMU IPs): QEMU's flashgen.py script, which populates QEMU RAW image files with binaries, only currently accepts binaries & ELFs for exec (i.e. ROM_EXT) and boot (the Owner test code). It complains for ROM_EXT because the provided ROM_EXT elf does not match the binary, which needs to be further debugged.

edit: This was root caused to the ELF not matching the signed binary because of the manifest headers allocated at the end of the .text section (e.g. SPX SIGNATURE) which are reported in the manifest length field but not present in the loadable segments of the ELF corresponding to the unsigned binary. It was resolved to work-around this in this case by removing the unsafe ELF sanity checks, as they don't make much sense here.

[AlexJones0]

Looking more into the aforementioned issue (also see lowRISC/qemu#193).

Currently, QEMU's flashgen.py script only supports the notion of some "exec" binary (placed at offset 0x0) and an optional "boot" binary (placed at offset 0x10000) to support ROM_EXT execution. There is no support for loading many binaries of arbitrary sizes at specified locations of flash. This may not be compatible with desired flows which wish to use multiple boot stages without bootstrapping, or wish to use custom locations in flash to store code.

Furthermore, the current QEMU flash image format hardcodes ELF support for only these two files - meaning that even if we change the QEMU flash image generation script (flashgen.py), we cannot support ELFs for other binaries (which are used to provide debug symbols within QEMU). This requires changes to the actual flash image format (and thus flash controller) and a bump to the QEMU flash image version itself. Likely a sizable change will be required, as we will need to support a format that allows removing ELFs from the flash image when the corresponding binary is overwritten - it is not clear how to trivially support this.

Furthermore, the assemble = "{rom_ext}@0x0 {firmware}@0x10000" etc. param format used by several e2e tests is only supported by FPGA exec envs for now, as QEMU currently does not go through opentitantool image assemble. If we wanted to be able to go through opentitantool image assembly, we would again have to change flashgen.py to be able to support arbitrary images. This case would also not be able to easily support debug symbols in QEMU as we would need to support loading the ELFs of the assembled image.

For now I'll continue with this limitation, but it would be useful to know if we need to be able to support these flows, as changing the flash and rewriting flashgen.py will require some efforts.

[AlexJones0]

#28376 has now been merged to earlgrey_1.0.0, which adds initial support for the sim_qemu_sival_rom_ext environment, i.e. booting into ROM_EXT code. It would maybe also be useful to have follow up PRs which add the sim_qemu_sival and sim_qemu_rom_ext environments to aid in debugging.

As aforementioned, this currently does not interact with opentitantool image assemble and assumes that the firmware is placed in bank 0 at standard offsets (ROM_EXT at 0x0 and owner bl0 code at 0x10000). An ideal solution in the future is to change QEMU's flashgen.py to optionally take an image for both banks so that we can directly use the output of opentitan_image_assemble. Further changes would be needed to QEMU's flash format to support convenience debug symbols from ELFs, but this is not available for now.

You can see a QEMU regression run with around ~220 new passing sim_qemu_sival_rom_ext test targets here. I've marked the first part of this issue as completed - this should support the DICE attestation flow also with the keymgr changes, but I need to check if there are any additional tests that can be run before marking this as completed.

[AlexJones0]

Also see lowRISC/qemu#203 in lowRISC/qemu which adds regression CI runs for QEMU ROM_EXT tests.

[AlexJones0]

The majority of DICE attestation and ROM_EXT end-to-end boot service tests are now passing (including ownership transfer via UART), but I am holding off on PRing these changes until we have opentitantool QEMU SPI Bootstrapping support to be able to support the last few passing test targets. When that is unblocked I will finish and open these PRs, which should complete this issue.

[AlexJones0]

Relevant support for UART RX Break and sending break for rescue in QEMU was merged in #28449. This PR also added QEMU execution environments to all boot service (non-ownership) tests, which are now all passing, except for boot_service_wakeup which is not expected to pass because of lacking low power entry/exit pwrmgr emulation in QEMU.

Opentitantool SPI bootstrapping has been quite difficult to properly support, so we've spent some time looking into this. While we're still working out the best way to support that, I've opened PRs for relevant tests for this issue and marked the ones that depend on bootstrapping as drafts. After fixes to the flash and lc_ctrl in QEMU and with appropriate bootstrapping support these tests should all pass on QEMU, though with some ROM timing assumptions that mean they should ideally be run sequentially on a reasonably fast host.

• [bazel,qemu] Add QEMU support for ROM_EXT E2E verified boot tests #28503
• [bazel,qemu] Add QEMU support for ROM E2E sigverify tests #28504
• [bazel,qemu] Add QEMU support for ROM_EXT E2E attestation & DICE chain tests #28505
• [bazel,qemu] Add QEMU support for ROM_EXT E2E ownership tests #28506

When these PRs are merged, it means that all attestation / DICE chain / boot service / ownership transfer test is supported and passing in QEMU (except for the aforementioned boot_service_wakeup test).

[AlexJones0]

All the above PRs are merged into earlgrey_1.0.0, which means that all of the following is working in QEMU:

• Booting into silicon owner code via the sim_qemu_rom_ext and sim_qemu_sival_rom_ext execution environments.
• DICE attestation, with every attestation and dice_chain ROM_EXT E2E test passing in QEMU.
• Boot services, with every boot_svc ROM_EXT E2E test passing in QEMU with the exception of the boot_svc_wakeup_test which is not expected to be supported as low power is not modeled in QEMU.
• Ownership transfer boot services via UART, with every ownership ROM_EXT E2E test passing in QEMU.

As such, I am marking all the items on this issue as completed.