Return INV_CRB_CTRL_DATA for empty CRB control data on Start

[dymk]

Per ARM DEN0138 TPM Service CRB Interface Over FF-A, the Start function's response codes have these semantics:

CRB_FFA_DENIED: the TPM has previously DISABLED locality requests and command processing at the given locality
CRB_FFA_INV_CRB_CTRL_DATA: CRB control data or locality control data at the given TPM locality is not valid

The SP currently returns DENIED for two scenarios that don't fit the spec's DENIED semantics:

1. handle_command() falls through to a default Denied whenever no state-transition bit is set in the CRB control_request / control_start registers (e.g., the host issues Start(COMMAND) before writing cmdReady).
2. handle_locality_request() returns Denied when neither the RELINQUISH nor REQUEST_ACCESS bit is set in locality_control.

Both cases are "host issued Start with empty CRB control data" — which per DEN0138 is INV_CRB_CTRL_DATA, not DENIED. The semantic distinction is corroborated by two independent authoritative consumers of DEN0138:

• Linux kernel (drivers/char/tpm/tpm_crb_ffa.c): the CRB_FFA_START docstring lists the same four status codes with the same semantics.
• TianoCore EDK2 (SecurityPkg/Library/Tpm2DeviceLibFfa/Tpm2ServiceFfaRaw.c::TranslateTpmReturnStatus): maps INV_CRB_CTRL_DATA → EFI_COMPROMISED_DATA and DENIED → EFI_ACCESS_DENIED, confirming the distinction between "malformed CRB" and "access disabled."

Diff

Two minimal edits to ec-service-lib/src/services/tpm.rs:

// handle_command(): early-return InvCrbCtrlData when both
// crb_control_request and crb_control_start are zero (no operation requested).
if crb.crb_control_request == 0 && crb.crb_control_start == 0 {
    error!("CRB has no operation requested");
    return TpmStatus::InvCrbCtrlData;
}

// handle_locality_request(): change the "no bits set" branch
// from `Denied` to `InvCrbCtrlData`.

Other paths (locality mismatch, closed locality, invalid arguments, source-id check) are left as-is — their existing return codes are spec-conformant.

Surfaced from / verified by

Systematic debugging of odp-platform-qemu-sbsa's Phase 2 e2e tests (tpm_start_command_locality_mismatch, tpm_start_command_idle_no_bits, tpm_start_locality_no_crb_bits). Companion test-side change is opened against dymk/odp-platform-qemu-sbsa — it updates the test expectations to INV_CRB_CTRL_DATA for the affected cases and restructures the "closed locality" tests to target a locality that's actually closed by default (locality 2 instead of 0, since OpenDevicePartnership#76 made 0+1 default-open).

Verified locally inside the qemu-sbsa devcontainer: with this SP fix + the companion test fix + the downstream odp-platform-qemu-sbsa PRs that unblock the harness (TPM device wiring + uart-logger virt retarget), make e2e-test QEMU_TIMEOUT=900 reports RESULT: ALL TESTS PASSED (27/27).

[dymk]

Superseded — promoted to upstream as OpenDevicePartnership#79, which merged at commit 29af461. The qemu-sbsa consumer side has now also landed via OpenDevicePartnership/odp-platform-qemu-sbsa#93 (merged at b3d09316). Closing the fork-review trail.