Lyx OS – LBF: Lyx Binary Format

Das Lyx Binary Format (LBF) ist das native ausführbare Binärformat von Lyx OS. Es ersetzt ELF/PE für alle Programme die mit lyxc –target=lyxos kompiliert werden, und ist von Grund auf für KI-native Architekturen und das Island & Ocean File System (IOFS) entworfen.

Version: 1.1 · Magic: LYX! (0x4C 0x59 0x58 0x21)

LBF ist das ausführbare Binärformat von Lyx OS. Anders als ELF oder PE wird ein LBF-Binary auf nativem IOFS ohne eine einzige Speicher-Kopie ausgeführt — der Kernel trägt die physischen Disk-Adressen direkt in die CPU-Seitentabelle ein. Block 0 (Genesis-Block) enthält zusätzlich einen strukturierten KI-Kontext, der dem Betriebssystem vor der ersten Ausführung mitteilt was das Programm tut und welche Rechte es benötigt.

→ Anwendungen entwickeln · Kernel-Interna · Übersicht

Zwei Emit-Modi — NICHT verwechseln:

Der Rest dieser Seite beschreibt das native LYX!-Format (Produktionspfad).

• --target=lyxos erzeugt nativen x86-64-Maschinencode im LYX!-Format; lyxc übersetzt sich selbst dorthin.
• Mehrere Sektionen sind umgesetzt — Compiler und Kernel. Der Compiler legt je Sektion einen SECTION_MAP-Eintrag im Genesis-Block ab, der Loader (kernel/lbf_exec.lyx) liest ihn und trennt .text, .rodata und .data beim Einhängen.
• W^X ist umgesetzt, konservativ: der Loader führt eine Schreibbarkeitskarte über alle Seiten des Abbilds. Weil die Nutzlast eines Blocks 4032 Byte lang ist und damit nicht auf Seitengrenzen fällt, kann eine Seite Bytes aus zwei Sektionen enthalten — deshalb gilt: eine Seite ist beschreibbar, sobald irgendein Byte darin zu einer beschreibbaren Sektion gehört. Nur Seiten, die vollständig von Nur-Lese-Sektionen gedeckt sind, werden schreibgeschützt eingehängt (PTE_P_U statt PTE_P_W_U).
• .bss wird vom Kernel genullt (Sektionstyp 4, keine Daten in der Datei).
• Rechte kommen aus dem Manifest. Die CAPABILITIES-TLV wird beim Laden auf die PLEDGE-Bits des Kernels abgebildet; ein LBF ohne Angabe bekommt nur PLEDGE_STDIO — fail-closed.
• VA-Layout: Nutzlast 4032-B-gepackt, zusammenhängend ab 0x400000; entry_point ist die volle virtuelle Adresse (normal 0x400000 = _start). Stapel 16 KB, Seitenkarte bis 8192 Seiten (= 32 MB Abbild).

• IOFS-Zero-Load-Executor (Abschnitt 6 beschreibt den Entwurf, nicht den Stand)
• ARM64-LYX! (WP-5)
• Signaturen und die Vertrauenskette aus Abschnitt 5
• Modus B (Sub-Page-Packing) — es gibt kein Flag dafür, siehe Abschnitt 2

ELF und PE tragen jahrzehntelangen Ballast: komplexe Relokationstabellen, dynamische Linker, Sektions-Parsing zur Laufzeit — und keinerlei semantische Selbstbeschreibung. LBF bricht damit auf drei Ebenen:

Physisch: LBF ist exakt auf das 4096-Byte-Page-Raster der NVMe-Hardware und der CPU ausgerichtet. Auf nativem IOFS lädt der Kernel keine Segmente in den RAM — er trägt die physischen Sektoradressen (LBAs) direkt in die Page Tables (CR3) ein. Die CPU feuert den Maschinencode ohne eine einzige Kopie.

Semantisch: Block 0 (der Genesis-Block) enthält einen strukturierten KI-Kontext-Pool, der der System-KI vor der ersten Ausführung mitteilt: was das Programm tut, welche Hardware-Erweiterungen es benötigt, welche Abhängigkeiten es deklariert, und ob die kryptografische Vertrauenskette intakt ist.

Dual-Portabel: Auf Legacy-Dateisystemen verhält sich LBF wie eine flache, sequentielle Binärdatei (POSIX-Loader lbf_run). Auf nativem IOFS injiziert der Kernel die 4-KB-Blöcke direkt als Datenknoten in den Graphen. Dasselbe Binary, zwei Lademodi, null Overhead.

Jede logische Sektion (.text, .data, .rodata) beginnt an einer physischen 4096-Byte-Grenze. Optimal für große, monolithische Anwendungen: maximale Page-Table-Mapping-Performance, jeder Block direkt als IOFS-Page importierbar.

Block 0:  Genesis-Block (4096 Bytes)
Block 1:  .text [0]
Block 2:  .text [1]
Block 3:  .rodata [0]   ← neue 4-KB-Grenze, eigene Page
Block 4:  .data [0]     ← neue 4-KB-Grenze, eigene Page

