Puhdastilakäyttöjärjestelmän suunnittelu
Useimmat modernit käyttöjärjestelmät rakentuvat vuosikymmenten aikana kertyneen koodin, kirjastojen ja ulkoisten riippuvuuksien varaan. Vaikka tämä ekosysteemi mahdollistaa nopean kehityksen, se tuo mukanaan myös monimutkaisuutta, piileviä oletuksia ja mahdollisesti tutkimattomia tietoturvariskejä.
EriX lähestyy asiaa toisin.
Sitä kehitetään puhdastilakäyttöjärjestelmänä, mikä tarkoittaa, että jokainen komponentti - käynnistyslataimesta käyttäjätilan palveluihin - toteutetaan projektin sisällä ilman ulkoisen lähdekoodin tai kolmannen osapuolen kirjastojen sisällyttämistä.
Tämä kirjoitus tarkastelee, mitä puhdastilakehitys tarkoittaa käytännössä, miksi se on hyödyllistä ja millaisia kompromisseja se tuo mukanaan.
Mitä “puhdastila” tarkoittaa?⌗
EriXin yhteydessä puhdastilakehitys tarkoittaa:
- Ulkoista lähdekoodia ei kopioida eikä käytetä uudelleen
- Kolmannen osapuolen kirjastoja tai crateja ei sisällytetä
- Kaikki komponentit toteutetaan projektin sisällä
- Vain julkisiin määrityksiin ja dokumentaatioon voidaan viitata
Tuloksena on järjestelmä, jossa jokainen koodirivi on:
- ymmärretty
- auditoitavissa
- tarkoituksellisesti suunniteltu
Tämä ei ole vain juridinen tai lisensointiin liittyvä päätös - se on arkkitehtuurinen päätös.
Miksi välttää ulkoista koodia?⌗
Ulkoisten riippuvuuksien välttäminen voi vaikuttaa rajoittavalta. Moderni ohjelmistokehitys yleensä kannustaa uudelleenkäyttöön, ja suuret ekosysteemit ovat olemassa juuri siksi, ettei pyörää tarvitsisi keksiä uudelleen.
Käyttöjärjestelmät eivät kuitenkaan ole tavallisia sovelluksia.
1. Piilevä monimutkaisuus⌗
Ulkoinen koodi tuo usein mukanaan implisiittisiä oletuksia:
- muistiasettelusta
- rinnakkaisuusmalleista
- virheenkäsittelystä
- alustan käyttäytymisestä
Nämä oletukset eivät välttämättä sovi uuden käyttöjärjestelmän arkkitehtuuriin, erityisesti jos järjestelmä rakentuu kyvykkyyksien ja tiukan eristyksen varaan.
2. Kasvanut luotettu laskentapohja (TCB)⌗
Jokainen riippuvuus kasvattaa luotetun laskentapohjan kokoa.
Jos kolmannen osapuolen kirjastoa käytetään ytimessä tai kriittisissä järjestelmäkomponenteissa, sen oikeellisuudesta tulee osa järjestelmän tietoturvatakuita.
Puhdastilakehitys pitää TCB:n:
- pienenä
- hallittuna
- eksplisiittisesti määriteltynä
3. Auditoitavuus ja verifiointi⌗
Kokonaan itse rakennettu järjestelmä voidaan auditoida järjestelmällisesti.
- Kaikki unsafe-koodi voidaan tarkistaa
- Kaikki invariantit voidaan dokumentoida
- Kaikkia rajapintoja voidaan arvioida perustellusti
Tämä on erityisen tärkeää EriXin kaltaiselle järjestelmälle, joka painottaa:
- eksplisiittistä auktoriteettia
- kyvykkyyspohjaista tietoturvaa
- minimaalista ydinsuunnittelua
4. Arkkitehtoninen vapaus⌗
Olemassa olevan koodin uudelleenkäyttö usein rajoittaa suunnittelupäätöksiä.
Esimerkiksi:
- kirjaston käyttöönotto voi pakottaa tietyn API-muodon
- olemassa olevan koodin integrointi voi vaatia yhteensopivuuskerroksia
- vanhat abstraktiot voivat vuotaa uusiin komponentteihin
Puhdastilakehitys antaa järjestelmän muotoutua kokonaan omien periaatteidensa mukaan, ei perittyjen rajoitteiden ohjaamana.
Puhdastila vs. uudelleentoteutus⌗
On tärkeää erottaa puhdastilakehitys yksinkertaisesta uudelleentoteutuksesta.
Puhdastilakehitys ei tarkoita olemassa olevien järjestelmien sokeaa uudelleenkirjoittamista.
Sen sijaan siihen kuuluu:
- julkisten määritysten tutkiminen
- taustalla olevien periaatteiden ymmärtäminen
- uusien toteutusten suunnittelu ensimmäisistä periaatteista lähtien
Esimerkiksi:
- Tiedostojärjestelmä voi noudattaa POSIX-semantiikkaa, mutta olla toteutettu itsenäisesti
- Käynnistyslatain voi noudattaa UEFI-määrityksiä, mutta käyttää mukautettua rakennetta
- C-standardikirjasto voi tarjota saman API:n, mutta olla kirjoitettu kokonaan Rustilla
Tavoitteena on yhteensopivuus siellä, missä sitä tarvitaan, ilman koodin uudelleenkäyttöä.
Puhdastila käytännössä⌗
EriXissä puhdastilarajoitteita sovelletaan koko järjestelmään.
Ei ulkoisia crateja⌗
Vaikka riippuvuuksien uudelleenkäyttö on Rustissa yleistä, EriX välttää ulkoisia crateja.
Sen sijaan se määrittelee sisäisiä uudelleenkäytettäviä komponentteja, kuten:
- muistityökalut
- synkronointiprimitiivit
- kyvykkyysabstraktiot
Sisäiset kirjastot⌗
Uudelleenkäytettävä toiminnallisuus järjestetään sisäisiin crateihin, esimerkiksi:
lib-bootimglib-capabilib-ipc
Nämä kirjastot ovat:
- versioituja
- projektin sisällä hallittuja
- suunniteltuja erityisesti järjestelmän tarpeisiin
Tiukka repositoriorakenne⌗
Jokainen alijärjestelmä on eristetty:
- käynnistyslatain
- ydin
- IPC
- muistinhallinta
- käyttäjätilan palvelut
Tämä pakottaa modulaarisuuteen ja estää piilevää kytkeytymistä.
Toistettavat koonnit⌗
Puhdastilasuunnittelu ulottuu myös koontiprosessiin.
Järjestelmä tavoittelee:
- deterministisiä koonteja
- vähäisiä oletuksia työkaluketjusta
- eksplisiittisiä koontivaiheita
Näin varmistetaan, että artefaktit voidaan tuottaa uudelleen ja verifioida.
Puhdastilakäyttöjärjestelmän hyödyt⌗
1. Koko järjestelmän ymmärrys⌗
Jokainen komponentti tunnetaan ja ymmärretään.
Järjestelmässä ei ole läpinäkymättömiä riippuvuuksia tai piileviä käyttäytymisiä.
2. Vahvempi tietoturvamalli⌗
Kun TCB on pienempi ja hallittu:
- hyökkäyspintoja on vähemmän
- invariantteja on helpompi valvoa
- kyvykkyyspohjainen tietoturva voidaan toteuttaa siististi
3. Parempi tutkimusalusta⌗
EriX ei ole vain käyttöjärjestelmä - se on myös tutkimusalusta.
Puhdastilakehitys mahdollistaa:
- uusien abstraktioiden kokeilun
- suunnittelukompromissien tarkan mittaamisen
- auktoriteetista ja eristyksestä päättelyn selkeästi
4. Pitkän aikavälin ylläpidettävyys⌗
Vaikka työmäärä on aluksi suurempi, puhdastilajärjestelmät voivat olla helpompia ylläpitää:
- ei riippuvuuksien rikkoutumista
- ei seurattavia upstream-muutoksia
- ei versiokonflikteja
Järjestelmä kehittyy omilla ehdoillaan.
Kompromissit ja haasteet⌗
Puhdastilakehitys ei ole ilmaista.
1. Hitaampi kehitys⌗
Kaikki on rakennettava alusta asti:
- peruskirjastot
- ajonaikainen tuki
- järjestelmäpalvelut
Tämä kasvattaa alkuvaiheen työmäärää merkittävästi.
2. Pyörän keksiminen uudelleen⌗
Monet ongelmat on jo ratkaistu muualla.
Niiden uudelleentoteuttaminen vaatii aikaa ja huolellista suunnittelua.
3. Vähemmän oikoteitä⌗
Ei ole mahdollisuutta:
- tuoda nopeasti kirjastoa
- nojata olemassa oleviin ekosysteemeihin
- delegoida monimutkaisuutta ulkoiselle koodille
Kaikki monimutkaisuus on käsiteltävä suoraan.
4. Suurempi suunnitteluvastuu⌗
Jokainen abstraktio on suunniteltava harkitusti.
Virheitä ei voi helposti paikata vaihtamalla riippuvuuksia.
Miksi tämä lähestymistapa sopii EriXille⌗
EriX rakentuu muutaman ydinperiaatteen varaan:
- minimaalinen luotettu laskentapohja
- eksplisiittinen auktoriteetti kyvykkyyksien kautta
- tiukka erottelu ytimen ja käyttäjätilan välillä
- toistettavuus ja determinismi
Puhdastilakehitys tukee kaikkia näitä tavoitteita.
Se varmistaa, että:
- auktoriteetti ei koskaan piiloudu ulkoiseen koodiin
- järjestelmän invariantit pysyvät täysin hallinnassa
- arkkitehtuuri pysyy johdonmukaisena kaikissa komponenteissa
Perusta self-hostingille⌗
Puhdastilasuunnittelu tukee myös pitkän aikavälin tavoitetta self-hostingista.
Jotta EriX voidaan rakentaa EriXin sisällä, järjestelmän on sisällettävä:
- oma työkaluketju
- omat ajonaikaiset kirjastot
- omat järjestelmärajapinnat
Järjestelmän, joka riippuu vahvasti ulkoisista komponenteista, olisi vaikea saavuttaa tällaista riippumattomuuden tasoa.
Katse eteenpäin⌗
Puhdastilakäyttöjärjestelmän suunnittelu on pitkän aikavälin työ. Se vaatii huolellista suunnittelua, kurinalaista toteutusta ja valmiutta rakentaa perustavanlaatuisia komponentteja alusta asti.
Samalla se luo järjestelmän, joka on:
- läpinäkyvä
- hallittu
- syvällisesti ymmärretty
Tulevissa kirjoituksissa siirrymme periaatteista toteutukseen, alkaen varhaisesta käynnistysprosessista ja järjestelmän boot image -formaatin suunnittelusta.