Cele mai multe sisteme de operare moderne sunt construite pe decenii de cod acumulat, biblioteci și dependențe externe. Deși acest ecosistem permite dezvoltare rapidă, el introduce și complexitate, presupuneri ascunse și riscuri de securitate potențial neexaminate.

EriX adoptă o abordare diferită.

Este dezvoltat ca un sistem de operare clean-room, ceea ce înseamnă că fiecare componentă - de la bootloader la serviciile din spațiul utilizator - este implementată în cadrul proiectului însuși, fără a încorpora cod sursă extern sau biblioteci terțe.

Acest articol explorează ce înseamnă dezvoltarea clean-room în practică, de ce este utilă și ce compromisuri introduce.

Ce înseamnă “clean-room”?⌗

În contextul EriX, dezvoltarea clean-room înseamnă:

  • Nu este copiat sau reutilizat cod sursă extern
  • Nu sunt incluse biblioteci sau crates terțe
  • Toate componentele sunt implementate în cadrul proiectului
  • Pot fi consultate doar specificații și documentație publice

Rezultatul este un sistem în care fiecare linie de cod este:

  • înțeleasă
  • auditabilă
  • proiectată intenționat

Aceasta nu este doar o decizie juridică sau de licențiere; este una arhitecturală.

De ce să evităm codul extern?⌗

Evitarea dependențelor externe poate părea restrictivă. Dezvoltarea software modernă încurajează de obicei reutilizarea, iar ecosistemele mari există tocmai pentru a evita reinventarea roții.

Totuși, sistemele de operare nu sunt aplicații obișnuite.

1. Complexitate ascunsă⌗

Codul extern aduce adesea presupuneri implicite:

  • despre dispunerea memoriei
  • despre modelele de concurență
  • despre tratarea erorilor
  • despre comportamentul platformei

Aceste presupuneri pot să nu se alinieze cu arhitectura unui nou sistem de operare, mai ales unul construit în jurul capabilităților și al izolării stricte.

2. Bază de calcul de încredere (TCB) extinsă⌗

Fiecare dependență crește dimensiunea bazei de calcul de încredere.

Dacă o bibliotecă terță este folosită în kernel sau în componente critice ale sistemului, corectitudinea ei devine parte din garanțiile de securitate ale sistemului.

Dezvoltarea clean-room menține TCB:

  • mică
  • controlată
  • definită explicit

3. Auditabilitate și verificare⌗

Un sistem construit integral intern poate fi auditat sistematic.

  • Tot codul unsafe poate fi revizuit
  • Toți invarianții pot fi documentați
  • Toate interfețele pot fi analizate rațional

Acest lucru este deosebit de important pentru un sistem ca EriX, care pune accent pe:

  • autoritate explicită
  • securitate bazată pe capabilități
  • design minim al kernelului

4. Libertate arhitecturală⌗

Reutilizarea codului existent constrânge adesea deciziile de proiectare.

De exemplu:

  • adoptarea unei biblioteci poate forța o anumită formă de API
  • integrarea codului existent poate necesita straturi de compatibilitate
  • abstracțiile moștenite se pot scurge în componente noi

Dezvoltarea clean-room permite sistemului să fie modelat în întregime de propriile principii, nu de constrângeri moștenite.

Clean-room vs. reimplementare⌗

Este important să distingem dezvoltarea clean-room de simpla reimplementare.

Dezvoltarea clean-room nu înseamnă rescrierea oarbă a sistemelor existente.

În schimb, ea implică:

  • studierea specificațiilor publice
  • înțelegerea principiilor de bază
  • proiectarea unor implementări noi pornind de la primele principii

De exemplu:

  • Un sistem de fișiere poate urma semantica POSIX, dar poate fi implementat independent
  • Un bootloader poate urma specificațiile UEFI, dar poate folosi o structură personalizată
  • O bibliotecă standard C poate expune aceeași API, dar poate fi scrisă integral în Rust

Scopul este compatibilitatea acolo unde este necesară, fără reutilizare de cod.

Clean-room în practică⌗

În EriX, constrângerile clean-room sunt aplicate în întregul sistem.

Fără crates externe⌗

Chiar și în Rust, unde reutilizarea dependențelor este comună, EriX evită crates externe.

