Repository navigation
OCIRE core - 3.0.0 WP-01 (development milestone)
Pre-releaseOCIRE 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\_S5package 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) andmake ocire-isorun 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>