Skip to content

CosmoOS 1.0.11-rc2

Pre-release
Pre-release

Choose a tag to compare

View all tags
@github-actions github-actions released this 23 Oct 13:25
· 75 commits to main since this release
v1.0.11-rc2
af38131
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

CosmoOS 1.0.11-rc2: the 1.0 roadmap completed. CosmoOS installs to a disk, reboots into it, is used through BusyBox ash, keeps files across reboots, reaches the network by name, accepts an ssh login, and has a verified boot chain and sound randomness, on x86-64 and AArch64 under QEMU.

Start with the user guide. Each architecture's files: cosmoos-ARCH.img (the signed live image), its UEFI loader, kernel.elf, boot.tar, cmdline, the signed manifest, cosmo-upgrade and its signed package. SHA256SUMS.sig is SHA256SUMS's detached signature with the release key below (scripts/modsign.py verify-detached, or cosmo-verify on an installed system); check the files with sha256sum --ignore-missing -c SHA256SUMS.

Release signing key

The loader in these images verifies the kernel, boot archive and command line against this Ed25519 key (and the kernel trusts it for modules and packages):

  • public key: d2c778bcb38775790b6b6e843631bd2e76d6a29ec52296ece6e2d67c1bef41f8
  • key id: 36ae7bb4947896ab (the first 8 bytes of SHA-512 of the key; the boot log prints it: verified boot, key 36ae7bb4947896ab)
  • in the repository: tools/keys/release-2026.pub

Toolchain

Built and tested in the project's CI images (ci/Dockerfile), pinned by digest:

  • toolchain: ghcr.io/vkuttyp/cosmoos-ci@sha256:f6aee1470b952bdb426b8d55cfcccb734c9c1f4dac50c89edefba4e8be3be385
  • litmus: ghcr.io/vkuttyp/cosmoos-ci@sha256:c8b16f9c652cd99e4a557c08adc451528cc9cd36ba0e9e37b2973feffb15a5a9
  • clang 1:19.0-63
  • lld 1:19.0-63
  • llvm 1:19.0-63
  • qemu-system-x86 1:10.0.13+ds-0+deb13u1
  • qemu-system-arm 1:10.0.13+ds-0+deb13u1
  • ovmf 2025.02-8+deb13u1
  • qemu-efi-aarch64 2025.02-8+deb13u1
  • mtools 4.0.48-1
  • python3 3.13.5-1
  • clang-19 1:19.1.7-3+b1
  • lld-19 1:19.1.7-3+b1
  • llvm-19 1:19.1.7-3+b1

Third-party sources

Fetched and checked against these SHA-256 digests (ports/busybox/busybox.mk, ports/dropbear/dropbear.mk, ports/openssh/openssh.mk, ports/mbedtls/mbedtls.mk):

Source Version SHA-256
BusyBox 1.37.0 3311dff32e746499f4df0d5df04d7eb396382d7e108bb9250e7b519b837043a4
musl 1.2.5 a9a118bbe84d8764da0ea0d28b3ab3fae8477fc7e4085d90102b8596fc7c75e4
compiler-rt 19.1.7 c12b6e764202c615c1a3af9a13d477846878757ae0e29e5f8979215a6958fffc
dropbear 2026.94 e098034a843699200c8c977a991fff73159735bf795d5f72ef672c41a6b1ae81
OpenSSH portable (sftp-server only) 10.6p1 a9dc9565dffe8640f64d863cd29a32bc4a3dbdec0566a7fc44c5d6ee767d5f39
mbedTLS 3.6.7 a7e8bcbec0e6f761b4af24f25677626b35f762f68eef79c08677a363212d11f6
CA certificates (curl's extract of Mozilla's) 2026-09-25 a41b5d356aea97a529fe27e0f7316d2f9d946d75927476cf9cf1b90637d00505

Reproducibility

Each architecture was built twice from the tag v1.0.11-rc2, in two fresh containers of the toolchain image above, with the release key; every file below was identical in both:

  • x86_64: two builds, 10 files each, identical; cosmoos-x86_64.img sha256 8d6177bdc9c1d9a8b11298960eea3f4542ffae25700e76508abdd5cce3fea555
  • aarch64: two builds, 10 files each, identical; cosmoos-aarch64.img sha256 d44c6fbf728e2094edc8ff47fe31e1658474b0790cc8069e07cef4a161273e0d

