Singularity

20.11.2005 21:55 | Přečteno: 1640× | Plané filozofování | poslední úprava: 20.1.2006 14:53

Před pár týdny jsem narazil na zprávu o novém operačním systému od Microsoft Research jménem Singularity. Mělo to být něco nového, bezpečného, navrženého od nuly, žádné tweaklé Windows ani Unix. Neodolal jsem a vrhl jsem se na studium příslušného reportu. Předpokládám, že ne každý má dost času a chuti číst takové reporty, tak přináším pár postřehů.

Cílem projektu bylo navrhnout operační systém nezatížený jakoukoliv zpětnou kompatibilitou s primárním ohledem na bezpečnost a spolehlivost (tedy ne rychlost) a vytvořit zkušební implementaci. To vše se zapojením moderních vysokoúrovňových jazyků ala C# a jeho nadstaveb.

Architektura

Celý návrh Singularity stojí na pojmu SIP - software isolated process (dále budu slovo proces používat jako synonymum k SIP). Tak jako v každém jiném operačním systému i v Singularity jsou procesy. Tyto procesy je vhodné od sebe nějak izolovat. Singularity, na rozdíl od všech běžných OS, k tomu nepoužívá hardwarové prostředky, ale softwarové.

Proces je obvykle vymezen svými daty (adresový prostor) a vlákny provádění. K SIP se ale neváže adresový prostor, nýbrž objektový prostor. V Singularity může více procesů sdílet jeden adresový prostor a přesto můžou být na sobě dokonale nezávislé.

