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.

Tämä kirjoitus selittää, mitä TCB tarkoittaa, miksi sen koko vaikuttaa hyökkäyspintaan ja miten EriX pyrkii pitämään luotetun koodin pienenä ja eksplisiittisenä.

Mitä TCB tarkoittaa?⌗

Luotettu laskentapohja on joukko komponentteja, joiden oikeellisuus on välttämätöntä järjestelmän tietoturvaominaisuuksien säilymiselle.

Jos TCB:hen kuuluva komponentti murretaan, järjestelmän tietoturvatakuut eivät välttämättä enää pidä.

Käyttöjärjestelmässä TCB sisältää usein:

  • bootloaderin
  • ytimen
  • etuoikeutetut järjestelmäpalvelut
  • tunnistus- ja valtuutuslogiikan
  • luotettujen käynnistysdatan parserit
  • kryptografisen varmennuskoodin
  • koodin, joka jakaa tai siirtää auktoriteettia

Tarkka TCB riippuu järjestelmän rakenteesta.

Perinteisessä monoliittisessa ytimessä suuri osa ytimestä kuuluu yleensä TCB:hen, koska monet alijärjestelmät suoritetaan täydellä ydinprivilegiolla. Virhe ajurissa, tiedostojärjestelmässä tai verkkopinossa voi muuttua ytimen kompromissiksi.

Mikroydinjärjestelmässä ytimen TCB voi olla pienempi, mutta koko luotettu järjestelmä sisältää edelleen komponentit, jotka jakavat auktoriteettia ja toteuttavat politiikkaa.

Tällä erolla on merkitystä.

Mikroytimet vähentävät koodia, joka toimii täydellä koneauktoriteetilla. Ne eivät tee kaikista käyttäjätilan palveluista automaattisesti epäluotettuja.

Luotettu ei tarkoita turvallista⌗

Sana “luotettu” on helppo ymmärtää väärin.

Luotettu komponentti ei ole komponentti, jonka tiedetään olevan oikein.

Se on komponentti, jonka oikeellisuudesta järjestelmä riippuu.

Tämä on epämukavampi määritelmä, mutta hyödyllinen.

Jos palveluun luotetaan kyvykkyyksien jakamisessa, sen bugi voi myöntää auktoriteettia väärin. Jos parseriin luotetaan suoritettavan kuvan validoinnissa ennen käynnistystä, parserin bugi voi murtaa käynnistysketjun. Jos ytimen syscall-käsittelijään luotetaan endpoint-oikeuksien tarkistamisessa, puuttuva tarkistus voi rikkoa eristyksen.

Luottamus ei ole kehu.

Luottamus on riski.

Tavoitteena ei siis ole nimetä mahdollisimman paljon koodia luotetuksi. Tavoitteena on tehdä luotetusta joukosta mahdollisimman pieni, kapea ja auditoitava.

Miksi koolla on väliä⌗

TCB:n koolla on merkitystä useasta syystä.

1. Enemmän koodia tarkoittaa enemmän bugeja⌗

Kaikessa ohjelmistossa on virheitä.

Kun luotetun koodin määrä kasvaa, myös tietoturvan kannalta merkittävien virheiden todennäköisyys kasvaa. Tämä koskee erityisesti koodia, joka:

  • jäsentää epäluotettavaa syötettä
  • hallitsee muistia
  • käsittelee rinnakkaisuutta
  • tulkitsee oikeuksia
  • kääntää yhden auktoriteettimallin toiseksi

Käyttöjärjestelmät sisältävät kaikkia näitä malleja.

TCB:n pienentäminen ei poista bugeja, mutta se vähentää koodia, jossa bugi voi kompromettoida koko järjestelmän.

2. Enemmän rajapintoja tarkoittaa suurempaa hyökkäyspintaa⌗

Hyökkäyspinta ei ole vain rivimäärä.

Se on myös sisääntulopisteitä.

Jokainen rajapinta luotettuun koodiin on paikka, johon hyökkääjä voi antaa syötettä:

  • syscall-argumentit
  • IPC-viestit
  • käynnistyskuvan metadata
  • ELF-otsakkeet
  • tiedostojärjestelmärakenteet
  • laitekuvaukset
  • keskeytystapahtumat
  • firmwaren antamat taulut

Jokainen rajapinta tarvitsee validoinnin.

