Claude Code
33f6bf729a
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>
47 lines
1.7 KiB
TOML
47 lines
1.7 KiB
TOML
[workspace]
|
|
members = [
|
|
"crates/bascule-core",
|
|
"crates/bascule-server",
|
|
"crates/bascule-auth-agent-id",
|
|
"crates/bascule-shell",
|
|
"crates/bascule-dashboard",
|
|
"crates/bascule-dashboard-web",
|
|
]
|
|
resolver = "2"
|
|
|
|
[workspace.package]
|
|
version = "0.1.0"
|
|
edition = "2021"
|
|
license = "Apache-2.0"
|
|
|
|
[workspace.dependencies]
|
|
# M1: depend on the canonical proto-generated SAT types from the substrate
|
|
# workspace. Path dep across workspaces; CI mounts both checkouts side by
|
|
# side. substrate-proto is itself a thin facade over substrate-common which
|
|
# owns the tonic-build invocation, so consumers only need to worry about
|
|
# the substrate-proto import surface.
|
|
substrate-proto = { path = "../substrate-project/substrate/crates/substrate-proto" }
|
|
# Post-M6: optional HFL kernel-dispatch path. Pulled by `bascule-core`
|
|
# under the `hfl` feature so the M5/M1 SAT compose path can route
|
|
# through audit::SAT_BUNDLE on nodes with /dev/substrate-hfl loaded.
|
|
# Cross-workspace path dep — CI mounts both checkouts side by side.
|
|
hfl-types = { path = "../substrate-project/substrate/crates/hfl-types" }
|
|
substrate-hfl = { path = "../substrate-project/substrate/crates/substrate-hfl" }
|
|
russh = "0.46"
|
|
russh-keys = "0.46"
|
|
tokio = { version = "1", features = ["full"] }
|
|
async-trait = "0.1"
|
|
anyhow = "1"
|
|
thiserror = "1"
|
|
tracing = "0.1"
|
|
tracing-subscriber = { version = "0.3", features = ["env-filter"] }
|
|
serde = { version = "1", features = ["derive"] }
|
|
toml = "0.8"
|
|
chrono = { version = "0.4", features = ["serde"] }
|
|
uuid = { version = "1", features = ["v4"] }
|
|
rand = "0.8"
|
|
clap = { version = "4", features = ["derive"] }
|
|
portable-pty = "0.8"
|
|
serde_json = "1"
|
|
reqwest = { version = "0.12", default-features = false, features = ["json", "rustls-tls"] }
|
|
jsonwebtoken = "9"
|