To rebuild: check out the tag, run the toolchain image above, and make ARCH=<arch> SIGNING=release MODSIGN_KEY=<key> KEYRING_PUBS=tools/keys/release-2026.pub release. Without the private key, a build with your own key differs in what the key reaches: the key ring compiled into the kernel and loader, the signatures on modules, packages and the manifest, and the archive and image that hold them.

SHA256SUMS

8d6177bdc9c1d9a8b11298960eea3f4542ffae25700e76508abdd5cce3fea555  cosmoos-x86_64.img
115ef94c7916d2ba01ed3127701506beb2cc8199f6835a4e4489966fa34ffb67  cosmoos-x86_64-BOOTX64.EFI
fa5ec9b41c6161337f5a17b9b19410f3d89f0cce60b0b3271f87e3475ec28bbe  cosmoos-x86_64-kernel.elf
f4ca8fdbf1e1ef8d8a7e92f1877ff4c80b8393793401e9b68ab5c5969e7d6a6a  cosmoos-x86_64-boot.tar
7a77470be4312a22db40932c6cd8ddcd6d42a29b07101cbbe135cbfa1fc1aa14  cosmoos-x86_64-cmdline
5e96196d25ff653c46452e4079e3e715f066a27f096dbc7ee0e542a64135d684  cosmoos-x86_64-manifest
e8d3475826bfd1d013cc078a6ebaedb1142518949fab105c005a8890b2b11960  cosmoos-x86_64-cosmo-upgrade
4cf2f7ce417883c1c5ff38e246f0ba9b06a049d548cc13de728bae2c2242a750  cosmoos-x86_64-cosmo-upgrade.cpk
d44c6fbf728e2094edc8ff47fe31e1658474b0790cc8069e07cef4a161273e0d  cosmoos-aarch64.img
0d00053d85654789deaf9fa0edc5cb8231d8d142140c1198bcb38cfedc8ff87e  cosmoos-aarch64-BOOTAA64.EFI
61c3b0435164d86cbf1881c32b31fe8142012265c756b0e5cd0128ea377494f9  cosmoos-aarch64-kernel.elf
a5119fc33f81ba28f581c84b492dbebb5f76e01d84487f958457838bc287bdf8  cosmoos-aarch64-boot.tar
7a77470be4312a22db40932c6cd8ddcd6d42a29b07101cbbe135cbfa1fc1aa14  cosmoos-aarch64-cmdline
a1c87b674344faa0eddb34373812953be75e586031588c96164a49fdc60170be  cosmoos-aarch64-manifest
8d25dc5353238833fb56e7d2f1673a08d0094f0e6dfa20268a02011373ba8444  cosmoos-aarch64-cosmo-upgrade
871b1df87c4227198b7bd9034f1ed060869fff094b231c93d9baf211cd72a58c  cosmoos-aarch64-cosmo-upgrade.cpk

Known limitations

What CosmoOS 1.0 does not do, or does differently from what you may
expect. Each item names where it is recorded; the work that remains
after 1.0 is in docs/plan.md, and the full list of known
gaps in the deferred-work inventory.

Machines

  • QEMU is the tested platform. x86-64 on q35 and AArch64 on virt
    are tested by CI; there is no physical hardware matrix. Since v1.0.1
    the AArch64 image boots on Parallels Desktop 27 on Apple Silicon, and
    since v1.0.3 installs on its NVMe disks and has a network there; its
    SATA disks are not seen (Tested platforms). Out of scope for 1.0
    (roadmap): GPU and display beyond a text console (on
    the firmware's framebuffer, or a virtio-gpu adapter at the display's
    own size: no 3D, cursor or display interface for programs), CPU and memory
    hotplug (PCIe disks can be added and removed since v1.0.11), NUMA, more than 64 CPUs, huge pages, live migration,
    RAID-Z, eBPF, and the Intel VMX backend on hardware.
  • Randomness from the weakest source last. The pool seeds from the
    CPU's random instructions, the firmware's EFI_RNG_PROTOCOL or a
    virtio-rng; with none of them (Parallels Desktop) a timing-jitter source
    seeds it, credited conservatively (docs/kernel/security/design.md §6).
    random.jitter=off on the command line turns that off, and the pool
    then never seeds there. The commands in this guide add -device virtio-rng-pci.
  • The clock is stepped, not slewed. The wall clock is set at boot
    from the RTC or, with none (Parallels), the firmware's time. Since
    v1.0.4 root can set it (date -s, hwclock -w where there is an RTC)
    and ntpd -q steps it once from a server; there is no NTP daemon,
    because adjtimex is not implemented, and no time zone.
  • No Wi-Fi, Bluetooth or sound.

