- The loaded image matches a key authorised by the configured trust root.
- The version satisfies the controller's freshness policy.
- Noncompliant version state can prevent the covered chip from operating.
Mechanism under review
Mandatory firmware enlightenment
The proposed security module makes current, issuer-approved firmware and software a condition of accelerator operation. Secure boot and enforced updates can close known vulnerabilities and preserve a control plane after sale. They establish version approval, not code correctness, sound policy or issuer legitimacy; the same mechanism that improves patch adoption also makes update infrastructure part of the chip's availability boundary.
Read primary source ↗Adversary realism4/5
Context-sensitive
The source distinguishes minimally, covertly and openly adversarial custody and is candid about software and physical compromise, but gives less treatment to a compromised or mistaken update authority.Trusted dependencies5/5
Control-plane dense
Keys, secure boot, firmware correctness, physical integrity and an available update-governance process all sit on the critical path.Policy reach5/5
Fleet-wide
The architecture can update policy after sale and deny operation across all equipped high-performance accelerators.01Mechanism under review
Keep governance and security controls patchable, current and enforceable even when the hardware operator would prefer not to update.
- 01
Anchor manufacturer or controller keys in a dedicated hardened security module.
- 02
Verify firmware and software signatures and version state during secure boot and attestation.
- 03
Deliver authenticated updates when vulnerabilities or policy requirements change.
- 04
Block operation, or allow an associated licence to expire, when the approved current state is not present.
Technical output
An enforcement decision that the covered chip is running an issuer-approved, sufficiently current software stack.
02Claim boundary
What the primitive says—and what it does not.
- Whether signed and current code is free of exploitable bugs or implements the intended policy correctly.
- Whether the update authority is legitimate, uncompromised and acting within an accepted mandate.
- Whether update distribution and recovery remain available during outages, mistakes or political disputes.
- Whether physical or supply-chain compromise has bypassed the boot and attestation path.
03Threat model in scope
Protected asset
The secure-boot chain, update and signing keys, freshness state, security-module code and operation gate.
Adversary
An operator ranging from a regulation-sensitive company to a covert commercial attacker or openly adversarial state-linked custodian.
Enforcement boundary
The gate governs the equipped accelerator's boot and continued licensed use; correctness of approved code and conduct of the approval authority sit above that boundary.
Capabilities considered
- Exploit legitimate firmware, parsers, drivers or licence-validation logic without physical access.
- Attempt rollback, fault injection, key extraction or compromise of remote attestation.
- Physically alter the package or security module under unsupervised custody.
- Target controller systems, verifiers, manufacturing or the signing ecosystem.
Limits and exclusions
- The report leaves detailed implementation in specific use cases and their broader impacts to future work.
- Manufacturing supply-chain compromise is acknowledged but placed outside the report's scope.
- Malicious or mistaken policy updates and update-service availability are not developed as adversary cases.
04Trust register
The assurance dependency chain.
DomainRequirementFailure consequenceSource treatment
Root and signing keys
Approval keys and update-signing processes must remain confidential, correctly scoped and recoverable.
A stolen or misused key turns malicious code into an approved update across the fleet.
discussedSecure boot and freshness
The module must measure the complete boot chain and reject rollback or stale state.
An operator boots a signed but vulnerable version or bypasses the gate.
centralFirmware correctness
The approved image must actually be secure and enforce its stated policy.
Attestation faithfully reports the current version of exploitable code.
centralPhysical integrity
The security module and its connection to chip operation must withstand the relevant custody threat.
Tampering disables enforcement while leaving useful compute intact.
centralUpdate governance and availability
Approval, revocation, distribution and emergency recovery must remain legitimate and available.
An outage or erroneous policy update becomes fleet-wide denial of service.
not located05Caveats on the record
Limitations the source already recognizes.
- The report is a platform sketch and leaves rigorous implementation and broader impacts of specific uses for future work (p. 9).
- Secure boot can prove that firmware is legitimate without proving it is vulnerability-free; substantial code remains notoriously difficult to secure (Appendix B, p. 28).
- Formal verification reduces bugs but does not make the full compiler, hardware and software stack unhackable (Appendix B, p. 28).
- Current hardware may contain unpatchable weaknesses and is not fully trustworthy in covertly adversarial settings without monitoring and legal deterrence (p. 22).
- Robust security modules and physical protections require years of development and testing, especially for openly adversarial custody (pp. 21–22).
06Consortium assessment
Where the assurance moves
The mechanism turns an authentic version identifier into permission to operate. That is strong update enforcement, but its governance value depends on the much larger proposition that the issuer-approved image, policy and issuer are all correct at the same time.
Load-bearing sequence
- The immutable trust root authenticates the intended authority.
- The measured boot chain covers every path that can control the chip.
- The approved update is secure and policy-correct.
- Distribution and recovery remain available before enforcement blocks operation.
Institutional translationThe patch Tuesday change-control board is given a direct electrical vote on whether the accelerator may wake up.
07Tests that would change our mind
A finding should be falsifiable.
Attempt rollback, partial update, power interruption and alternate boot paths across every firmware-bearing component.
Compromise a signing tier in a red-team exercise and measure blast radius, revocation speed and recovery without a second trusted path.
Model update-service and network outages, including safe grace periods and air-gapped deployment.
Ship a correctly signed but deliberately vulnerable policy image and verify that attestation does not overstate what approval proves.
Fault-inject or physically bypass the operation gate while preserving accelerator functionality.
08Record provenance
Evidence register (4)
Secure, Governable Chips, 'What Would Effective On-Chip Governance Look Like?', p. 9 (PDF p. 12)
Security-module architecture, forced freshness, blocking behaviour and adaptive policy updates.
Secure, Governable Chips, 'Timelines for Technical Development of Security Features', pp. 21–22 (PDF pp. 24–25)
Development stages, current-hardware limits and requirements across threat contexts.
Secure, Governable Chips, Appendix B, pp. 28–30 (PDF pp. 31–33)
Firmware fallibility, enforced-update rationale, physical protections, supporting ecosystem and supply-chain exclusion.
Secure, Governable Chips, 'Viability in Adversarial Contexts', pp. 19–20 (PDF pp. 22–23)
Three adversarial contexts, tamper evidence, tamper proofing and cost-imposition framing.