Für Kleinstprogramme und Microservices. Sektionen mit identischen Zugriffsrechten werden in dieselbe 4-KB-Page gepackt. Erst wenn sich die Schutzrechte ändern, beginnt ein neuer Block.

Packing-Regel: .text (R/X) und .rodata (R) können in eine gemeinsame Page. .data (R/W) erzwingt immer eine neue 4-KB-Grenze.

Block 0:  Genesis-Block (4096 Bytes)
Block 1:  .text + .rodata zusammen (beide R, ≤ 4032 Bytes)
Block 2:  .data [0]     ← Grenze wegen R/W

Der Compiler setzt lbf_flags |= LBF_FLAGS_PACKED im Genesis-Header. Der Loader (POSIX und IOFS) liest dieses Bit und wendet die korrekten Schutzrechte anhand des Section-Descriptor-TLV (Typ 0x08) pro Sub-Segment an.

Jeder 4096-Byte-Block beginnt mit einem 64-Byte-Blockkopf; darauf folgen 4032 Byte Nutzlast. Das gilt auch für Block 0 — die Genesis-Felder liegen also hinter dem Blockkopf.

Nachgemessen an einem Programm mit @capabilities([fs.read, hardware.block]), übersetzt mit lyxc 1.1.11B:

content_type 1   arch 1   entry 0x400000   stack_size 131072   tlv_offset 0x80

typ 5 len 8   CAPS 0x41
typ 8 len 2   0000
typ 9 len 8   SECTION_MAP start_block=1 count=2 typ=1 prot=5
typ 9 len 8   SECTION_MAP start_block=2 count=2 typ=2 prot=4
typ 9 len 8   SECTION_MAP start_block=3 count=2 typ=3 prot=3

Die Typnummern der Umsetzung weichen von der Entwurfsliste in Abschnitt 4 ab:

Im SECTION_MAP-Eintrag wertet der Kernel heute ein Bit aus: prot Bit 1 (LBF_PROT_WRITE) entscheidet, ob die Seiten beschreibbar eingehängt werden. Sektionstyp 4 ist .bss — dafür stehen keine Daten in der Datei, der Kernel nullt den Bereich.

Diese Tabelle beschreibt die geplante Fassung, nicht den heutigen Stand. Block 0 als vollständiges Kontrollzentrum: 96-Byte-Header gefolgt von einem 4000-Byte-TLV-Pool.

┌─────────────────────────────────────────────────────────────────┐
│  0x0000–0x000F  Core Machine Header          (16 Bytes)         │
│  0x0010–0x005B  Compiler Provenance Block    (76 Bytes)         │
│  0x005C–0x005F  Layout Flags & KI-Offset     (4 Bytes)          │
├─────────────────────────────────────────────────────────────────┤
│  0x0060–0x0FFF  KI-Semantik-Register / TLV-Pool (4000 Bytes)   │
└─────────────────────────────────────────────────────────────────┘

con LBF_FLAGS_PACKED : uint16 := 1

con LBF_ARCH_X86_64  : uint8 := 0x01
con LBF_ARCH_ARM64   : uint8 := 0x02
con LBF_ARCH_RISCV   : uint8 := 0x03

Block 0 folgen die Code- und Daten-Blöcke. Jeder Block ist exakt 4096 Bytes, ohne eigenen Block-Header.

BLOCK 0    Genesis-Block
BLOCK 1+   .text [0..N]    R/X — Maschinencode
BLOCK N+1  .rodata [0..]   R   — Konstanten, String-Literale
BLOCK M+1  .data [0..]     R/W — initialisierte globale Variablen
BLOCK K+1  .bss             R/W — Kernel setzt auf 0, kein Inhalt auf Disk

Im Modus B können .text + .rodata in einem gemeinsamen Block stehen; die Aufteilung steht im Section-Descriptor-TLV (Typ 0x08).

Der 4000-Byte-Pool ab Offset 0x0060 verwendet eine Type-Length-Value-Struktur:

[Type: uint8 (1 Byte)] [Length: uint16 LE (2 Bytes)] [Value: Length Bytes]
Overhead pro Eintrag: 3 Bytes

Reichen 4000 Bytes nicht aus, verweist TLV 0x05 (EXT_META_PTR) auf eine Continuation-IOFS-Page. Das Framework ist damit für beliebig komplexe Programme unbegrenzt erweiterbar.

Typen 0x09–0x0F sind im Entwurf reserviert: 0x09 (DWARF-Unwind-Frame) und 0x0A (Debug-Symboltabelle) sind für v1.2 geplant (siehe Versionstabelle). Typen 0x0B–0x0F sind unbelegt und dürfen von Custom-Toolchains genutzt werden, sofern ein Vendor-Präfix in HUMAN_INTENT (TLV 0x01) deklariert ist.

Payload: UTF-8-Freitext, max. 512 Bytes.

Enthält die semantische Beschreibung des Programms. Der Compiler extrahiert ihn aus /‑Doc-Comments über main():