Pieni luotettu komponentti huonosti suunnitellulla rajapinnalla voi silti olla vaarallinen. Mutta kun luotettujen rajapintojen määrä kasvaa, validointitaakka kasvaa mukana.

3. Enemmän tilaa vaikeuttaa päättelyä⌗

Tietoturvavirheet eivät usein synny yhdestä puuttuvasta tarkistuksesta, vaan siitä, että tila muuttuu odottamattomassa järjestyksessä.

Esimerkiksi:

  • kyvykkyys kopioidaan ennen oikeuksien kaventamista
  • palvelu käynnistyy ennen kuin sen käynnistyspaketti on täysin validoitu
  • vanha paikallinen slot tulkitaan auktoriteetin todisteeksi
  • laite katsotaan läsnä olevaksi ennen tunnistuksen valmistumista
  • prosessi säilyttää auktoriteetin epäonnistuneen käynnistyspolun jälkeen

Mitä enemmän luotettua muuttuvaa tilaa järjestelmällä on, sitä vaikeampaa on todistaa, että jokainen siirtymä säilyttää tarkoitetut invariantit.

Siksi EriX korostaa determinististä käynnistystä, eksplisiittisiä siirtotietueita ja fail-closed-käyttäytymistä.

4. Enemmän privilegioita tarkoittaa suurempaa vaikutusaluetta⌗

Sama bugi aiheuttaa eri seurauksia riippuen siitä, missä se tapahtuu.

Parserivirhe etuoikeudettomassa työkalussa voi kaataa vain sen työkalun.

Parserivirhe bootloaderissa voi kompromettoida koko järjestelmän ennen ytimen käynnistymistä.

Käyttäjätilan ajurin bugi, jolla on pääsy vain tiettyyn I/O-alueeseen, on vakava. Se ei kuitenkaan ole sama asia kuin bugi ajurissa, joka toimii ytimen sisällä täydellä koneauktoriteetilla.

TCB:n pienentäminen tarkoittaa myös yksittäisten bugien vaikutusalueen pienentämistä.

Ydin on vain osa TCB:tä⌗

On houkuttelevaa sanoa:

TCB on ydin.

Se on yleensä liian yksinkertaista.

Ydin on keskeinen, mutta turvallinen järjestelmä riippuu myös koodista, joka valmistelee ytimen, käynnistää ensimmäisen käyttäjätilatehtävän, määrittelee auktoriteettiformaatit ja jakaa kyvykkyydet.

EriXissä ydin kuuluu eksplisiittisesti TCB:hen.

Se omistaa ytimen kyvykkyystaulut, ajastustilan ja koneen resurssit. Se validoi bootloaderilta ytimelle tulevan handoffin, luo root-tehtävän, hallitsee ytimen perusobjekteja ja tarjoaa arkkitehtuurikohtaiset trap-, syscall- ja keskeytyssisääntulot.

Jos ydin ei pakota kyvykkyystarkistuksia, endpoint-oikeuksia, osoiteavaruusrajoja tai objektien elinkaaria, järjestelmän eristysmalli pettää.

Mutta ydin ei ole koko tarina.

Käynnistyskoodi on myös luotettua⌗

Bootloader suoritetaan ennen ydintä.

Siksi se on tietoturvakriittinen.

EriXissä bootloader vastaa allekirjoitetun boot.img:n lataamisesta ja varmentamisesta, ytimen ja palvelukuvien jäsentämisestä, deterministisen handoff-rakenteen rakentamisesta ja ohjauksen siirtämisestä ytimelle.

Tämä sijoittaa bootloaderin TCB:hen.

Sillä on käynnistyksen aikana firmwaren antama auktoriteetti ja se hallitsee viimeistä hyppyä ytimeen. Sen täytyy käsitellä käynnistysmediaa epäluotettavana, validoida kuvan rakenne ja kryptografinen eheys, hylätä virheelliset ELF-binäärit ja epäonnistua suljetusti epäselvissä tilanteissa.

Jos bootloader hyväksyy muokatun kuvan tai rakentaa epäjohdonmukaisen handoffin, ydin voi aloittaa kompromettoidulta pohjalta.

Siksi käynnistyskoodin pitää olla pientä, tiukkaa ja tylsää.

Parserit voivat olla TCB-rajoja⌗

Parsereita aliarvioidaan usein järjestelmäturvallisuudessa.

Ne sijaitsevat täsmälleen kohdassa, jossa epäluotettavat tavut muuttuvat luotetuksi rakenteeksi.

