
Jag studerar informationsteknologi vid Tammerfors universitet. På min fritid bidrar jag till fria och öppna projekt som EriX Project, AES, Cutie Shell Project och Droidian GNU/Linux. Jag är också intresserad av naturliga språk och att lära mig dem.
Du kan hitta mig på GitHub, git.erikinkinen.fi och LinkedIn.
Från firmware till kernel: bootprocessen förklarad
Varje operativsystem börjar innan det verkligen är sig självt. CPU:n startar i en miljö som definieras av plattformen, firmware initialiserar tillräckligt med hårdvara för att ladda den första körbara filen, och den körbara filen förbereder maskinen för kernel. Först när den kedjan har gjort sitt arbete kan operativsystemet börja upprätthålla sina egna regler.
Det är lätt att behandla den tidiga vägen som ren VVS, men bootprocessen är en del av säkerhetsmodellen.
Varför Rust för kernelutveckling
Operativsystem förknippas oftast med C.
Det är begripligt. C är litet, förutsägbart, nära maskinen och historiskt dominerande i kernelarbete. Det ger programmeraren direkt åtkomst till minne, register, layout och anropskonventioner.
Det är exakt sådant en kernel behöver.
Det är också exakt sådant som gör kernels svåra att säkra.
EriX är huvudsakligen skrivet i Rust eftersom projektet byggs kring en central idé:
Auktoritet ska vara explicit.
Det gäller capabilities, boot-handoff-strukturer, IPC-meddelanden, minnesobjekt och enhetsåtkomst.
Den betrodda beräkningsbasen: varför storlek spelar roll
Säkerhetsdiskussioner fokuserar ofta på enskilda buggar:
ett buffertspill ett confused-deputy-fel en okontrollerad parser en väg för privilegieeskalering De buggarna spelar roll, men de är symptom på en djupare fråga:
Hur mycket kod måste vara korrekt för att systemet ska förbli säkert?
Den koden är den betrodda beräkningsbasen, vanligtvis förkortad TCB.
TCB:ns storlek och form avgör hur mycket kod som måste betros, granskas, testas och förstås. Ett system kan ha starka abstraktioner på papperet, men om de abstraktionerna beror på att en stor mängd privilegierad kod beter sig perfekt blir säkerhetsargumentet mycket svagare.
Mikrokärnor kontra monolitiska kärnor: kompromisserna igen
Få debatter inom operativsystemsdesign har pågått lika länge som debatten mellan mikrokärnor och monolitiska kärnor.
På ytan verkar skillnaden enkel:
monolitiska kärnor behåller de flesta operativsystemstjänster i kärnan mikrokärnor flyttar de flesta tjänster till användarrymden I praktiken är kompromissen mer subtil.
Den verkliga frågan är inte om den ena strukturen alltid är snabbare, renare eller säkrare. Den verkliga frågan är var auktoritet, komplexitet, fel och prestandakostnader ska ligga.
Det här inlägget går tillbaka till den kompromissen, förklarar varför många äldre argument om mikrokärnor blev alltför förenklade och visar varför moderna system som EriX gör mikrokärnemodellen praktisk igen.
Att utforma ett renrumsoperativsystem
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 är ett kapabilitetsbaserat operativsystem
Moderna operativsystem upprätthåller säkerhetsgränser mellan processer, filer, enheter och användare. Hur dessa gränser implementeras varierar dock avsevärt mellan olika systemdesigner.
De flesta vanliga operativsystem förlitar sig på identitetsbaserad åtkomstkontroll och globala namnrymder. Kapabilitetsbaserade operativsystem använder ett fundamentalt annorlunda angreppssätt: de representerar auktoritet explicit och gör den till ett förstaklassigt begrepp.
Detta inlägg introducerar kapabilitetssystem, förklarar hur de skiljer sig från traditionella modeller och beskriver varför de är centrala för EriX design.
Varför jag bygger en kapabilitetsbaserad mikrokärna från grunden
Operativsystem hör till den mest komplexa programvara som någonsin byggts. De hanterar minne, schemalägger beräkning, styr hårdvara och upprätthåller säkerhetsgränser som skyddar varje program som körs på en maskin.
Ändå bygger många operativsystem vi förlitar oss på i dag på arkitekturidéer som går flera decennier tillbaka. Även om dessa system är extraordinärt kraftfulla och väl beprövade, bär de också på decennier av ackumulerad komplexitet.
Detta projekt utforskar en annan riktning: att bygga ett modernt, kapabilitetsbaserat operativsystem med mikrokärna från grunden, med starkt fokus på explicit auktoritet, minimal betrodd beräkningsbas (TCB), och strikt separation mellan kärna och användarrymd.