Supported targets

A target is a machine a release runs on: a VM on your laptop, a board on a bench, a cloud instance, or a payload computer in orbit. A satellite carries two kinds of computer. The flight computer runs the software that keeps the spacecraft alive, and the payload computer runs the mission's own applications, such as processing instrument data. SpaceOS runs on the payload computer. SpaceOS describes each class of machine in a target profile, and describes one machine in a target manifest that names its profile, its keys, and the route its releases take.

A profile records the facts needed to assemble and run a release on that class of machine:

• the boot contract, which says which boot stage checks which signature;
• the isolation backends, the kinds of sandbox a service may run in: runc runs a Linux container inside its partition's machine, hvt runs a unikernel in its own KVM virtual machine through the Solo5 solo5-hvt tender, and spt runs a unikernel as a seccomp-confined process;
• the rollback anchor, where the node keeps its anti-rollback floor, the lowest security version it will still boot;
• the link budgets, the most bytes and the longest contact each kind of transfer may take;
• the smoke test, the procedure that checks a board meets the profile's claims.

On cm5, the link budgets allow 8 GiB in 900 s of contact for a first install, 512 MiB in 120 s for a routine update, 64 KiB in 30 s for an acknowledgement, and 1 GiB in 300 s for results.

A profile's identity is the SHA-256 of its canonical JSON form, with every set-valued member sorted, and it prints as NAME@sha256:<64 hex digits>. space target connect records that reference in the target's entry in the CLI's config.toml. Every later command that resolves the target rehashes the profile it finds under that name and refuses it as stale when the digest differs, so a connection pins the exact profile it was made against.

Profile catalog

space embeds the catalog released with the CLI. space target catalog ls prints the canonical reference of every profile it holds:

$ space target catalog ls
cm5@sha256:77ac5252abc4db00040a9339c47ec5314ef90bf6395e4b0327dedc10cd2623f0
cm5-dev@sha256:9a763f58b419708a33ba38e540d0d3b3ca9fba99846863daed4636c97bf55145
hosted-linux@sha256:5bb0ad3e78fffcf1497af02404d9ef49533c6e87e42a9b6263cedaf406010411
macos-vmm@sha256:4c549a833d4e9801bdc6f6e55485e64b23d5d33e0190ba713a20131f114a65da
scaleway@sha256:fea89f38ded01bd6243986845f7b2597ea76f95026ff8e1819bac27defd0642c

space target catalog sync updates a managed checkout of the catalog from the public parsimoni-labs/targets repository. A project can also carry its own profiles under profiles/, and a project profile takes precedence over the managed and embedded catalogs.

Profile	Machine	Integration	Isolation backends	Rollback anchor	Status
macos-vmm	Development VM on macOS, Apple silicon	System image under the host VMM	runc	Software	Supported
cm5-dev	Raspberry Pi CM5, bench	System image, flashed	hvt, runc	Software	Supported
cm5	Raspberry Pi CM5, locked	System image, flashed	hvt, runc	TPM 2.0 counter	Supported, image-level evidence
hosted-linux	Operator-owned arm64 Linux host	Daemon install	runc	Software	Supported for the daemon install
scaleway	Scaleway arm64 instance	System image, UEFI disk	runc	Software	Profile only

Integration models explains the two ways SpaceOS sits on a machine. Isolation backends lists the backends, and Boot, updates, and rollback explains the rollback anchors.

A target is supported when its profile ships and repeatable evidence exercises what that profile claims. The status column reads as follows:

• Supported. Automated scenarios build, boot, and run releases against the profile.
• Supported, image-level evidence. Automated tests check the locked CM5 image: the signed boot image, the dm-verity root, and the refusal of a modified image. The hardware procedure that checks OTP-locked boot, the TPM counter, and sealed secrets on a real board has not run.
• Supported for the daemon install. Automated scenarios build and verify the signed daemon bundle, and refuse a foreign key, a tampered daemon, and an unlisted executable. No repeatable evidence covers a runc workload running on the host.
• Profile only. The profile ships and space target apply provisions the instance, and no repeatable evidence has run against it.

Development VM (macos-vmm)

A macOS host on Apple silicon boots the system image through Apple's Virtualization framework. space run uses this profile, and space deploy --target local ships a release to the same VM. The host VMM is the boot trust anchor, and dm-verity verifies the root filesystem. The space CLI also builds and runs on Linux, where it launches the VM under QEMU, but no Linux development profile ships.

Raspberry Pi CM5 (cm5-dev and cm5)

