W6: Bring the QEMU AArch64 suite to parity with the M33MU negatives

[aidangarske]

Context

Plan item W6 of the AArch64 level 3 plan (tracking #46). The QEMU AArch64 suite should exercise the same behaviors as the M33MU negatives wherever the AArch64 ports have the feature.

Origin

The M33MU scenario list compared with the QEMU AArch64 list; the AArch64 level 3 plan

What is needed

• Twins: restartneg1 to restartneg3 (a restarted partition's band returns to its link-time image), hsmpinneg, sealneg, sealbootneg, sealhaltneg, sealpivotneg, remeasureneg, authneg, devattestqcbor, bothiso, bothpsa
• Document as not applicable, with the reason, in docs/Testing.md:
  • gtzcneg and revneg: STM32H5 only
  • vnet and vnetneg: the H5 VNET option
  • bootupdate and fwustage: until wolfBoot boots the AArch64 image
  • restart: no managed Normal-world guests, and S-EL0 restart is covered by spfaultneg and spbudgetneg
  • hsmfaultneg: the HSM tasklet is privileged S-EL1
  • rollbackneg: needs persistent NVM and a rollback hook

Blockers and dependencies

restartneg1 to restartneg3 need #43 (W1), which brings private bands that reload on restart.

Acceptance criteria

• Every listed twin passes on virt gicv2 a35, virt gicv3 a72 and versal-virt with both engines, or SKIPs with a stated reason
• The not-applicable rows are in docs/Testing.md
• Skoll review and review-security clean on each change

[aidangarske]

W6 progress, on wolfTrust-dev2 (#29):

• 8f7465c1 Run the attestation conformance suite under the reference QCBOR decoder on AArch64. The token is encoded by wolfCOSE built for a 64-bit (LP64) target, so this twin catches width-specific encoding bugs that the M33MU run cannot. It passes on virt (hsm) and versal-virt (native), with Skoll review and review-security both clean.

No AArch64 twin needed, because the behaviour does not exist on AArch64:

• sealneg, sealbootneg, sealhaltneg, sealpivotneg: Armv8-M secure stack sealing.
• authneg, remeasureneg, bothiso, bothpsa: these need managed, launch-authenticated Normal-world guests; the AArch64 ports run one unmanaged endpoint.

Remaining: the other half of this issue (hsmpinneg, restartneg1 to restartneg3, and the not-applicable rows in docs/Testing.md), which lands in the next push.

[aidangarske]

Landed on wolfTrust-dev2 (#29), this session's half of W6:

• 18d916b adds the hsmpinneg QEMU twin. Under hsm, the relay forges its wolfHSM server pointers into SPM RAM before every pin, and the positive flow still completes; an nm guard proves the probe is linked. It is skipped under native.
• ab5d92d adds the restartneg1 to restartneg3 QEMU twins. The crypto, attestation or vault partition plants state in its private band and faults once, and the restarted instance must find the band at its link-time image. With band reset disabled, all three fail on the second fault.
• 0a62e7f documents the twins and the scenarios with no AArch64 twin.

Not applicable on AArch64 (documented in Testing.md):

• restart, hsmfaultneg, authneg, remeasureneg, bothiso and bothpsa: there are no managed Normal-world guests.
• rollbackneg: the QEMU NVM is in RAM, so a version floor does not survive a reset.
• deputyneg: there is no privileged flash deputy.
• sealneg, sealbootneg, sealhaltneg and sealpivotneg: these test Armv8-M stack seals.

Remaining in W6: none. The other half, including devattestqcbor (8f7465c1), is already on dev2.