De flesta moderna operativsystem bygger på årtionden av ackumulerad kod, bibliotek och externa beroenden. Även om detta ekosystem möjliggör snabb utveckling för det också med sig komplexitet, dolda antaganden och potentiellt ogranskade säkerhetsrisker.

EriX använder ett annat angreppssätt.

Det utvecklas som ett renrumsoperativsystem, vilket innebär att varje komponent - från starthanteraren till tjänster i användarrymden - implementeras inom projektet självt, utan att extern källkod eller tredjepartsbibliotek tas in.

Detta inlägg utforskar vad renrumsutveckling innebär i praktiken, varför den är användbar och vilka kompromisser den medför.

Vad betyder “renrum”?⌗

I EriX sammanhang innebär renrumsutveckling:

  • Ingen extern källkod kopieras eller återanvänds
  • Inga tredjepartsbibliotek eller crates inkluderas
  • Alla komponenter implementeras inom projektet
  • Endast offentliga specifikationer och dokumentation får användas som referens

Resultatet är ett system där varje kodrad är:

  • förstådd
  • granskningsbar
  • avsiktligt utformad

Detta är inte bara ett juridiskt beslut eller ett licensbeslut - det är ett arkitekturbeslut.

Varför undvika extern kod?⌗

Att undvika externa beroenden kan verka begränsande. Modern programvaruutveckling uppmuntrar vanligtvis återanvändning, och stora ekosystem finns just för att undvika att uppfinna hjulet på nytt.

Operativsystem är dock inte vanliga applikationer.

1. Dold komplexitet⌗

Extern kod för ofta med sig implicita antaganden:

  • om minneslayout
  • om parallellitetsmodeller
  • om felhantering
  • om plattformsbeteende

Dessa antaganden kanske inte stämmer med arkitekturen hos ett nytt operativsystem, särskilt ett som byggs kring kapabiliteter och strikt isolering.

2. Större betrodd beräkningsbas (TCB)⌗

Varje beroende ökar storleken på den betrodda beräkningsbasen.

Om ett tredjepartsbibliotek används i kärnan eller i kritiska systemkomponenter blir dess korrekthet en del av systemets säkerhetsgarantier.

Renrumsutveckling håller TCB:

  • liten
  • kontrollerad
  • explicit definierad

3. Granskningsbarhet och verifiering⌗

Ett system som byggs helt internt kan granskas systematiskt.

  • All unsafe-kod kan granskas
  • Alla invarianter kan dokumenteras
  • Alla gränssnitt kan resoneras om

Detta är särskilt viktigt för ett system som EriX, som betonar:

  • explicit auktoritet
  • kapabilitetsbaserad säkerhet
  • minimal kärndesign

4. Arkitektonisk frihet⌗

Återanvändning av befintlig kod begränsar ofta designbeslut.

Till exempel:

  • ett bibliotek kan tvinga fram en viss API-form
  • integrering av befintlig kod kan kräva kompatibilitetslager
  • äldre abstraktioner kan läcka in i nya komponenter

Renrumsutveckling gör att systemet kan formas helt av sina egna principer, i stället för av ärvda begränsningar.

Renrum kontra återimplementering⌗

Det är viktigt att skilja renrumsutveckling från enkel återimplementering.

Renrumsutveckling betyder inte att befintliga system skrivs om blint.

I stället innebär det:

  • att studera offentliga specifikationer
  • att förstå underliggande principer
  • att utforma nya implementationer från första principer

Till exempel:

  • Ett filsystem kan följa POSIX-semantik, men implementeras oberoende
  • En starthanterare kan följa UEFI-specifikationer, men använda en egen struktur
  • Ett C-standardbibliotek kan exponera samma API, men vara skrivet helt i Rust

Målet är kompatibilitet där den behövs, utan återanvändning av kod.

Renrum i praktiken⌗

I EriX tillämpas renrumsbegränsningar över hela systemet.

Inga externa crates⌗

Även i Rust, där återanvändning av beroenden är vanligt, undviker EriX externa crates.