SpaceOS is assembled as a flashable image with the Raspberry Pi firmware partition first. The board's own signed boot verifies the boot image. The kernel command line inside that signed image pins a dm-verity root hash, the root of a SHA-256 hash tree over the root filesystem's 4 KiB blocks. The kernel hashes each block as it is read, checks it up the tree to that root, and fails the read on a mismatch. Two profiles ship for the same board:

• cm5-dev is the bench profile. Signature enrollment is reversible. The rollback floor is a record on the node's own storage, authenticated with a MAC under a boot state key derived from a range of the SoC's one-time-programmable (OTP) memory. Nobody can forge the record without that key, and an attacker who can rewrite storage can still restore an older valid record, so cm5-dev claims software rollback only.
• cm5 is the locked profile. The SHA-256 hash of the customer's RSA public key is burnt into OTP memory, and the development key path is revoked, so the boot ROM accepts only a boot image that key signed. A discrete TPM 2.0 holds the rollback counter. The TPM also seals secrets to a PCR policy. A platform configuration register (PCR) can only be extended, as PCR := SHA-256(PCR || digest), and a sealed secret is released only while the chosen PCRs hold the values of the expected boot.

The two are kept apart so a reversible board never acquires the locked board's claims. Deploy to a Raspberry Pi CM5 walks through a first deploy.

Hosted Linux (hosted-linux)

The host is any operator-owned arm64 Linux with cgroup v2 and systemd v229 or newer. systemd 229 is the release that added AmbientCapabilities=, which the installed units use to give a daemon its Linux capabilities without running it as root. SpaceOS does not boot, own, or update this operating system. space target bundle signs the daemon set, space target install verifies it and installs it under /opt/space with one systemd unit per daemon, and space target verify checks it again later. The host keeps its own trust boundary, and nothing is flashed. BusyBox and SysV hosts are not supported, because the installer drives service lifecycle, update, and removal through systemd.

Provider instance (scaleway)

An arm64 Scaleway instance boots UEFI from a block volume created from an imported, content-addressed SpaceOS image. The provider's hypervisor is the boot trust anchor. space target apply creates the instance, the data volume, the routed address, the security group, and the registry namespace, then connects the target.

Boards without a profile

The six boards below are targets the platform is being built toward. SpaceOS has run on five of them on a test bench, and the sixth, the Innoflight CFC-400XS, has not been powered on yet. No profile ships for any of them, so space target connect resolves none of them by name and none is a supported target. Each one needs a profile written from the board's observed facts, and repeatable evidence against that profile, before it becomes one.

Board	Architecture	Compute	Accelerator	Vendor Linux
Raspberry Pi 4B	arm64	Broadcom BCM2711, 4 Cortex-A72 at 1.5 GHz	None	Raspberry Pi OS
Xilinx VCK190	arm64	Versal AI Core, 2 Cortex-A72	AI Engine, FPGA fabric	PetaLinux
NXP LX2160A	arm64	16 Cortex-A72 at up to 2.2 GHz	DPAA2 packet processing	NXP LSDK
NVIDIA Jetson TX2i	arm64	2 Denver 2 and 4 Cortex-A57	256-core Pascal GPU	L4T (JetPack 4)
Kalray Coolidge V1	amd64 host	80-core MPPA on a PCIe card	The MPPA itself	Host Linux with AccessCore
Innoflight CFC-400XS	arm64	Zynq UltraScale+ MPSoC, 4 Cortex-A53	FPGA fabric	Vendor Buildroot image

Each of these boards is designed to take SpaceOS as a daemon install. The vendor's Linux keeps the boot path, the kernel, and the drivers, and SpaceOS runs unikernels under hvt where the vendor kernel provides /dev/kvm and under spt where it does not. Several of these vendor kernels leave KVM off, so run ls /dev/kvm on the board before you plan around it. Integration models dates this work.

Each bench demonstration is graded on the four-level scale the platform's hardware evaluation uses:

• None: the combination has not been tested or does not work.
• Prototype: unikernels run in static partitions with CPU and memory isolation and at least serial access, with no dynamic orchestration and no access to storage or acceleration.
• Minimal: the local orchestrator schedules unikernels dynamically and talks to ground software over the network. Unikernels reach local storage, downlink data, and request input from the local manager.
• Accelerated: the same, and unikernels also drive an on-board GPU or FPGA without interfering with each other. A board with no accelerator tops out at minimal.

These grades record what ran on the bench, and no shipped profile carries any of them. The platform's accelerator schema names two device kinds, GPU and FPGA, and no shipped profile declares an accelerator, so no accelerator in this table is reachable from a SpaceOS workload today. Hardware acceleration says how a workload reaches one.

