LibOS: Revolutionen inden for Operativsystemer

Effektiviteten af operativsystemer (OS) har altid været i søgelyset for systemforskere, lige siden Dijkstras banebrydende THE-multiprogrammeringssystem i de tidlige 60'ere. Men i den moderne tidsalder, hvor datacentre håndterer enorme arbejdsbelastninger, er jagten på ydeevne blevet mere intens end nogensinde. Selvom vi ofte tænker på operativsystemet som et lag mellem vores applikationer og hardwaren, er denne opfattelse ikke helt præcis. Applikationskode kører direkte på CPU'en uden indblanding fra operativsystemet, som kun griber ind ved administrative hændelser som procesafbrydelser eller adgang til delte ressourcer som fil- og netværks-I/O. Man kunne derfor undre sig over, hvor meget af OS-koden der egentlig bliver eksekveret. Undersøgelser viser, at i datacentre bruges omkring 15-20% af CPU-cyklusserne i OS-kernen. Dette skyldes, at de fleste arbejdsbelastninger er I/O-intensive og belaster adskillige OS-komponenter, fra enhedsdrivere til netværksstakke og planlægningsalgoritmer. Denne konstante byrde har ført til udviklingen af en radikalt anderledes arkitektur: Biblioteksoperativsystemet, eller LibOS.

De iboende problemer i traditionelle operativsystemer

Selvom hver enkelt del af et traditionelt operativsystem normalt er højt optimeret, lider systemet som helhed under flere grundlæggende designproblemer, der skaber flaskehalse for ydeevnen. Disse problemer stammer direkte fra de designprincipper, der ligger til grund for traditionelle operativsystemer.

1. Beskyttelse (Protection)

For at sikre systemets stabilitet og sikkerhed kører operativsystemets kerne i en privilegeret tilstand (kernel mode), mens applikationer kører i en ikke-privilegeret tilstand (user mode). Hver gang en applikation har brug for en OS-tjeneste, f.eks. at læse en fil, skal der ske et 'context switch' fra user mode til kernel mode og tilbage igen. Denne overgang er omkostningsfuld, da den involverer at gemme CPU'ens nuværende tilstand, skifte beskyttelsesdomæne og indlæse kernens tilstand. For I/O-tunge applikationer, der konstant foretager systemkald, akkumuleres denne overhead og bliver en betydelig faktor for den samlede ydeevne.

2. Modularitet (Modularity)

Moderne operativsystemer er ekstremt komplekse og bygget op af mange abstraktionslag for at tæmme denne kompleksitet. For eksempel går en netværkspakke gennem flere lag – fra den fysiske enhedsdriver op gennem protokolstakken (TCP/IP) til socket-laget, før den når applikationen. Hvert lag kan kræve ekstra datakopiering og medføre andre omkostninger forbundet med softwareindkapsling. Selvom denne modularitet gør systemet lettere at vedligeholde og udvikle, skaber det en lang og ineffektiv eksekveringssti for data.

3. Generalitet (Generality)

Operativsystemet er designet til at være en generel platform, der kan køre tusindvis af forskellige applikationer. Derfor tilbyder det generelle mekanismer og politikker, der sjældent er optimale for en specifik applikation. For eksempel bruger et OS en generel sidestruktur (page table structure), som måske ikke er den mest effektive for en applikation med et unikt hukommelsesmønster. Applikationen har ingen mulighed for at tilpasse disse grundlæggende OS-abstraktioner for at forbedre sin egen ydeevne. Den er fanget af de generelle løsninger, som OS'et påtvinger den.

Introduktion til Exokernel og LibOS

For at overvinde disse begrænsninger kræves et radikalt anderledes OS-design. I et skelsættende forskningsarbejde introducerede Dawson Engler et al. en exokernel OS-arkitektur. Idéen er at 'udrydde alle OS-abstraktioner' fra kernen og i stedet give applikationsudviklere magten til at bygge deres egne på en sikker og effektiv måde.