I stället definierar systemet interna återanvändbara komponenter såsom:

  • minnesverktyg
  • synkroniseringsprimitiver
  • kapabilitetsabstraktioner

Interna bibliotek⌗

Återanvändbar funktionalitet organiseras i interna crates, till exempel:

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

Dessa bibliotek är:

  • versionerade
  • kontrollerade inom projektet
  • utformade specifikt för systemets behov

Strikt repositorystruktur⌗

Varje subsystem är isolerat:

  • starthanterare
  • kärna
  • IPC
  • minneshantering
  • tjänster i användarrymden

Detta tvingar fram modularitet och förhindrar dold koppling.

Reproducerbara byggen⌗

Renrumsdesign sträcker sig även till byggprocessen.

Systemet eftersträvar:

  • deterministiska byggen
  • minimala antaganden om verktygskedjan
  • explicita byggsteg

Detta säkerställer att artefakter kan reproduceras och verifieras.

Fördelar med ett renrums-OS⌗

1. Full förståelse av systemet⌗

Varje komponent är känd och förstådd.

Det finns inga ogenomskinliga beroenden eller dolda beteenden.

2. Starkare säkerhetsmodell⌗

Med en mindre och kontrollerad TCB:

  • finns färre angreppsytor
  • är invarianter lättare att upprätthålla
  • kan kapabilitetsbaserad säkerhet implementeras rent

3. Bättre forskningsplattform⌗

EriX är inte bara ett operativsystem - det är också en forskningsplattform.

Renrumsutveckling möjliggör:

  • experiment med nya abstraktioner
  • precis mätning av designkompromisser
  • tydligt resonemang om auktoritet och isolering

4. Långsiktig underhållbarhet⌗

Även om det innebär mer arbete i början kan renrumssystem vara enklare att underhålla:

  • inga beroenden som går sönder
  • inga uppströmsändringar att följa
  • inga versionskonflikter

Systemet utvecklas på sina egna villkor.

Kompromisser och utmaningar⌗

Renrumsutveckling är inte utan kostnad.

1. Långsammare utveckling⌗

Allt måste byggas från grunden:

  • grundläggande bibliotek
  • runtime-stöd
  • systemtjänster

Detta ökar den initiala arbetsinsatsen avsevärt.

2. Att uppfinna hjulet på nytt⌗

Många problem har redan lösts någon annanstans.

Att återimplementera dem kräver tid och noggrann design.

3. Färre genvägar⌗

Det finns ingen möjlighet att:

  • snabbt importera ett bibliotek
  • förlita sig på befintliga ekosystem
  • delegera komplexitet till extern kod

All komplexitet måste hanteras direkt.

4. Större designansvar⌗

Varje abstraktion måste utformas medvetet.

Misstag kan inte enkelt döljas genom att byta beroenden.

Varför detta angreppssätt passar EriX⌗

EriX bygger på några kärnprinciper:

  • minimal betrodd beräkningsbas
  • explicit auktoritet genom kapabiliteter
  • strikt separation mellan kärna och användarrymd
  • reproducerbarhet och determinism

Renrumsutveckling stöder alla dessa mål.

Den säkerställer att:

  • auktoritet aldrig döljs i extern kod
  • systemets invarianter är helt kontrollerade
  • arkitekturen förblir konsekvent över alla komponenter

En grund för självhosting⌗

Renrumsdesign stöder också det långsiktiga målet självhosting.

För att bygga EriX inuti EriX måste systemet innehålla:

  • sin egen verktygskedja
  • sina egna runtime-bibliotek
  • sina egna systemgränssnitt

Ett system som är starkt beroende av externa komponenter skulle ha svårt att uppnå denna nivå av oberoende.

Framåt⌗

Att utforma ett renrumsoperativsystem är en långsiktig insats. Det kräver noggrann planering, disciplinerad implementation och en vilja att bygga grundläggande komponenter från grunden.

Men det skapar också ett system som är:

  • transparent
  • kontrollerat
  • djupt förstått

I framtida inlägg går vi från principer till implementation, med början i den tidiga startprocessen och designen av systemets boot image-format.