EriX käsittelee useita parseri- ja ABI-crateja TCB:n osina tai TCB:n läheisinä komponentteina:

  • lib-bootimg jäsentää ja varmentaa boot.img:n rakenteen, hashit ja allekirjoitukset
  • lib-elf validoi ELF64-binäärit ennen kuin bootloader luottaa lataussegmentteihin
  • lib-handoff validoi versioidut handoff-rakenteet käynnistysvaiheiden välillä
  • lib-ipc määrittelee ja validoi IPC-viestien asettelut
  • lib-capabi määrittelee kyvykkyystyypit, oikeudet, slot-vakiot ja siirtokuvaukset

Nämä kirjastot eivät välttämättä omista runtime-kyvykkyyksiä itse.

Se ei tee niistä merkityksettömiä TCB:n kannalta.

Jos lib-bootimg hyväksyy muokatun käynnistyskuvan, bootloader voi luottaa koodiin, joka pitäisi hylätä. Jos lib-elf hyväksyy virheellisen suoritettavan tiedoston, käynnistysketju voi ladata väärät tavut tai luottaa virheellisiin segmenttialueisiin. Jos lib-ipc tulkitsee viestin väärin, operaatio voidaan ymmärtää väärin. Jos lib-capabi määrittelee liian laajan roolipolitiikan, palvelu voi saada auktoriteettia, jota sen ei pitäisi koskaan omistaa.

Puhdas koodi voi silti olla luotettua koodia.

Tärkeää on, että nämä kirjastot ovat kapeita. Ne eivät tee I/O:ta, eivät omista järjestelmäpolitiikkaa ja välttävät ambienttia auktoriteettia. Niiden tehtävä on jäsentää, validoida ja hylätä.

Käyttäjätilan palvelut voivat olla luotettuja komponentteja⌗

Politiikan siirtäminen ytimen ulkopuolelle ei poista politiikkaa.

Se siirtää politiikan käyttäjätilan palveluihin, joissa se voidaan eristää, rajata ja auditoida erikseen.

EriXissä rootd on ensimmäinen politiikkaa kantava käyttäjätilan auktoriteetti. Se validoi kernel-to-root-handoffin, jäsentää boot-konfiguraation, suorittaa käynnistyksen DAG:n ja siirtää vähimmän privilegion kyvykkyydet vaadituille palveluille.

rootd on korkean privilegion komponentti.

Mutta se ei ole ydin.

Tämä ero on tärkeä. rootd:hen luotetaan varhaisen politiikan ja kyvykkyyksien jakelun osalta, mutta se ei toteuta ydinobjekteja eikä omista koneauktoriteettia suoraan. Sen tehtävä on jakaa auktoriteettia eksplisiittisten käynnistyssopimusten mukaan.

Myös muut palvelut ovat omissa luottamusrajoissaan:

  • procd on luotettu prosessien elinkaaren orkestroinnissa
  • deviced on luotettu ajuripolitiikassa ja ajurikyvykkyyksien toimituksessa
  • vfsd on luotettu julkisen tiedostojärjestelmän nimiavaruuden rajana
  • yksityiset tiedostojärjestelmäproviderit ovat luotettuja vain provider-rooliinsa

Tämä ei tee näistä palveluista merkityksettömiä.

Se tekee niiden auktoriteetista kapeampaa kuin täydestä ydinauktoriteetista.

Hyökkäyspinta monoliittisessa mallissa⌗

Monoliittisessa ytimessä monet alijärjestelmät jakavat yhden etuoikeutetun osoiteavaruuden.

Tämä voi tehdä nopeista poluista yksinkertaisia, mutta se luo myös laajan hyökkäyspinnan.

Haavoittuvuus missä tahansa ytimen sisäisessä alijärjestelmässä voi muuttua ydinhaavoittuvuudeksi:

  • virheelliset tiedostojärjestelmämetadatat
  • viallinen verkkopakettien käsittely
  • turvaton ajurikoodi
  • odottamattomat laitekuvaukset
  • kilpailutilanteet jaetussa ydintilassa

Hyökkääjä tarvitsee vain yhden polun etuoikeutettuun koodiin.

Tämä ei tarkoita, etteivät monoliittiset ytimet voisi olla turvallisia. Niitä voidaan koventaa, fuzzata, hiekkalaatikoida ja auditoida laajasti.

Mutta arkkitehtuuri aloittaa suuresta etuoikeutetusta pinnasta.

