. 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í.Portál AbcLinuxu, 21. května 2025 05:12
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.
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.
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.
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.
Tiskni
Sdílej:
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.
20.11.2005 22:34
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
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
20.11.2005 22:37
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
).
22.11.2005 20:40
Yin | skóre: 39
| blog: Yinotopia
| Slovesnko, Košice
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ť.
21.11.2005 13:52
elviin | skóre: 29
| blog: elviin
| Plzeň-Praha
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.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.