Yderst pålideligt operativsystem

Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den version , der blev gennemgået den 19. juni 2013; checks kræver 7 redigeringer .

Extremely Reliable Operating System (EROS) er et mandatbaseret operativsystem designet til at opfylde sikkerheds- og pålidelighedskravene for aktive systemer . Brugere af aktive systemer kan indtaste og udføre vilkårlig kode til enhver tid , herunder fejlagtig eller endda ondsindet kode . Aktive systemer er delte platforme , der samtidig skal understøtte potentielt konkurrerende brugere på samme maskine på samme tid.

Sådan virker det

Fordi aktive systemer udfører brugerleveret kode, kan du ikke stole for meget på systemkantbeskyttelse for at forhindre konsekvenserne af ondsindet kode . I tilfælde af udførelse af en sådan kode giver EROS garantier for både sikkerhed og systemydelse. Programmer , der udfører ondsindet kode (såsom virus ) kan ikke skade andre brugere eller systemet som helhed og kan ikke bruge de tilladelser, der er givet til en bruger, til at skade andre dele af brugerens miljø .

Projekthistorie

EROS- projektet begyndte som en referenceimplementering af KeyKOS , et operativsystem skabt af Norm Hardy og kolleger til IBM System/370 . Hovedbidraget fra EROS er formelt at teste nogle af de grundlæggende sikkerhedsegenskaber i en arkitektur , konstruktion af implementeringen af ​​specifikke ydeevnekarakteristika. Disse beskyttelses- og ydeevneegenskaber blev opnået på to måder.

For det første fulgte udviklerne strenge principper , når de oprettede systemets grundlæggende arkitektur . I tilfælde af at den planlagte mulighed for systemet var i modstrid med beskyttelsesprincippet, blev det øjeblikkeligt opgivet. Resultatet er en lille, internt konsistent arkitektur, hvis adfærd er veldefineret, og som fører til en grundig og pålidelig implementering. For det andet, de førende arkitekter af det system, der bruges til at designe processorer. Dette gjorde det muligt for os at undgå en vis form for abstraktion, som har en tendens til at adskille moderne operativsystemer, og at designe systemet, så det direkte svarer til de funktioner, som moderne hardwareimplementeringer tilbyder; ved konvertering af abstraktioner falder ydeevnen meget lidt.

Jeremy Salzer og Michael Schroeder udviklede mange af EROS-designprincipperne fra Multics- projektet og integrerede andre ud fra deres erfaring i andre projekter. Konsistens i ydeevne og systemarkitektur blev opnået udelukkende ved at finde de bedste måder at nøjagtigt implementere disse principper ned til nuancerne, uden at kompromittere ydeevnen.

Udviklerne af EROS overholdt strengt principperne for arkitektur, da de designede EROS / KeyKOS ] af følgende tre grunde. Du skal være sikker på, at systemet fungerer og vide, hvorfor det virker. Hvis det for hvert stykke systemkode er umuligt at sige, hvad det vejledende princip eller obligatoriske begrænsning er, der garanterer korrekthed, er det meget vanskeligt at nå dette mål. Kommunikation af denne art er også nødvendig for at vurdere systemets ydeevne med en høj grad af sikkerhed. Det blev antaget, at en klar arkitektur i sig selv ville bidrage til en højtydende implementering. Udførte præstationstest bekræftede rigtigheden af ​​sådanne antagelser.

EROS kernearkitektur

Den mest direkte indflydelse af designprincipper i EROS har påvirket strukturen og implementeringen af ​​kernen. I nogle tilfælde førte streng overholdelse af designprincipper til uventede arkitektoniske beslutninger.

Sikker genstart

På sikre systemer skal du sikre dig, at systemet er i en ensartet og sikker tilstand efter en genstart. De fleste operativsystemer har et indledende sæt af processer, der er specifikt skabt af kernen. Disse processer udfører et konsistenstjek, begrænser deres beføjelser til dem, der antages i stabil tilstand, og starter derefter resten af ​​programmerne på systemet. I denne situation opstår to problemer. Konsistenskontrol er heuristisk, hvilket gør det vanskeligt at fastslå korrektheden. For eksempel skal Unix fsck-kommandoen bestemme, hvilke filer der skal fjernes, og hvilke der skal beholdes uden at vide, hvordan filerne er relateret. Derfor kan tilstanden af ​​adgangskodefiler og grupper være inkonsistente med hinanden. De indledende processer opnår deres autoritet gennem midler, der går ud over de sædvanlige mekanismer for tildeling eller uddelegering af autoritet. Udviklere bør skabe specifikke midler til at demonstrere, at systemet administrerer og reducerer disse tilladelser korrekt. Kompleksiteten af ​​disse værktøjer kan sammenlignes med kompleksiteten af ​​midlerne til at sikre korrektheden af ​​resten af ​​systemet.

I EROS løses begge problemer ved at bruge et system til implementering af checkpoints ved udførelse af transaktioner. Dette system laver periodisk rationelle asynkrone snapshots af hele maskinens tilstand, kontrollerer konsistensen af ​​denne tilstand og skriver den derefter som en del af en enkelt disktransaktion. Da systemet understøtter transaktionsmekanismen som helhed, er situationen med inkonsistens i hele systemet umulig. Ved genstart gendanner systemet blot den sidst gennemførte transaktion .

Stateless Kernel

EROS  er en tilstandsløs kerne - systemets udførelsestilstand ligger i brugerreserveret hukommelse. Acceptabel kerneydelse opnås ved at cache denne tilstand. Caching - arkitekturen understøtter checkpoint-mekanismen og giver kontrol over afhængigheder i kernen. For at sikre, at brugerreserveret hukommelse altid giver de korrekte værdier, når den er markeret, skal kernen være i stand til at gendanne sin tilstand efter behov. Disse afhængigheder tilbyder en form for selvkontrol. Kernen kan nogle gange sammenligne dens cachelagrede tilstand med brugertilstanden for at opdage uoverensstemmelser, og derved forhindre ukorrekt tilstand i at blive skrevet til disken.

EROS åbner ikke hukommelseskortfragmenter, da dette ville overtræde kernens princip om ikke-bevarende tilstand. I stedet kræver EROS , at applikationen nøjagtigt reserverer alle de fragmenter, der udgør hukommelseskortstrukturen. Applikationen reserverer eksplicit (normalt med en fejlbehandler på brugerniveau) hver node og side i det adresseområde. Kernen opretter hukommelses- og hardware-mapping-tabellerne ved at pakke denne struktur og cache resultaterne i hardware-mapping-tabellerne.

Se også

Links