Jednotlivé procesy jsou z datového hlediska množiny objektů (jak je známe z Javy a C#) a není dovoleno, aby objekty z různých procesů na sebe měly reference. Jednotlivé procesy spolu samozřejmě můžou komunikovat, ale jenom pomocí přesně a předem definovaných rozhraní, které exportují. Tato rozhraní kromě samotných formátů zpráv (jméno metody a typy parametrů) obsahují i jakýsi protokol (diagram přechodů).

contract C1 {
  in message Request(int x) requires x>0;
  out message Reply(int y);
  out message Error();

  state Start: Request?
               -> (Reply! or Error!)
               -> Start;
}

Zde například proces specifikuje, že přijímá zprávu Request s parametrem celým kladným číslem. Na tuto zprávu odpoví (viz vyřičník) zprávou Reply nebo Error a po odpovědi je znovu schopen přijmout zprávu Request (stav Start).

Kromě posílání zpráv si procesy můžou vyměňovat data pomocí tzv. kanálů s využitím tzv. exchange heap.

Na procesy jsou kladeny taky další omezení, proces například nemůže dynamicky nahrát a spustit další kód. Dokonce je zakázána i reflexe (vytváření nového kódu za běhu). Jenže dynamické nahrávání kódu je potřeba, moderní software je jím prolezlý, třeba rozšížení Firefoxu. Vyřešeno je to jednoduše, každé rozšíření musí mít vlastní SIP. Tím je zabráněno tomu, aby nějaké agresivní rozšíření manipulovalo s daty mateřského programu způsobem, který by vedl k jeho pádu.

Skoro každá prkotina má vlastní SIP. Počínaje ovladači a pluginama konče. Díky tomu, že jednotlivé SIP jsou od sebe dokonale odděleny, je možné je po havárii jednoduše odstřelovat, uvolňovat jejich prostředky a taky dělat restarty.

Implementace

Paměťníci možná vzpomenou na "operační systémy" jako Windows 3.x, kde se do jisté míry spoléhalo na ukázněnost procesů a jako celek to nefungovalo. Jak jsou tedy procesy k ukázněnosti přinuceny v Singularity? Singularity je napsán v Sing#, což je rozšíření Spec#, což je rozšíření C# . A pokud budete psát vlastní program je potřeba ho napsat ve vysokoúrovňovém jazyku překládaném do MSIL. A kód v MSIL umí Singularity ověřit na korektnost. Je to jasné, v Javě taky nemůžete přímo pracovat s pamětí.

Aby nedošlo k dojmu, že všechno musí být v C#. Každý proces může používat rozdílné runtime knihovny, mít jiný algoritmus pro GC. Jen musí dodržovat pravidla systému.

V singularity teoreticky (snad) může běžet i nativní stroják procesoru, ale ten musí být vyprodukován "důvěryhodným" překladačem.

Softwarová izolace má taky ten zajímavý důsledek, že v Singularity na x86 běží všechen software s úrovní oprávnění ring 0. Tato nezávislost na bezpečnostních vlastnostech hardwaru je zároveň příležitost pro vývoj nového hardwaru. Například místo ochrany paměti vytvořit akcelerovaný GC.

Pomalý mikrokernel?

Singularity je mikrokernel. Dole je pár řádek v assembleru a céčku a vše ostatní (včetně ovladačů) je v C# a potomcích. Zdá se, že by to mělo být pomalé. Kupodivu není.

Mikrokernel jako například HURD je pomalý zčásti proto, že komponenty běží v oddělených adresových prostorech. Kvůli každé operaci (kopírování dat) se pak musí typicky několikrát přepínant kontext procesu a taky se čeká, než se proces naplánuje.

V Singularity běžící na 64bitové architektuře můžou všechny procesy běžet v jednom adresovém prostoru. Exchange heap pak má mechanismy, jak předat data bez zbytečného kopírování.

Součástí reportu jsou i benchmarky. Singularity vychází ze srovnání s Windows XP, Linuxem a FreeBSD se ctí. Koncepce samotná má z výkonového hlediska IMHO šanci obstát.

       

Anketa

Komentáře

[petr_p]

Tak nejak tomu nerozumim. Pokud vsechny procesy bezi v ring 0, co jim zabrani v tom, aby cetly/zapisovali po cele pameti?

Nebo snad cela ochrana spociva v tom, ze procesy se nespousi v binarnim kodu a nevykonava je procesor, ale jsou interpretovany jadrem a ze diky objektovosti neni mozne z jednoho obektu psat do jineho? V tom pripade se ale jedna o normalni virtualni stroj, ktery hlida kazdy proces vzlast (narozdil od dnesnich VM, kdy se emuluje jen OS).

[petr_p]

s/zapisovali/zapisovaly/

[paskma]

Procesy vykonává normálně procesor. Po prohnání JITerem je z toho stroják. Ale je zaručeno, že ten stroják je korektní, protože vypadne z verifikovaného MSIL.

[XXX]

To by mě zajímalo kdopak tento článek napsal!

[VícNežNic]

Jeho autor.

[XXX]

já jsem se s prvu sek. neviděl jsem na něj přímo odkaz...

[XXX]

Defakto by to byl další uzavřený systém s ještě větší uzavřeností než je tedka windows. Tedy na otázku zdali bych takový systém chtěl musím odpovědět NE.

[paskma]

Doufám, že to byla jen trefná ironie.

Ale pokud ne:

Jde o idee, ne o licenci. Je to normální aplikovaný výzkum a můžem být rádi, že ho MS dělá. Unix byl od počátku taky komerční, Linux je jen jeho otevřená reimplementace.

[XXX]

vylož si jak chceš...

[Warp]

Po dlhej dobe je to "revolucna myslienka" a dokonca od MS, to si zasluzi ocenit.

P.S. Dobry Blog

[paskma]

No tak samozřejmě to z něčeho vychází, na konci toho reportu jsou četné reference. Třeba na jNode, a jiné podobné projekty. Revoluční to samo o sobě není, ale je hezké, že mají funkční implementaci.

[Luboš Doležel (Doli)]

Singularity vychází ze srovnání s Windows XP, Linuxem a FreeBSD se ctí.

Osobně bych to nazval tragédie, ale to záleží na úhlu pohledu

[Luk]

V té zprávě jsou zajímavé ještě další informace (už se tu o tom psalo dříve, ale připomenu to) - a sice porovnání rychlosti/náročnosti operací na různých OS, včetně Linuxu a Windows. A naměřené hodnoty odpovídají tomu, jak to subjektivně vnímám při běžné práci (takže mě potěšilo, že to i tak naměřili v MS ).

[Tomáš]

Může mi autor vysvětlit, proč dáva do jedný ankety dvě otázky? Jinak článek pěkný.

[paskma]

Ano, uznávám, jsou to dvě různé věci. Ale to druhé je snad u rozumných lidí implikace prvního. (Bavíme se o ideách, ne o konkrétní implementaci).

[Yin]

IMHO anketa nemá zmysel. Ani takáto architektúra nemôže nijak ovlyvniť užívateľovú prácu a jeho pohľad na... jeho tupý pohľad na obrazovku :D. Samozrejme, pokiaľ výrobca nenasadí ďalšoiu marketingovú taktiku (premakanejšiu než pro jeho produkt) a kopletne nezmení UI.

IMHO syngularity je len čiena diera, nič viac. Ten projekt nie je zameraný na stabilitu, ale na nekompatibilitu. O multiplatformových aplikáciách sa tu ani nemôžeme baviť.

[podlesh]

Onen report jsem četl (tedy, jen to opravdu zajímavé) a skutečně se mi to líbí. Pokusů o takové OS již bylo několik, ale je vidět že se vývoj skutečně hýbe dopředu.

Velmi dobrá je ta myšlenka definice protokolů. Možná se to na první pohled nezdá, ale pár let jsem nad tím uvažoval a nic kloudného mě nenapadlo, toto je velice dobré a robustní řešení.

[elviin]

Jen bych upozornil na existujici, funkcni, komercni POSIX mikrokernel QNX Neutrino.

a neco z jejich stranek:

The QNX Neutrino microkernel implements the core POSIX features used in embedded realtime systems, along with the fundamental QNX Neutrino message-passing services. The POSIX features that aren't implemented in the microkernel (file and device I/O, for example) are provided by optional processes and shared libraries.

Architecturally, the OS addresses the context-switch performance issue first. In fact, threads and processes provide nearly identical context-switch performance numbers. QNX Neutrino's process-switch times are faster than UNIX thread-switch times. As a result, QNX Neutrino threads don't need to be used to solve the IPC performance problem; instead, they're a tool for achieving greater concurrency within application and server processes.