Skip to content

OCIRE core - 3.0.0 WP-01 (development milestone)

Pre-release
Pre-release

Choose a tag to compare

@cubestudio-dev cubestudio-dev released this 26 Oct 20:03
· 55 commits to main since this release

OCIRE core - 3.0.0 work package WP-01

OpenCubeOS Independent Recovery Environment - a second L0 kernel,
fully independent of the Open Cube OS (OCOS) kernel. This milestone is
the WP-01 scope only: OCIRE boots independently and runs a minimal
shell
. This is a development milestone on the way to 3.0.0, not the
3.0.0 release (recovery features land in WP-02, the OCOS<->OCIRE
interface and process protection in WP-03).

What is in this milestone

  • ocire/ - an independent kernel source tree sharing no code with
    OCOS: multiboot2 boot (BIOS + UEFI via GRUB), 4 GiB identity map,
    minimal IDT with real fault diagnostics, serial + VGA text dual
    console, serial + PS/2 polled input, checksum-verified ACPI
    (RSDP/XSDT/FADT) with a tiny \_S5 package reader, and a shell
    with exactly three commands: help, shutdown, reboot.
  • Standalone boot image OCIRE-3.0.0-WP-01.iso (attached below, also
    on the website download page) - boots straight into the OCIRE shell
    under SeaBIOS and OVMF.
  • Dual-boot disk tooling (make ocire-disk): a GRUB menu disk where
    the user picks Open Cube OS (default) or OCIRE, with the
    OCIRE kernel living on its own disk in a partition OCOS cannot read
    or write.
  • CI gate: make ocire-kernel (same -Wall -Wextra -Werror
    zero-warning rule as the OCOS kernel) and make ocire-iso run on
    every push.

Verified (all real QEMU runs, logs in evidence/3_0_0_wp01_ocire/)

Acceptance Result
Compile 0 errors 0 warnings PASS (-Wall -Wextra -Werror)
OCIRE boot image produced PASS (hybrid BIOS+UEFI ISO, 2326528 B)
QEMU boots OCIRE to a shell prompt PASS, BIOS and UEFI
help lists the commands PASS
shutdown really powers off PASS (ACPI S5; QEMU exits)
reboot really resets PASS (8042/RESET_REG; -no-reboot QEMU exits)
OCIRE partition: OCOS cannot read/write PASS - measured, see below
OCOS regression unaffected PASS - full 2.2.0 matrix re-run, all green
Three-way SHA consistent PASS (see the digest table)
CI green PASS (8517eeb, 26d401d, 0226e8c, 311877d all success)

OCIRE battery: 14/14 (BIOS + UEFI). Dual-boot + isolation battery:
11/11 (menu default -> OCOS and menu pick -> OCIRE, both firmwares;
isolation probes below). OCOS regression: host 17 + 2 declared fixture
skips, reproducible-check PASS, wp12 14/14, wp10_tui 37/37 (no #DF),
chinese 21/21, tuiqa 32/32 + 32/32, native 36/36 + 36/36, l1_per_app
35/35 (two runs each with one stray runner-side serial row on a
different app - the same declared phenomenon from the 2.2.0 release;
three logs kept), wait4 fresh-boot battery 20/20 CLEAN, boot gates
BIOS + UEFI PASS.

Partition isolation - what was measured

OCIRE's disk carries a single MBR entry of type 0xEE ("GPT protective
shadow") with no GPT header. From inside a running OCOS:

partscan: 1 partition device(s) registered     <- the OCIRE disk contributes ZERO devices
parted hdb  -> Partition table (MBR) listed   <- control disk: visible
parted hda  -> no partition table found        <- OCIRE disk: table refused
mkfs.fat32 hdap1 confirm -> device not found   <- no node to write through
disk_rw_test hdap1       -> device lookup FAIL <- no node to read through

Honest boundary, measured too: whole-disk device nodes still exist
(disk_rw_test hda, mkfs.fat32 hda confirm work on a throwaway
copy) - the same semantics Linux root has with /dev/sdb. Blocking
those administrator-level whole-disk operations requires an OCOS
block-layer policy change, which this work package's "do not touch
OCOS" rule forbids; that hardening belongs to WP-03.

Asset digests

Asset Size SHA256
OCIRE-3.0.0-WP-01.iso 2326528 155b01f6652df6ac9788906df8344a4a50db96592e95ff698ed600eaa6fcbca4
ocire.elf (CI artifact) 15736 59011bd8c081a02c63faee78704005481a4d2f4372b8ac8e9ba620e18ed6a4cd

Engineering notes

Two integration lessons found by live testing are encoded in the tree:
GRUB 2.12's msdos partmap skips 0xEE entries (the dual-boot menu loads
the OCIRE kernel with a whole-disk blocklist instead), and the UEFI
El Torito entry must be the ESP FAT image (OVMF cannot boot a bare
BOOTX64.EFI payload). Design document: docs/dev/ocire.md.

Apache-2.0 - Copyright cubestudio-dev <cubestudio@qq.com>