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. SP unit tests are unaffected (none exercise the "no bits set" paths).

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 for the qemu-sbsa harness is being prepared as a super-PR that bundles 4 related fixes (TPM device wiring, CI gate, uart-logger retarget, TPM test alignment) — it bumps the submodule to this commit.

Verified locally inside the qemu-sbsa devcontainer: with this SP fix + the qemu-sbsa side fixes stacked, make e2e-test QEMU_TIMEOUT=900 reports RESULT: ALL TESTS PASSED (27/27).

[Copilot]

Pull request overview

This PR aligns the TPM Service CRB-over-FF-A Start status codes with ARM DEN0138 semantics by returning INV_CRB_CTRL_DATA (instead of DENIED) when the host issues Start with empty/invalid CRB control data.

Changes:

• In handle_command(), return InvCrbCtrlData when both crb_control_request and crb_control_start are zero (no operation requested).
• In handle_locality_request(), return InvCrbCtrlData when neither RELINQUISH nor REQUEST_ACCESS is set in locality_control.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Raymond-MS]

Good catch! Just some minor comments.