Raspberry Pi 4B

The Pi 4B boots from a microSD card and has no verified boot. The Raspberry Pi that SpaceOS supports is the CM5. On the bench the Pi 4B reached minimal under every isolation platform tried, including Xen, and it is the board where a seL4 prototype ran: unikernels partitioned by the microkernel, with serial access only and no Linux involved.

The design keeps Raspberry Pi OS on the boot path, runs the SpaceOS services on top of it, and runs unikernels under the Solo5 tenders. The Pi 4B is the lowest-cost board on this page, and it serves three uses: development on hardware you keep at your desk, a ground-test bench where several Pis model a multi-machine deployment and two of them linked over UART model a bus and payload split, and student competitions and hackathons, where commodity hardware is the constraint.

Xilinx VCK190

The VCK190 is the Versal AI Core evaluation board. PetaLinux, Xilinx's board support package and build system, owns its boot path. A SpaceOS host on this board needs a kernel with KVM enabled, and the Deep Learning Processing Unit driver for Vitis AI workloads. It reached accelerated on the bench under qemu and firecracker, and minimal under hvt, with FPGA work delegated from the unikernel to the host through the board's own acceleration API. It is the board for inference on FPGA fabric and the AI Engine.

NXP LX2160A

The LX2160A is a Layerscape system-on-chip with DPAA2, NXP's Data Path Acceleration Architecture, and up to 100 Gb/s Ethernet. It boots from NOR or QSPI flash in production and from an SD card during bring-up, with NXP's LSDK as the board support package. Its packet-processing accelerators suit high-throughput CCSDS framing on the bus interface, and Solo5 on KVM carries its unikernel workloads. On the bench it reached minimal under every isolation platform tried, including Xen with Linux as dom0; with no compute accelerator, minimal is its ceiling.

NVIDIA Jetson TX2i

The TX2i is the industrial variant of the Tegra X2 module, rated from -40 °C to +85 °C, with 8 GB of LPDDR4 and 32 GB of eMMC. JetPack 4 is the last JetPack line that supports it. It is the board for GPU-bound inference such as object detection and segmentation. The design has container services reach the Pascal GPU through CUDA once the target grants the device nodes, and unikernel services reach it through the broker's delegation path. It reached accelerated on the bench under qemu and firecracker, with unikernels using the on-board GPU, and minimal under hvt.

Kalray Coolidge V1

The Coolidge V1 is an 80-core processor array: five clusters of 16 VLIW cores at up to 1.2 GHz. It attaches to an x86-64 Linux host over PCIe, and AccessCore is Kalray's SDK for it. The design uses it as a PCIe accelerator: a unikernel or a container in a partition calls the MPPA through the broker, dispatching work through the AccessCore native API or OpenCL. It suits signal processing that gains from many-core parallelism, such as synthetic-aperture radar processing, beamforming, and dense linear algebra. On the bench it reached minimal under qemu and hvt.

Innoflight CFC-400XS

The CFC-400XS is a flight computer from Innoflight's CFC-400 series for small satellites. Its compute element is a Xilinx Zynq UltraScale+ MPSoC with four Cortex-A53 application cores at about 0.6 GHz, two Cortex-R5F real-time cores, and FPGA fabric. It has 2 GB of DRAM, about 1.7 GB usable after the contiguous memory reserve, the region the Linux Contiguous Memory Allocator sets aside at boot so drivers can later obtain physically contiguous buffers. It boots from QSPI and NAND flash with no SD card slot. A supervisor board beside the processor owns the watchdog and the reset line.

The vendor manual and its sample boot log describe the stock image:

• The boot chain is FSBL, Arm Trusted Firmware, U-Boot 2019.01, and Linux 4.19. No hypervisor boots.
• Linux runs at EL2, so the board can host KVM. An Arm processor runs code at exception levels: EL0 for applications, EL1 for an operating system kernel, and EL2 for a hypervisor. KVM on arm64 needs the kernel entered at EL2 to own the virtualization extensions. The stock kernel has CONFIG_KVM off, and turning it on takes a kernel rebuild.
• The root filesystem is an initramfs in RAM and is lost on reboot. Persistent storage is UBIFS at /mnt/ubi.
• Init is BusyBox with SysV scripts, and the root filesystem is Buildroot 2016.08 with no container runtime.