În schimb, definește componente interne reutilizabile, precum:

  • utilitare de memorie
  • primitive de sincronizare
  • abstracții de capabilități

Biblioteci interne⌗

Funcționalitatea reutilizabilă este organizată în crates interne, de exemplu:

  • lib-bootimg
  • lib-capabi
  • lib-ipc

Aceste biblioteci sunt:

  • versionate
  • controlate în cadrul proiectului
  • proiectate special pentru nevoile sistemului

Structură strictă a repository-ului⌗

Fiecare subsistem este izolat:

  • bootloader
  • kernel
  • IPC
  • managementul memoriei
  • servicii în spațiul utilizator

Acest lucru impune modularitate și previne cuplarea ascunsă.

Builduri reproductibile⌗

Designul clean-room se extinde și la procesul de build.

Sistemul urmărește:

  • builduri deterministe
  • presupuneri minime despre lanțul de unelte
  • pași de build expliciți

Acest lucru asigură că artefactele pot fi reproduse și verificate.

Beneficiile unui OS clean-room⌗

1. Înțelegere completă a sistemului⌗

Fiecare componentă este cunoscută și înțeleasă.

Nu există dependențe opace sau comportamente ascunse.

2. Model de securitate mai puternic⌗

Cu o TCB mai mică și controlată:

  • există mai puține suprafețe de atac
  • invarianții sunt mai ușor de impus
  • securitatea bazată pe capabilități poate fi implementată curat

3. Platformă de cercetare mai bună⌗

EriX nu este doar un sistem de operare; este și o platformă de cercetare.

Dezvoltarea clean-room permite:

  • experimentarea cu abstracții noi
  • măsurarea precisă a compromisurilor de proiectare
  • raționament clar despre autoritate și izolare

4. Mentenabilitate pe termen lung⌗

Deși inițial presupun mai multă muncă, sistemele clean-room pot fi mai ușor de întreținut:

  • fără ruperi de dependențe
  • fără schimbări upstream de urmărit
  • fără conflicte de versiuni

Sistemul evoluează în propriii săi termeni.

Compromisuri și provocări⌗

Dezvoltarea clean-room nu este lipsită de costuri.

1. Dezvoltare mai lentă⌗

Totul trebuie construit de la zero:

  • biblioteci de bază
  • suport runtime
  • servicii de sistem

Acest lucru crește semnificativ efortul inițial.

2. Reinventarea roții⌗

Multe probleme au fost deja rezolvate în altă parte.

Reimplementarea lor necesită timp și proiectare atentă.

3. Mai puține scurtături⌗

Nu există posibilitatea de a:

  • importa rapid o bibliotecă
  • te baza pe ecosisteme existente
  • delega complexitatea către cod extern

Toată complexitatea trebuie gestionată direct.

4. Responsabilitate mai mare de proiectare⌗

Fiecare abstracție trebuie proiectată deliberat.

Greșelile nu pot fi acoperite ușor prin schimbarea dependențelor.

De ce această abordare se potrivește cu EriX⌗

EriX este construit în jurul câtorva principii centrale:

  • bază de calcul de încredere minimă
  • autoritate explicită prin capabilități
  • separare strictă între kernel și spațiul utilizator
  • reproductibilitate și determinism

Dezvoltarea clean-room susține toate aceste obiective.

Ea asigură că:

  • autoritatea nu este niciodată ascunsă în cod extern
  • invarianții sistemului sunt complet controlați
  • arhitectura rămâne coerentă în toate componentele

O bază pentru self-hosting⌗

Designul clean-room susține și obiectivul pe termen lung al self-hostingului.

Pentru a construi EriX în interiorul EriX, sistemul trebuie să includă:

  • propriul lanț de unelte
  • propriile biblioteci runtime
  • propriile interfețe de sistem

Un sistem care depinde puternic de componente externe ar avea dificultăți în a atinge acest nivel de independență.

Privind înainte⌗

Proiectarea unui sistem de operare clean-room este un efort pe termen lung. Ea necesită planificare atentă, implementare disciplinată și disponibilitatea de a construi componente fundamentale de la zero.

Dar creează și un sistem care este:

  • transparent
  • controlat
  • înțeles în profunzime

În articolele viitoare vom trece de la principii la implementare, începând cu procesul timpuriu de boot și cu designul formatului de imagine de boot al sistemului.