Post-M6 enhancement: when /dev/substrate-hfl is loaded and the
bascule-core `hfl` feature is enabled, the new
compose_via_hfl_or_local() entry point hands a serialized
SessionClaim to the kernel's attestation::SAT_BUNDLE function and
uses the kernel-composed SatBundle (proto-encoded) in place of the
locally-composed M1 bundle. Kernel composition has access to TPM
state, governance state, and platform-claim producers Bascule can't
reach from userspace.
Without the `hfl` feature: M1 path unchanged.
With the `hfl` feature but no kernel module: graceful fallback to
the M1 local compose path. Per ADR D9, the SAT chain stays alive
regardless of HFL availability.
bascule-core::hfl_sat (NEW, behind --features hfl):
- compose_via_hfl_or_local(inputs) tries the kernel path first.
On any failure (device missing, ioctl error, decode error)
it logs at debug and returns the local M1 compose result.
- try_compose_via_hfl() encodes the SessionClaim with prost,
dispatches via HflClient::dispatch(0x0005, 1, claim_bytes,
[0u8;32], current_epoch), and decodes the result as a
proto SatBundle.
- 2 unit tests cover the device-absent fallback path (+ structure
equivalence with the M1 local compose).
Cargo.toml:
- Workspace deps: hfl-types + substrate-hfl as path deps to the
substrate workspace (cross-workspace, CI mounts both checkouts
side by side).
- bascule-core gains a `hfl` feature gating hfl-types +
substrate-hfl + prost (the last for SessionClaim::encode_to_vec
on the substrate-proto-generated types).
Tested (Docker rust:1.88-bookworm):
cargo build -p bascule-core clean
cargo test -p bascule-core --lib sat 7/7 (M1 regression)
cargo build -p bascule-core --features hfl clean
cargo test -p bascule-core --features hfl --lib 26/26
+2 hfl_sat tests on top of the existing bascule-core suite
Branched off main (post-merge of the M1..M5 stack).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Claude Code <claude@guildhouse.dev>
Claude Code
33f6bf729a