Three facts follow for SpaceOS. runc does not fit this image, whose kernel and root filesystem lack the cgroup v2, user-namespace, and overlay support it needs. The daemon install reaches a SysV host through rc.d scripts in place of systemd units, as Integration models dates. And the supervisor resets the processor board when the vendor's management daemon misses its watchdog deadline, so SpaceOS must never starve that daemon of CPU.

The intended tenant boundary on this board is Xen, with the control domain pinned to its own CPUs so the management daemon always runs. SpaceOS has no Xen backend, and the isolation backends include no Xen entry. Two existing backends could fit before Xen: spt on the stock kernel, and hvt once KVM is enabled. Neither has run on this board.

Target manifest

A target manifest, targets/NAME.yaml, names one machine: its profile, the key that signs its boot image, and the route its releases take. For example, targets/cm5-demo.yaml:

schema: space.target
version: "1"
profile: cm5-dev
connection:
  signing_key: keys/cm5-demo.pem
  endpoint: ipn:7.1
  cla_address: cm5-demo.local:4556
  always_reachable: true

profile names the machine class. The connection section holds the node's key custody and its route. endpoint is the node's endpoint ID in the Bundle Protocol version 7 (BPv7, RFC 9171), which stores and forwards data over links that are not always up. ipn:7.1 names service 1 on node 7. cla_address is the HOST:PORT of the node's convergence layer, the transport that carries bundles; 4556 is the port registered for the TCP convergence layer, RFC 9174. space target connect records the target, space target ls lists the targets connected on this machine, and space target show prints the record a deploy resolves:

$ space target connect cm5-demo
✓ cm5-demo registered: cm5-dev, always reachable
$ space target ls
   NAME      PROFILE  BOARD            ENDPOINT  CONTACT
   cm5-demo  cm5-dev  raspberrypi-cm5  ipn:7.1   always
$ space target show cm5-demo
name         : cm5-demo
profile      : cm5-dev@sha256:9a763f58b419708a33ba38e540d0d3b3ca9fba99846863daed4636c97bf55145
board        : raspberrypi-cm5
signing-key  : keys/cm5-demo.pem
dtb          : (firmware stock)
kernel       : (image default)
ack-key      : /tmp/space-docs/config/keys/target-cm5-demo-ack.pem
recipient-key: (none: whole-bundle delivery only)
runtime-provenance: (none: releases measured against this ground's own ceiling)
approves     : you, alone
endpoint     : ipn:7.1
cla-address  : cm5-demo.local:4556
contact      : always (a target on a network)
rate         : 1e+06 B/s (default)
ground       : this machine's local ground
publisher  (none: a deploy pins this machine's signing identity once a build's evidence verifies under it)
verdict    no verdict recorded: this machine keeps no deploy store yet (/tmp/space-docs/config/deploys.sqlite), where the ground `space up` runs would record what cm5-demo announces

The RSA key in signing_key signs the CM5 boot image, which is the signature the Raspberry Pi firmware verifies. The generated Ed25519 acknowledgement key authenticates the deploy acknowledgements this node signs. The node signs with the private half, which it reads from deploy/ack-key.pem under its data directory, and the ground checks each acknowledgement against the public half. A target that space target apply provisions receives the private half in the bootstrap document it boots with.

The other lines of space target show read as follows. recipient-key is the node's ML-KEM-768 public key, to which the ground encrypts each release; with none, a release travels signed as a whole bundle and unencrypted. rate is the link rate the CLI assumes for a target that is always reachable, 10^6 bytes per second when the target names none with --contact-rate. A deploy waits for the node's answer for at most ⌈300 + bytes / rate⌉ seconds, where 300 s covers staging, a trial reboot, and the acknowledgement. A 512 MiB update at the default rate is waited on for at most ⌈300 + 536,870,912 / 10^6⌉ = 837 s. In production, set ack_key to a path in your key-management system; when it is absent, the CLI generates a local key for bring-up.

A target reached over scheduled contacts needs --tle with --station, or a fixed --contact-start and --contact-stop, in place of always_reachable. --tle takes the satellite's two-line element set (TLE), and --station the ground station as LAT,LON,ALT: degrees north, degrees east, and kilometers above the WGS-84 ellipsoid. The CLI propagates the orbit and computes the passes during which the station sees the node.

space target connect records a machine that already exists and allocates nothing. space target apply creates or reconciles the provider resources the manifest's provision: section declares, then connects the target; --plan prints the plan and stops. For such a target, space target show also prints what the provider holds against the manifest, and reports that half unavailable without provider credentials.

space deploy --plan copies the resolved profile and connection into the release descriptor. --target defaults to the single target declared in targets/, and otherwise to the single target connected on this machine.