How a Provider Pack puts silicon on AGELAIOS nodes without a custom integration

Picture a mid-size manufacturer whose NPU, cryptographic accelerator or software-defined radio is genuinely competitive. Two programme offices want it. Each already has an integrator, a driver model and a security process of its own. The manufacturer is asked for a proprietary SDK, a dedicated port and a support contract for each buyer. Months later the silicon is still in a laboratory, and a larger supplier whose integration was paid for years ago has taken both slots.

That path is the default in tactical edge systems. Hardware arrives late. The integration locks both sides. Every programme starts from zero. For a manufacturer that cannot fund a custom integration per customer, the cost is often decisive. Better silicon stays outside the programmes that matter.

AGELAIOS offers a standard path instead. The Provider Pack, abbreviated PCK, is the delivery unit through which a manufacturer exposes silicon to AGELAIOS instances without a bilateral negotiation with every integrator. This article explains what a pack contains, how to build one without hardware using the emulated NPU pack in the reference repository, how a pack lives in a fleet, and why the mandatory software fallback serves the manufacturer as well as the operator.

The problem as the node sees it

An AGELAIOS node runs signed, isolated modules. A module that needs inference, accelerated cryptography or a waveform does not have to know which chip sits underneath. It declares a capability need in its manifest. The node matches that need with the capabilities it currently has.

For that match to work, hardware must present itself in a normalised form. That is the role of the PCK. It is how a manufacturer makes silicon visible to every AGELAIOS instance, rather than to a single integrator under a private contract.

Exposing hardware resources to workloads through a declarative interface is not unique to this project. Kubernetes device plugins follow the same principle in container infrastructure [5]. OCI specifications similarly standardise the software delivery unit [4]. The PCK adds what a defence context requires: evidence, attestation and the ability to operate offline.

Four pieces make a pack

The PCK is a signed archive. It contains four pieces, and none of them is optional.

The manifest

The manifest declares who made the pack, which hardware it targets, which version it is, and which firmware revision it covers. It also declares the hardware capabilities it exposes, using the platform’s capability vocabulary. Inference with supported formats, accelerated cryptographic primitives and available waveforms are typical examples. For each capability, the manifest names a software fallback. As with modules, nothing is implied. A capability that is absent from the manifest does not exist for the node.

The onboard self-test

The pack carries its own verification procedure. It runs on the node, without external tooling. It checks that the hardware is present, that the firmware version matches, and that known test vectors produce the expected responses. The self-test runs at activation and again when the operator requests it. A failed self-test leaves the capability on its software fallback and records the discrepancy. The node does not guess that the accelerator is healthy. It asks, and it keeps the answer.

The replayable witness session

The manufacturer records a reference session that captures the inputs submitted to the hardware and the outputs that should come back. That session can be replayed without the hardware, against the pack’s emulation, and with the hardware, against the real silicon. Integrators and evaluators therefore get a stable object of comparison, the same behaviour proven in both environments.

The witness session also serves assurance. An authority evaluating a fleet can replay the session on a reference node and file the result, without depending on the manufacturer’s laboratory. The claim is no longer a slide from a vendor demo. It is an artefact that a third party can run.

The manufacturer’s signed attestation

By signing the pack, the manufacturer attests that the manifest describes its hardware, that the self-test is its own, and that the witness session comes from its laboratory. That signature is added to the instance’s signature, which approves the pack’s entry into the fleet. It does not replace it. Two decisions remain distinct. The manufacturer stands behind the silicon it ships. The operator stands behind the decision to let that silicon into a given fleet.

When the hardware includes an attestation component that conforms to Trusted Computing Group specifications, the pack can also bind the attestation to the measured state of the platform [3]. That binding is available where the silicon supports it. It is not assumed for every accelerator.

The emulated NPU pack is the executable example

The reference repository contains a complete PCK for an emulated NPU. It is a template with a filled manifest, a working self-test, a supplied witness session and an example signing chain. It runs on the platform’s emulated x86-64 and ARM64 nodes, with no dedicated hardware.

That example serves two audiences. For the manufacturer, it is the starting point. Clone the pack, replace the emulation with the real driver, keep the structure. For everyone else, it is replayable proof. The full PCK chain of validation, signature, activation and fallback can be demonstrated on the emulator. The repository’s approximately 930 automated tests cover this path as they cover the others.

The construction path, condensed, has four stages.

1. Start from the emulated NPU pack in the repository and replay its witness session on an emulated node, so that the complete chain can be observed in operation.
2. Write the manifest for the real hardware. Declare the exposed capabilities in the platform vocabulary and name a software fallback for each.
3. Replace the emulation with the real driver and self-test, then record the witness session on the silicon.
4. Sign the pack and submit it to an instance’s store, which approves it under its own policy.

