Jokainen käyttöjärjestelmä alkaa ennen kuin se on kunnolla oma itsensä. CPU käynnistyy alustan määrittelemässä ympäristössä, firmware alustaa riittävästi laitteistoa ensimmäisen suoritettavan ohjelman lataamiseksi, ja tuo ohjelma valmistelee koneen ydintä varten. Vasta kun tämä ketju on tehnyt työnsä, käyttöjärjestelmä voi alkaa panna täytäntöön omia sääntöjään. Tuo varhainen polku on helppo nähdä pelkkänä putkituksena, mutta käynnistysprosessi on osa turvallisuusmallia. EriXissä boot on ensimmäinen kohta, jossa epäluotettavista tavuista tulee luotettua suoritusta, ja se on myös ensimmäinen kohta, jossa koneen auktoriteetti käännetään eksplisiittiseksi rakenteeksi: varmennetuiksi imageiksi, muistikartoiksi, moduulideskriptoreiksi, entry-osoitteiksi, framebuffer-metadataksi, ACPI-osoittimiksi ja lopulta ytimen objekteiksi.

Käyttöjärjestelmät yhdistetään yleensä C:hen. Tämä yhteys on ymmärrettävä. C on pieni, ennustettava, lähellä konetta ja historiallisesti hallitseva kieli ydintyössä. Se antaa ohjelmoijalle suoran pääsyn muistiin, rekistereihin, layouteihin ja kutsukonventioihin. Juuri näitä ydin tarvitsee. Ne ovat myös juuri niitä asioita, jotka tekevät ytimistä vaikeita turvata. EriX on kirjoitettu pääosin Rustilla, koska projekti rakentuu yhden keskeisen ajatuksen ympärille: Auktoriteetin pitää olla eksplisiittistä. Tämä koskee kyvykkyyksiä, käynnistyksen handoff-rakenteita, IPC-viestejä, muistiobjekteja ja laitepääsyä. Se koskee myös toteutuskieltä.

Tietoturvakeskustelut keskittyvät usein yksittäisiin virheisiin: puskurin ylivuotoon confused deputy -ongelmaan tarkistamattomaan parseriin privilegioiden nostopolkuun Nämä virheet ovat tärkeitä, mutta ne ovat oireita syvemmästä kysymyksestä: Kuinka suuren osan koodista täytyy olla oikein, jotta järjestelmä pysyy turvallisena? Tämä koodi on luotettu laskentapohja, yleensä lyhennettynä TCB. TCB:n koko ja muoto määräävät, kuinka paljon koodia täytyy luottaa, auditoida, testata ja ymmärtää. Järjestelmällä voi olla paperilla vahvat abstraktiot, mutta jos ne riippuvat suuresta määrästä täydellisesti toimivaa etuoikeutettua koodia, tietoturva-argumentti heikkenee.

Harva käyttöjärjestelmäsuunnittelun keskustelu on jatkunut yhtä pitkään kuin keskustelu mikroytimistä ja monoliittisista ytimistä. Pintatasolla ero näyttää yksinkertaiselta: monoliittiset ytimet pitävät suurimman osan käyttöjärjestelmäpalveluista ytimen sisällä mikroytimet siirtävät suurimman osan palveluista käyttäjätilaan Käytännössä kompromissi on hienovaraisempi. Todellinen kysymys ei ole, onko toinen rakenne aina nopeampi, siistimpi tai turvallisempi. Todellinen kysymys on, missä auktoriteetin, monimutkaisuuden, vikojen ja suorituskykykustannusten pitäisi sijaita. Tämä kirjoitus tarkastelee tätä kompromissia uudelleen, selittää miksi monet vanhat mikroytimiä koskevat argumentit yksinkertaistettiin liikaa ja näyttää, miksi EriXin kaltaiset modernit järjestelmät tekevät mikroydinmallista jälleen käytännöllisen.

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.

Modernit käyttöjärjestelmät valvovat prosessien, tiedostojen, laitteiden ja käyttäjien välisiä turvallisuusrajoja. Tapa, jolla nämä rajat toteutetaan, vaihtelee kuitenkin merkittävästi järjestelmien suunnittelussa. Useimmat valtavirran käyttöjärjestelmät nojaavat identiteettipohjaiseen pääsynhallintaan ja globaaleihin nimiavaruuksiin. Kyvykkyyspohjaiset käyttöjärjestelmät omaksuvat perustavanlaatuisesti toisen lähestymistavan: ne esittävät auktoriteetin eksplisiittisesti ja tekevät siitä ensiluokkaisen käsitteen. Tämä kirjoitus esittelee kyvykkyysjärjestelmiä, selittää, miten ne eroavat perinteisistä ratkaisuista, ja hahmottelee, miksi ne ovat keskeisiä EriXin suunnittelulle. Ongelma: ympäristöauktoriteetti Perinteisissä järjestelmissä prosesseilla on usein pääsy resursseihin ympäristöauktoriteetin kautta.

Käyttöjärjestelmät ovat ohjelmistojen monimutkaisimpia kokonaisuuksia. Ne hallitsevat muistia, ajoittavat laskentaa, ohjaavat laitteistoa ja valvovat suojausrajoja, jotka suojaavat jokaista koneella ajettavaa sovellusta. Silti monet nykyisin käyttämämme käyttöjärjestelmät perustuvat arkkitehtonisiin ideoihin, jotka ovat peräisin vuosikymmenten takaa. Nämä järjestelmät ovat erittäin tehokkaita ja taistelussa testattuja, mutta niihin on myös kertynyt vuosikymmenten monimutkaisuus. Tämä projekti tutkii toista suuntaa: rakennetaan moderni, kyvykkyyspohjainen mikroytimeen perustuva käyttöjärjestelmä alusta asti, vahvalla painotuksella eksplisiittiseen auktoriteettiin, minimaaliseen luotettuun laskentapohjaan (TCB) ja tiukkaan erotteluun ytimen ja käyttäjätilan välillä.