THE PROBLEM
Why it was built
A launcher can hash a file and later read it again for execution. If the file changes between those operations, the system runs code different from what it approved.
Verify what actually executes
AURIX Attested Boot
An integrity boundary that reads executable bytes once, verifies those bytes, and executes that same in-memory content to close a verification-to-execution race.
THE CONCEPT
The architectural move
Attested Boot v2 performs a single read during attestation, hashes the captured bytes, and delegates execution from that verified in-memory representation. A sealed import path serves the already-verified supervisor content.
SIGNIFICANCE
Why it matters
This repairs the root cause of a time-of-check/time-of-use gap rather than adding another check around the same unsafe two-read design.
SYSTEM FLOW
Architecture at a glance
- 01Single byte read
- 02Hash and seal verification
- 03In-memory compilation
- 04Sealed supervisor import
- 05Attestation receipt
SCENARIO
Post-check file swap
INPUT
Replace the launcher on disk immediately after attestation.
SYSTEM RESPONSE
The current boot still executes the captured verified bytes. The changed disk file is detected as CODE_CHANGED during the next attestation.
PROTECTED SNIPPET
Verify-what-you-execute invariant
verified_bytes = read_once(launcher_path)
assert digest(verified_bytes) == qualified_digest
code = compile(verified_bytes, launcher_path)
execute(code)Conceptual excerpt. Internal implementation, tests, configuration, and operational logic are withheld.
EVIDENCE STATUS
What supports it
A dedicated regression suite covers baseline verification, state and code divergence, ledger conditions, replay behavior, and the original race scenario.
LIMITATIONS
What remains bounded
Attestation is only as trustworthy as its foundational canonicalization, storage, and qualification inputs; those dependencies require independent tests.
LICENSING PATH
Use the concept without exposing the source.
Available as a reusable integrity pattern for Python launchers, governed runtimes, and sealed application baselines.