Tietoturva-argumentin täytyy selittää, miten tämä suuri pinta hallitaan.

Hyökkäyspinta mikroydinmallissa⌗

Mikroydin muuttaa hyökkäyspinnan muotoa.

Ydin tarjoaa edelleen kriittisiä rajapintoja:

  • syscallit
  • IPC:n toimitus
  • ajastus
  • osoiteavaruusoperaatiot
  • kyvykkyysoperaatiot
  • keskeytysten käsittely

Näiden rajapintojen täytyy olla oikein.

Korkeamman tason palvelut eivät kuitenkaan automaattisesti toimi täydellä ydinprivilegiolla. Jos tiedostojärjestelmäprovideri käsittelee virheellistä mediaa, tavoite on, että bugi pysyy providerin auktoriteetin sisällä. Jos ajuri epäonnistuu, tavoite on, että se epäonnistuu vain sillä laiteauktoriteetilla, joka sille annettiin eksplisiittisesti.

Tämä muuttaa yhden suuren etuoikeutetun pinnan useiksi pienemmiksi auktoriteettipinnoiksi.

Se ei ole automaattisesti yksinkertaisempaa.

Se toimii vain, jos rajat ovat tiukkoja ja niiden yli siirretty auktoriteetti on kapeaa.

Miten EriX minimoi TCB:n⌗

EriX pienentää TCB:tä ja hyökkäyspintaa useilla suunnitteluratkaisuilla.

1. Politiikkaminimaalinen ydin⌗

EriXin ydin vastaa mekanismeista, ei järjestelmäpolitiikasta.

Se käsittelee:

  • ytimen perusobjektit
  • kyvykkyyssemantiikan
  • ajastuksen ja tehtävien suorituksen
  • osoiteavaruusprimitiivit
  • IPC:n ja endpoint-dispatchin
  • keskeytys- ja poikkeussisääntulot

Se ei omista:

  • palvelujen käynnistyspolitiikkaa
  • prosessien orkestrointipolitiikkaa
  • tiedostojärjestelmän nimiavaruuspolitiikkaa
  • ajurien aktivointipolitiikkaa
  • korkean tason muistivarauspolitiikkaa

Tämä pitää ytimen keskittyneenä eristyksen pakottamiseen koko järjestelmän muodon päättämisen sijaan.

2. Eksplisiittiset kyvykkyydet ambientin auktoriteetin sijaan⌗

EriX mallintaa auktoriteetin kyvykkyyksinä.

Komponentti voi toimia vain, jos sillä on vaadittavat oikeudet sisältävä kyvykkyys. Ydin validoi kyvykkyysviitteet käytössä, pakottaa endpoint-oikeudet syscall-dispatchissa ja käsittelee siirrot eksplisiittisinä tapahtumina.

Tämä välttää globaalien nimien tai tavanomaisten slot-numeroiden käyttämisen lupina.

Slot-numeron tietäminen ei ole auktoriteettia.

Oikean kyvykkyyden omistaminen paikallisessa CSpacessa on auktoriteettia.

Tämä ero on keskeinen TCB:n pienentämisessä: luotetun koodin ei tarvitse päätellä lupia globaalista tilasta, kun auktoriteetti kulkee eksplisiittisesti.

3. Kapeat kernel-control-endpointit⌗

Vanhemmat käyttöjärjestelmämallit keskittävät usein ohjauksen laajojen etuoikeutettujen rajapintojen taakse.

EriX tekee päinvastoin.

Nykyinen runtime käyttää kapeita kernel-control-endpoint-perheitä tiettyihin tehtäviin:

  • aika
  • keskeytykset
  • hotplug
  • PCI-konfiguraatio
  • konsoli ja framebuffer
  • COM1-I/O
  • i8042-I/O
  • muistin retyping
  • VSpace-kartoitus
  • pagerin vikojen ratkaisu
  • prosessien hallinta
  • ACPI-luvut

Normaali runtime-käynnistys ei anna palveluille yhtä laajaa root-endpointtia kaikkiin ydinoperaatioihin.

Sen sijaan palvelu saa tarvitsemansa endpoint-perheen. timed saa ajan hallinnan. irqd saa keskeytysten hallinnan. drv-serial saa COM1-kohtaisen I/O:n. drv-i8042 saa i8042-kohtaisen I/O:n. drv-acpi saa ACPI-lukuauktoriteetin.