Disse applikationsspecifikke OS-tjenester indkapsles i et biblioteksoperativsystem (LibOS), der kører i user mode som en del af applikationens eget adresserum. Der er ingen deling af LibOS'er mellem applikationer. Nedenunder ligger en privilegeret exokernel-kerne, der kun tilbyder et minimalistisk sæt hardware-grænseflader til at multiplekse hardwaren mellem applikationer. Exokernelen allokerer ressourcer til applikationerne og håndhæver derefter disse allokeringer under kørsel med minimal overhead. Al administration inden for de tildelte ressourcer – såsom virtuel hukommelse, procesplanlægning, filsystem og netværksstak – overlades til det applikationsspecifikke LibOS. Resultatet er en utroligt udvidelsesvenlig OS-arkitektur, der minimerer eller helt eliminerer de ydelsesmæssige ulemper ved traditionelle OS-designs.

Den nye generation af LibOS'er: Moderne Anvendelsesområder

Selvom exokernel-konceptet stammer fra 1995, er det mere relevant i dag end nogensinde før. Fremkomsten af højhastigheds-I/O-enheder med lav latens flytter ydeevneflaskehalsene fra hardwaren til softwarelagene i operativsystemet. Dette motiverer en mere direkte adgang til hardwaren for applikationer. Her er nogle af de mest almindelige anvendelsesområder for LibOS i dag:

Højtydende servere

Moderne eksempler som IX og Arrakis implementerer exokernel-principper på moderne hardware med virtualiseringssupport. Ved at udnytte avancerede QoS- og isolationsmekanismer i moderne I/O-enheder kan OS-logikken helt fjernes fra dataplanen. Biblioteker som DPDK (Data Plane Development Kit) giver applikationer direkte adgang til netværkskortets (NIC) I/O-buffere, hvilket fuldstændig omgår operativsystemet og er afgørende for ydeevnekritiske applikationer som f.eks. pakkebehandling.

Letvægtsvirtualisering (Unikernels)

En unikernel er et design, hvor et højt specialiseret LibOS kompileres sammen med en applikation. Dette skaber en enkelt, selvstændig eksekverbar fil, der kan køre direkte på bare-metal hardware eller en virtuel maskine. Unikernels er ekstremt lette, indeholder kun den absolut nødvendige OS-logik og er ideelle til applikationer, der kræver stærk isolation som virtuelle maskiner, men med radikalt hurtigere implementeringstid og et meget lille hukommelsesaftryk.

Kompatibilitetslag

Visse sikre eksekveringsmiljøer, såsom Intel Software Guard Extensions (SGX), tillader ikke applikationer at foretage systemkald. Det betyder, at umodificerede applikationer ikke kan køre i disse såkaldte 'enclaves'. Her kommer LibOS'er som SCONE og Graphene-SGX ind i billedet. De skaber et kompatibilitetslag inde i enklaven, der implementerer de manglende OS-grænseflader, enten ved at håndtere dem internt (f.eks. trådplanlægning i user-level) eller ved transparent at videresende systemkald til det rigtige OS uden for enklaven.

Accelererede systemer

I systemer med hardwareacceleratorer som GPU'er kan LibOS'er give enorme fordele. Biblioteker som GPUfs og GPUnet implementerer filsystem- og netværkslag direkte på GPU'en. Dette giver tusindvis af GPU-tråde mulighed for at foretage I/O-kald direkte, hvilket eliminerer den CPU-kontrol-overhead, der normalt er forbundet med at koordinere opgaver mellem CPU og GPU. Målet er at skabe en accelerator-centreret OS-arkitektur, hvor hver accelerator har sit eget enhedsoptimerede LibOS.

Sammenligning: Traditionelt OS vs. LibOS

For at give et klart overblik over forskellene, er her en tabel, der sammenligner de to arkitekturer:

Udfordringer og Hardwareimplikationer

Indførelsen af LibOS'er er drevet af behovet for maksimal effektivitet og er blevet praktisk mulig takket være hardware-virtualiseringssupport i både CPU'er og I/O-enheder. Men der er stadig udfordringer og mangler i hardwaren:

• Begrænset virtualiseringssupport: For visse enheder, som GPU'er og lagerenheder, er virtualiseringssupporten stadig ret begrænset, hvilket gør direkte, uprivilegeret adgang vanskelig.
• Multiplexing-overhead: Hardware-support til lav-overhead multiplexing mellem flere applikationer på højhastighedsenheder er et komplekst problem.
• Skalerbarhed: Hardware-virtualisering i I/O-enheder skalerer ikke godt i dag. For eksempel understøtter netværkskort typisk kun i omegnen af hundrede virtuelle funktioner, hvilket begrænser antallet af LibOS'er, der kan køre samtidigt.
• Sikkerhedsrisici: Når upålidelig brugerkode får direkte adgang til virtuelle enheder, udsættes de for angreb, som et traditionelt operativsystem normalt ville blokere.
• Ansvar flyttes til hardware: Nogle af OS'ets traditionelle ansvarsområder, såsom ydeevneisolation og ressourcepartitionering, skal flyttes ind i hardwaren. Det er dog ofte uklart, hvordan man bevarer fleksibiliteten fra de oprindelige softwaremekanismer.

Ofte Stillede Spørgsmål (FAQ)

Hvad er et LibOS helt præcist?

Et LibOS er et operativsystem, hvor OS-tjenester (som filsystem, netværksstak osv.) er implementeret som biblioteker, der linkes direkte ind i en applikation og kører i applikationens eget user space. Dette står i kontrast til et traditionelt OS, hvor disse tjenester leveres af en delt, central kerne.

Er et LibOS mere sikkert end et traditionelt OS?

Det er et komplekst spørgsmål. På den ene side reducerer LibOS-arkitekturen angrebsfladen, da hver applikation er isoleret med sit eget OS. På den anden side giver det applikationer mere direkte adgang til hardware, hvilket kan åbne for nye sårbarheder, hvis hardware-isolationsmekanismerne ikke er robuste nok. Sikkerheden afhænger i høj grad af exokernelens evne til at håndhæve ressourcegrænser.

Hvorfor betragtes en userspace-netværksstak som et LibOS?

En userspace-netværksstak som DPDK er et perfekt eksempel på et LibOS-princip. Den omgår kernens netværksstak og giver applikationen direkte kontrol over netværkskortet. Det er et 'bibliotek', der leverer OS-lignende netværkstjenester i user space, hvilket giver hurtigere udvikling, letvægtsvirtualisering og fuld kontrol over netværksmiljøet.

Kan jeg bruge et LibOS på min personlige computer?

I teorien, ja, men i praksis er LibOS-arkitekturer primært designet og anvendt i specialiserede miljøer som højtydende datacentre, cloud-infrastruktur og indlejrede systemer, hvor ydeevne og tilpasning er vigtigere end den generelle anvendelighed, man forventer af et desktop-operativsystem som Windows, macOS eller Linux.

Konklusion

LibOS'er repræsenterer et spændende og kraftfuldt alternativ til traditionelle operativsystemer, især i en verden, der kræver stadig højere ydeevne fra servere og specialiseret hardware. Ved at flytte OS-abstraktioner fra den privilegerede kerne ud til applikationerne selv, løser de mange af de iboende ydelsesproblemer, der plager monolitiske systemer. Selvom de stiller nye krav til hardwarearkitekturen og introducerer nye sikkerhedsudfordringer, er de en drivkraft for innovation og en mulighed for at genoverveje det fundamentale forhold mellem software og hardware. Fremtiden for højtydende computing kan meget vel ligge i denne applikationscentrerede tilgang til systemdesign.