Boot and security

  • Verified boot covers the loader's three files (kernel, boot archive,
    command line). The root filesystem is not verified; the loader is
    not signed for UEFI Secure Boot; there is no TPM measurement
    and no rollback protection for manifests or modules (inventory
    2.9).
  • No KASLR: the kernel is at a fixed address. User-space ASLR covers
    the stack, heap, mmap and PIE executables; a non-PIE (ET_EXEC)
    program loads at its fixed address.
  • One user, root. Privileges, not uids, separate what processes may
    do (Privileges). A root session holding fewer
    privileges can still rewrite files in /etc that a later boot runs
    with all of them (M5 report, inventory 2.9).

Shell and commands

  • The commands are the BusyBox applets listed in the shell
    page    : no ping6; no hard links; no /sys.
  • /proc has the process directories and a fixed set of system files
    (meminfo, stat, loadavg, uptime, mounts, version,
    cpuinfo). A process has no nice value and no user/system split of its
    CPU time; ps's TT column is a pair of Linux device numbers (5,1
    for the console), since devices here have none of their own; and a
    process's environ is what exec gave it, not what it has since written
    over (inventory §13).
  • The terminal driver honours the common modes (canonical input, echo,
    signals, raw mode, window size); most other termios flags and control
    characters are accepted and ignored (inventory 1.4).
  • No swap.

Networking

  • wget's certificate authorities are fixed in the image
    (/etc/ssl/certs/ca-certificates.crt, as built); nothing updates them,
    and there is no certificate revocation check
    (Networking).
  • The address comes from DHCP. There is no runtime tool to set one by
    hand; /etc/resolv.conf is written once per boot, not on lease
    renewal; the DHCP client does no ARP probe or DECLINE, no INIT-REBOOT,
    no RELEASE, and ignores classless routes (option 121) (inventory 2.5).
  • IPv6 is link-local; there is no IPv6 routing beyond the link, no IP
    fragmentation, and no TCP SACK, window scaling or timestamps
    (inventory 2.5).
  • ssh is dropbear with key login only (Ed25519 or RSA), root only;
    no port forwarding (ssh).

Storage

  • cosmofs files are capped at 516128 blocks of 4 KiB (about 1.97 GiB),
    64516 blocks (252 MiB) when encrypted; a larger write fails with
    EFBIG.
  • A read-only mount still writes the replay of an interrupted free or
    orphan record, as a journalling filesystem replays its journal.
  • A rollback to a snapshot takes effect at the next boot (or the next
    mount of another filesystem), not in the running system
    (Snapshots and rollback); a clone of a clone, and a
    snapshot of a clone, are not possible; no RAID-Z (backlog CFS-13). A
    mirror holds at most four copies (backlog CFS-27), and a copy missing when the pool is
    mounted is rebuilt whole when it returns, not caught up (backlog
    CFS-29; Mirrors).
  • A root disk that appears late (USB storage) is not waited for: init
    stays on the live root and says so.

Packages

  • A network repository is fetched whole, file by file: no mirrors, no
    delta updates. Its index's freshness is only as good as the clock, which
    is stepped by hand or by ntpd -q, with no NTP daemon
    (Packages).
  • cosmo-upgrade --rollback returns packages and /etc only to a boot
    environment, which upgrades made by v1.0.8's cosmo-upgrade and later
    take; past an upgrade made by v1.0.7 or older it returns the boot set and
    the base system only (Upgrading). Only
    files under /root, /home and /var/log written after the upgrade
    are kept across a rollback; the root is rolled back at the next boot,
    never while it runs; one pool.

Linux programs

  • Static and PIE Linux binaries for x86-64 and AArch64 run under the
    Linux personality; it is a subset of Linux's system calls, so a
    program that needs a missing one gets ENOSYS. Dynamically linked
    musl programs run through musl's own linker, /lib/ld-musl-$ARCH.so.1,
    with libc.so and dlopen; glibc's has not been
    tried. A library with text relocations is refused (W^X); build it
    -fPIC. Native CosmoOS programs stay static.
    No containers or desktop software (docs/plan.md).
Assets 20
Loading