Tämä kaventaa sekä luotettua rajapintaa että väärinkäytön aiheuttamaa vahinkoa.

4. Tarkat käynnistyssopimukset⌗

EriX käsittelee käynnistyksen kyvykkyyssiirtoa sopimuksena, ei ehdotuksena.

Käynnistyskuoret kuvaavat, mitä kyvykkyyksiä palvelun tulee saada, missä niiden tulee näkyä ja mitä oikeuksia niiden tulee kantaa.

Palvelut validoivat oikeasti vastaanottamansa paikalliset slotit ennen valmiuden ilmoittamista. Endpoint-siirrot tarkistetaan lähdeslotin, kohdeslotin, oikeuksien ja odotetun endpoint-lajin perusteella. Tuntemattomat, väärät tai ylimääräiset siirrot hylätään.

Tämä estää yleisen auktoriteettivirheen:

“Slot on varattu, joten sen täytyy olla oikea asia.”

EriXissä slotin varaus yksin ei todista auktoriteettia.

Kyvykkyyden täytyy vastata ilmoitettua auktoriteetin muotoa.

5. Vaiheistettu prosessien luonti⌗

Prosessien luonti on korkean riskin operaatio, koska siinä yhdistyvät suoritus, osoiteavaruudet, endpointit ja alkuauktoriteetti.

EriX ohjaa runtime-prosessien luonnin vaiheistetun lapsiprosessin luonnin kautta vanhan suoran luontioperaation sijaan.

Vaiheistettu kulku on eksplisiittinen:

  1. luo vaiheistettu lapsi
  2. vastaanota install grant ja lapsen endpoint-alias
  3. asenna ilmoitettu käynnistyskyvykkyyspaketti
  4. käynnistä prosessi vasta, kun täyttö on valmis

Ydin kieltää prosessin käynnistyksen niin kauan kuin elävät install grantit kohdistuvat kyseiseen lapsivaiheeseen.

Näin osittain täytetyt prosessit eivät tule ajettaviksi epäselvässä auktoriteettitilassa.

6. Roolikohtainen ajuriauktoriteetti⌗

Ajurit ovat suuri käyttöjärjestelmäriskin lähde.

EriX ei käsittele kaikkea laitteiston hallintaa yhtenä laajana lupana.

Ajuriauktoriteetti on roolikohtaista:

  • drv-serial saa vain COM1-I/O-auktoriteetin
  • drv-i8042 saa vain i8042-I/O-auktoriteetin
  • drv-acpi saa ACPI-lukuauktoriteetin
  • probed saa PCI-konfiguraation lukuauktoriteetin
  • drv-virtio-block saa validoidun laiteframen yleisen muistiauktoriteetin sijaan

deviced hallitsee ajuripolitiikkaa, mutta se ei anna jokaiselle ajurille yleistä laitehallintakyvykkyyttä. Se käyttää eksplisiittistä käynnistyskyvykkyyksien asennusta ja roolikohtaisia auktoriteettipintoja.

Tämä rajoittaa ajuribugien TCB-vaikutusta.

7. Laitemuisti on erillinen kyvykkyystyyppi⌗

Laitemuisti on vaarallista, koska se voi vaikuttaa suoraan laitteiston tilaan.

EriX erottaa laitemuistin tavallisesta RAM:ista CAP_TYPE_DEVICE_FRAME:llä.

Tallennuspolku voi johtaa BAR-taustaisen MMIO-framen deviced:lle, ja deviced voi asentaa vain tämän johdetun laiteframen ajurin käynnistyspakettiin.

Tätä laiteframea ei käsitellä tavallisena varattavana muistina.

Tämä on tärkeää, koska laitemuistin sekoittaminen tavallisiin frameihin laajentaisi auktoriteettimallia ja vaikeuttaisi muistiturvallisuudesta päättelyä.

8. Puhdastilariippuvuudet⌗

Riippuvuudet voivat kasvattaa TCB:tä hiljaa.

Jos luotettu koodi riippuu yleiskäyttöisestä ulkoisesta kirjastosta, järjestelmä voi periä:

  • koodipolkuja, joita se ei tarvitse
  • oletuksia, jotka eivät sovi käyttöjärjestelmään
  • liian sallivaa parserikäyttäytymistä
  • päivitys- ja toimitusketjuriskiä

EriX välttää kolmannen osapuolen crateja ja toteuttaa kriittiset kirjastonsa projektin sisällä.