The public toolchain exposes that sequence directly.

agelaios pck new npu-example --from emulated-npu
agelaios pck test
agelaios pck sign --key ./keys/provider

The expected result is concrete. The self-test passes. The witness session replays. The attestation covers the manifest. None of these stages goes through Penrose Tactical. The manufacturer builds against a public specification and delivers to instances that decide on their own.

How a pack lives in a fleet

An approved pack enters the instance store and is distributed through the TUF (The Update Framework) repository, the same way a module is. It uses the same signer roles, the same resistance to a compromised repository and the same revocation path. A pack withdrawn by the manufacturer, or revoked by the operator after a firmware vulnerability is found, leaves the fleet through an ordinary update. The affected capabilities fall back to their software equivalents. Three mechanisms then govern the pack on the nodes themselves.

Integrity with fs-verity

The pack’s files are sealed with fs-verity. The Linux kernel verifies every read against a hash tree whose root is fixed at installation [1]. An alteration of the pack on disk, even after installation, makes the modified blocks unreadable instead of serving them. Integrity is not a checksum checked once at install time. It is a property of every subsequent read.

Measurement with IMA

The Integrity Measurement Architecture measures the pack’s executables and libraries at execution time and keeps a log of those measurements, which can be anchored in the node’s TPM [2][3]. The instance operator can later prove what actually ran on a node, not only what was installed. That distinction matters in an audit. Installation records describe intent. IMA describes what executed.

Activation without interrupting service

Pack activation is designed for a node already in service. The hardware capability is validated by the self-test, then published in the node’s catalogue. Modules that were consuming the software fallback switch to hardware acceleration without a node restart. Deactivation follows the reverse path. The function returns to fallback without interrupting the capability.

This is where honesty about maturity belongs. Integration on real silicon is currently in a trial campaign. The campaign on a real ARM64 board is tooled, and its results will be published as they come, including failures. The emulated path is what the repository can demonstrate today. The silicon path is what the campaign is built to measure.

Why the mandatory software fallback is also a sales argument

The platform rule is strict. Every hardware capability exposed by a PCK must have a degraded software equivalent. Without a declared fallback, the pack does not enter the store. “Degraded” is stated honestly. Software inference is slower. Software cryptography consumes processor time. A software waveform covers fewer cases. The function itself is still delivered.

From the operator’s point of view the argument is obvious. A node whose silicon dies, or a fleet whose supplier disappears, continues to operate in a degraded mode. That is the same controlled-degradation logic as the rest of the platform.

The fallback has a structural consequence for competition. Two packs from different manufacturers that expose the same capability in the platform vocabulary are substitutable from the modules’ point of view. An operator can qualify a second silicon source without touching its modules, compare the two against the same witness session, and mix them in the fleet. The capability vocabulary plays the role that a standardised interface plays in any open market. It moves competition from integration to performance.

From the manufacturer’s point of view the argument is less obvious, and it is worth stating plainly. The mandatory fallback also protects the manufacturer’s own customer, and that is precisely what makes the hardware buyable. A defence buyer treats every dependency as a risk. Hardware with no software escape is a hard dependency. It invites clauses, escrow and suspicion. Hardware that accelerates a function whose software fallback already exists is a performance improvement, not a single point of failure.

The PCK therefore reverses the commercial burden. The hardware accelerates. It does not condition. The manufacturer sells a gain, not a captivity, and the comparison between its silicon and the software fallback can be replayed by the customer, witness session in hand.

That is the proposition to take to a programme office. It is not a private SDK that has to be rebuilt for the next buyer. It is a signed pack, built against a public specification, that a fleet can approve, distribute, revoke and fall back from. Replay the witness session and decide whether that is the integration model your silicon deserves.

Sources

1. Kernel.org, “fs-verity: read-only file-based authenticity protection”, 2024, https://www.kernel.org/doc/html/latest/filesystems/fsverity.html
2. Linux IMA Project, “Integrity Measurement Architecture (IMA) Wiki”, 2024, https://sourceforge.net/p/linux-ima/wiki/Home/
3. Trusted Computing Group, “TPM 2.0 Library Specification”, 2019, https://trustedcomputinggroup.org/resource/tpm-library-specification/
4. Open Container Initiative, “OCI Image Format Specification”, 2024, https://github.com/opencontainers/image-spec
5. The Kubernetes Authors, “Device Plugins”, 2024, https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/