/// Berechnet die CRC32C-Prüfsumme für Speichermedien im IOFS.
/// Liest Eingabe von stdin, gibt Prüfsumme als Hex auf stdout aus.
fn main(): int64 { ... }

con LBF_ISA_AVX2    : uint64 := 1    // Intel AVX2 (256-bit SIMD)
con LBF_ISA_AVX512  : uint64 := 2    // Intel AVX-512 (512-bit SIMD)
con LBF_ISA_ARM_NEON: uint64 := 4    // ARM NEON / AdvSIMD
con LBF_ISA_AMX     : uint64 := 8    // Intel AMX (KI-Beschleunigung)
con LBF_ISA_SVE     : uint64 := 16   // ARM SVE/SVE2
con LBF_ISA_RISCV_V : uint64 := 32   // RISC-V Vector Extension
con LBF_ISA_AES_NI  : uint64 := 64   // x86 AES-NI (Hardware-Verschlüsselung)
con LBF_ISA_SHA_NI  : uint64 := 128  // x86 SHA-NI (Hardware-Hashing)

con LBF_CAP_FS_READ       : uint64 := 1
con LBF_CAP_FS_WRITE      : uint64 := 2
con LBF_CAP_NET_SOCKET    : uint64 := 4
con LBF_CAP_PROC_SPAWN    : uint64 := 8
con LBF_CAP_KI_EMBED      : uint64 := 16
con LBF_CAP_KI_GRAPH_WRITE: uint64 := 32
con LBF_CAP_SANDBOX_ACCESS: uint64 := 64
con LBF_CAP_AUDIO_MIC     : uint64 := 128
con LBF_CAP_PRIVILEGED    : uint64 := 9223372036854775808   // Bit 63

1. Genesis-Block lesen; format_version prüfen (== 0x01)
2. Compiler-UUID gegen Blacklist prüfen
3. ISA_EXTENSIONS gegen CPUID des Kernels prüfen
4. Intent + Capabilities auf Kohärenz prüfen (Semantische Firewall)
5. DEP_HASH_GRAPH auflösen → Dependency-LPIDs via Hash-Index
6. SYM_INTERFACE-Contracts verifizieren
7. IOFS-Pages für alle Blöcke anlegen, Graph-Kanten weben

1. Kernel liest Genesis-Block (IOFS-Page Typ=0x04)
   → Vertrauenskette durchlaufen
   → ISA_EXTENSIONS gegen CPUID validieren

2. Kernel erstellt neues CR3-Page-Table-Root

3. Section-Descriptor-TLV (0x08) bestimmt VA-Layout:
   .text:   0x0000000000400000 + block_index × 4096
   .rodata: folgt direkt nach .text
   .data:   folgt direkt nach .rodata
   .bss:    kein Block auf Disk — Kernel alloziert zeroed Frames

4. Für jeden Block (Block 1..N):
   lba = lip_get(block_lpid)      → O(1) LIP-Übersetzung
   pte.phys_addr = lba × 4096    → LBA direkt als physische Adresse
   pte.flags     = section.prot  → R/W/X via NX-Bit
   PTE in CR3 schreiben          → kein Kopieren, kein Parsen

5. Stack allozieren (Kernel-Default: 128 KB)

6. CPU springt zu entry_point
   → Alle Pages bereits gemappt — kein erster Page-Fault
   → Kein ELF-Interpreter, kein ld.so, kein Relokations-Loop

1. Prüfe Magic "LYX!" an Byte 0
2. format_version prüfen (== 0x01)
3. Compiler-UUID gegen ~/.lyx/compiler_blacklist.bin prüfen
4. ISA_EXTENSIONS gegen CPUID prüfen
5. Section-Descriptor-TLV (0x08) auslesen
6. Blöcke 1..N via mmap() mit korrekten Schutzrechten mappen:
   .text:   PROT_READ | PROT_EXEC
   .rodata: PROT_READ
   .data:   PROT_READ | PROT_WRITE
   .bss:    mmap(MAP_ANON) → zeroed
7. DEP_HASH_GRAPH → POSIX-Pfad-Auflösung via LD_LIBRARY_PATH
8. Springe zu entry_point

con IOFS_EDGE_LBF_CHAIN : int64 := 0xB001   // Genesis → Block 1 → Block 2 → ...
con IOFS_EDGE_LBF_DEP   : int64 := 0xD001   // Genesis → externe Bibliotheks-Genesis

# Natives LYX! (Maschinencode) — Produktionspfad
lyxc main.lyx --target=lyxos -o main.lbf

# IR-Bytecode LBF\0 — NUR Simulation/Test, kein nativer Code!
lyxc main.lyx --target=lyxos --emit=lbf -o main.lbf.ir

# Cross-Compilation
lyxc main.lyx --target=arm64 -o main_arm.lbf

# Debug-LBF (TLV 0x06 zeigt auf lokale .lyx-Dateien)
lyxc main.lyx --target=lyxos --debug -o main.lbf

# Genesis-Block, TLV-Pool und Sektionen inspizieren
lbfdump -x main.lbf

# IR-Bytecode disassemblieren
lbfdump -d main.lbf.ir