Tämä lisää toteutustyötä, mutta pitää luottamusrajan näkyvänä. Kun parseri, ABI-crate tai kryptografinen apuri on osa käynnistys- tai auktoriteettipolkua, se on osa järjestelmän katselmointipintaa.

9. Fail-closed-käyttäytyminen⌗

Pieni TCB ei riitä, jos virheet ovat epäselviä.

EriX pyrkii tekemään tietoturvaherkistä virheistä eksplisiittisiä ja terminaalisia:

  • virheellinen boot-handoff pysäyttää käynnistyksen
  • tukemattomat versiot hylätään
  • virheellinen käynnistysauktoriteetti estää valmiuden
  • väärät endpoint-lajit epäonnistuvat validoinnissa
  • vaaditun palvelun käynnistysvirhe pysäyttää etenemisen
  • käynnistyksen jälkeiset virheet käynnistävät fail-closed-teardownin

Suljetusti epäonnistuminen on tärkeää, koska palautumisheuristiikat muuttuvat usein piilotetuksi politiikaksi.

Piilotettu politiikka laajentaa järjestelmän luotettua käyttäytymistä.

Pienempi ei tarkoita triviaalia⌗

TCB:n pienentäminen ei tee järjestelmäsuunnittelusta helppoa.

Se tekee siitä usein eksplisiittisempää.

Sen sijaan, että kaikki logiikka sijoitettaisiin yhteen etuoikeutettuun osoiteavaruuteen, järjestelmän on määriteltävä:

  • mikä komponentti omistaa minkäkin päätöksen
  • mitä auktoriteettia kukin komponentti saa
  • miten auktoriteetti siirretään
  • miten virheet raportoidaan
  • miten osittainen käynnistys siivotaan
  • miten vanhat kyvykkyydet mitätöidään tai pudotetaan

Tämä on enemmän työtä alussa.

Mutta tuloksena on järjestelmä, jonka tietoturva-argumenttia on helpompi tarkastaa.

Kysymys muuttuu muotoon:

Minkä komponentin täytyy olla luotettu tätä tiettyä ominaisuutta varten?

Se on parempi kysymys kuin:

Onko koko ydin oikein?

Käytännöllinen näkymä EriXin TCB:hen⌗

Käytännöllinen näkymä EriXin TCB:hen on kerroksittainen.

Alimpana on käynnistysketju:

  • bootloader
  • käynnistyskuvan varmennus
  • lib-bootimg:n read/verify-polku
  • ELF-jäsennys
  • handoff-validointi

Sitten ydin:

  • kyvykkyysobjektit
  • CSpace- ja VSpace-pakotus
  • IPC ja endpoint-oikeudet
  • ajastus ja trap-käsittely
  • keskeytysten toimitus

Sitten varhainen luotettu käyttäjätila:

  • rootd käynnistyspolitiikkaan ja kyvykkyyksien jakoon
  • procd prosessien elinkaareen
  • deviced ajuripolitiikkaan
  • valitut ABI- ja validointikirjastot, joita palvelut jakavat

Sitten kapeammat luotetut palvelut:

  • tiedostojärjestelmän nimiavaruuden välitys vfsd:ssä
  • yksityiset backend-providerit
  • syöte-, konsoli-, loki-, lohko-, aika- ja keskeytyspalvelut

Kaikki nämä komponentit eivät ole yhtä etuoikeutettuja.

Se on koko pointti.

EriX pyrkii välttämään yhden tasaisen luotetun maailman. Sen sijaan jokaisen komponentin tulisi olla luotettu vain dokumentoidussa roolissaan ja vain niillä kyvykkyyksillä, jotka sille on eksplisiittisesti annettu.

Katse eteenpäin⌗

TCB-keskustelu johtaa luontevasti toteutuskieleen.

Jos luotetun koodin täytyy olla pientä, eksplisiittistä ja auditoitavaa, muistiturvallisuudella on merkitystä. Niin on myös unsafe-rajoilla, parserien oikeellisuudella, datan asettelulla ja kurinalaisuudella, jota laitteiston lähellä työskentely vaatii.

Seuraava kirjoitus tarkastelee, miksi EriX on kirjoitettu pääasiassa Rustilla, mitä Rust ratkaisee ja ei ratkaise ydinkehityksessä, ja miten se vertautuu perinteiseen C-lähestymistapaan järjestelmäohjelmoinnissa.