Ha többet megtud arról, hogy az operációs rendszerek és az általuk futtatott hardverek hogyan működnek és hogyan működnek egymással, meglepődhet, ha látja, hogy furcsaságnak vagy „erőforrások” kihasználatlannak tűnik. Miért van az, hogy? A mai SuperUser Q & A bejegyzés megválaszolja az olvasó kíváncsi kérdését.
A mai Kérdések és válaszok ülés a SuperUser jóvoltából érkezik hozzánk - a Stack Exchange alosztályához, amely a Q & A webhelyek közösségvezérelt csoportosulása.
Fotó jóvoltából Lemsipmatt (Flickr) .
A kérdés
A SuperUser olvasó, az AdHominem tudni akarja, miért használják az x86-os CPU-k a négyből csak kettőt:
Csak Linux és Windows alapú x86 rendszerek használhatók 0 gyűrű kernel módhoz és 3. gyűrű felhasználói módhoz. Miért különböztetik meg a processzorok négy különféle gyűrűt, ha mindenesetre végül csak kettőt használják? Megváltozott ez az AMD64 architektúrával?
Miért használják az x86-os CPU-k a négyből csak kettőt?
A válasz
Jamie Hanrahan, a SuperUser közreműködője válaszol ránk:
Két fő oka van.
Az első az, hogy bár az x86-os CPU-k valóban négy gyűrűs memóriavédelmet kínálnak, az általuk kínált védelem részletessége csak szegmensenkénti szintű. Vagyis minden szegmens beállítható egy adott csengésre (privilégium szintre), más védelemmel együtt, például az íráskor letiltva. De nem áll rendelkezésre annyi szegmensleíró. A legtöbb operációs rendszer sokkal finomabb memóriavédelmet szeretne, például… az egyes oldalakhoz.
Tehát adja meg az oldaltáblázat-alapú védelmet. A legtöbb, ha nem az összes, a modern x86 operációs rendszerek többé-kevésbé figyelmen kívül hagyják a szegmentálási mechanizmust (amennyire csak tudják), és az oldaltáblázat bejegyzéseinek alacsony rendű bitjeiből elérhető védelemre támaszkodnak. Ezek egyikét „privilegizált” bitnek nevezzük. Ez a bit vezérli, hogy a processzornak az egyik „privilegizált” szinten kell-e lennie az oldal eléréséhez. A „kiváltságos” szintek PL 0, 1 és 2 . De ez csak egy bit, így az oldalankénti védelem szintjén a rendelkezésre álló „módok” száma csak kettő: egy oldal nem privilegizált módból érhető el, vagy sem. Ezért csak két gyűrű. Ahhoz, hogy minden oldalhoz négy lehetséges csengetés legyen, minden egyes oldaltáblázat bejegyzésénél két védelmi bitnek kell lennie ahhoz, hogy a négy lehetséges gyűrűszám egyikét kódolja (csakúgy, mint a szegmensleírókat). De nem teszik.
A másik ok az operációs rendszer hordozhatóságának vágya. Ez nem csak az x86-ról szól; A Unix azt tanította nekünk, hogy az operációs rendszer viszonylag hordozható lehet több processzor architektúra számára, és ez jó dolog. Néhány processzor csak két gyűrűt támogat. Azáltal, hogy az architektúra több csengésétől sem függ, az operációs rendszer megvalósítói hordozhatóbbá tették az operációs rendszereket.
Van egy harmadik ok, amely a Windows NT fejlesztésére jellemző. Az NT tervezőinek (David Cutler és csapata, akiket a Microsoft a DEC Western Region Labs munkatársaitól vett fel) széleskörű tapasztalataik voltak a VMS-ről; valójában Cutler és néhányan mások a VMS eredeti tervezői között voltak. És a VAX processzor, amelyhez a VMS-t tervezték, valóban négy gyűrűvel rendelkezik (a VMS négy gyűrűt használ).
De a VMS-ben futó alkatrészek 1. és 2. gyűrű (Record Management Services, illetve a CLI) kimaradtak az NT tervezéséből. 2. gyűrű a VMS-ben valójában nem az operációs rendszerek biztonságáról szólt, hanem arról, hogy a felhasználó CLI-környezetét egyik programról a másikra meg kellett őrizni, és a Windows nem rendelkezett ezzel a koncepcióval; a CLI rendes folyamatként fut. Ami a VMS-t illeti 1. gyűrű , az RMS kód 1. gyűrű be kellett hívnia 0 gyűrű meglehetősen gyakran, és a gyűrű átmenetek drágák. Sokkal hatékonyabbnak bizonyult, ha csak elmentünk 0 gyűrű és végezz vele inkább, mint sok 0 gyűrű átmenetek a 1. gyűrű kód (megint nem az, hogy az NT-nek amúgy is van valami RMS-je).
Ami azt jelenti, hogy az x86 miért hajtott végre négy gyűrűt, miközben az operációs rendszerek nem használták őket, az x86-nál jóval későbbi operációs rendszerekről beszél. Az x86 sok programozási funkcióját jóval azelőtt dolgozták ki, hogy az NT vagy az igazi Unix-ish kernelek megvalósultak volna rajta, és nem igazán tudták, hogy az operációs rendszer mit fog használni. Az x86-os lapozásig csak akkor valósíthattuk meg a valódi Unix-ish vagy VMS-szerű kerneleket.
A modern x86 operációs rendszerek nemcsak hogy nagyrészt figyelmen kívül hagyják a szegmentálást (csak beállították a C, D és S szegmenseket 0 bázis címmel és 4 GB méretben; az F és G szegmenseket néha az operációs rendszer legfontosabb adatstruktúráira mutatják ), nagyrészt figyelmen kívül hagyják a „feladatállapot-szegmenseket” is. A TSS mechanizmust egyértelműen a szál kontextusváltására tervezték, de kiderült, hogy túl sok mellékhatása van, ezért a modern x86 operációs rendszerek „kézzel” csinálják. Az x86 NT hardveres feladatait egyetlen alkalommal, amikor valóban kivételes körülmények között változtatja meg, például kettős hiba kivételével.
Az x64 architektúrát tekintve sok ilyen használaton kívüli funkció kimaradt. Becsületükre szolgál, hogy az AMD valóban beszélt az operációs rendszer kernel csapataival, és megkérdezte, hogy mire van szükségük az x86-tól, mire nincs szükségük, vagy mi nem, és mit szeretnének hozzáadni. Az x64-en lévő szegmensek csak úgynevezett vestigiális formában léteznek, a feladatállapot-váltás nem létezik stb., És az operációs rendszerek továbbra is csak két gyűrűt használnak.
Van valami hozzáfűzhető a magyarázathoz? Hang a kommentekben. Szeretne további válaszokat olvasni más, hozzáértő Stack Exchange-felhasználóktól? Nézze meg a teljes vitafonalat itt .
