Singularity - nový systém od Microsoftu

...nevyšel by ze srovnání nejlépe. HURD je jenom pokus postavit POSIX nad jiným jádrem, které shodou okolností umí pár věcí z toho, co Singularity. (A je to pokus docela neúspěšný, minimálně z hlediska nasazení. To, že však jde *NIX postavit nad MACHem už ukázal NeXT a dnes to předvádí Apple.) Také se zdá, že Singularity pracuje na zcela odlišné úrovni abstrakce (ocituju-li z jejich zprávy SIPs are closed object spaces, not address spaces.)
Singularity jde, jak se zdá z uvolněných informací, notně dále - staví na jazycích s managovaným kódem a JIT kompilací. Díky tomu má podstatně větší potenciál pro vývoj software s méně chybami než jazyky postavené na makroassemblerech C a C++. Podle všeho si dali docela záležet na podpoře bezpečného programování a bezpečnosti (bohužel se asi nedočkáme capabilities, ale i tak mají imho šanci být o řád bezpečnější než současné Windows a *NIXy).
Jsem docela zvědavý, kam to povede, některé aspekty mne odrazují (A process cannot dynamically load or generate code. ), ale zatím to vypadá fain...

Mimochodem - pokud někdo hledá open source konkurenci, tak nejbližším podobným projektem je pravděpodobně jNode. Do praxe asi nejvíce zasáhne Sun a jeho Isolations API (JSR 121).

Nesrovnávám a ani nechci, pouze jsem chtěl poukázat na podobnost filozofie (mikrokernel).

A že je HURD neúspěšný přeci neznamená, že nelze srovnávat ;-).

Docela by mne zajimalo, jakou vyhodu ma Singularity v oblasi "Díky tomu má podstatně větší potenciál pro vývoj software " nez normalni OS s JVM.

Pisete o managed codu, ale jaksi zapominate na moznost pousteni unmanaged codu, ktera se v tom systemu velmi pravdepodobne objevi.

Dale by mne zajimalo, jak muze byt system bez capabilities radove bezpecnejsi nez system s capabilities.

No a v neposledni rade se muzeme podivat na mikrokernel architekturu, ktera se zatim nikdy neprosadila - vzdy byla pomalejsi. Tenhle system je v plenkach a hodne funkcionality neni implementovano, tudiz rychly muze byt. Az bude vyvoj u konce, tak rychlostni testy budou znacne odlisne. Staci se podivat na MACH a tu bolest pri thread managementu

Singularity bude mít výhodu v tom, že tam nebude ten "normální OS", typicky těžko laděný a plný bugů. A JVM s ním bude srovnatelná, až budou izolace (tuším, že JSR 121). Právě izolace si, pokud se nemýlím, vybrali za jeden z cílů vývojáři jNode.
Unmanaged kód se neobjeví (tedy až na velmi úzkou oblast). Code in Singularity is either verified or trusted. Verified code's type and memory safety is checked by a compiler. Unverifiable code must be trusted by the system and is limited to the hardware abstraction layer (HAL), kernel, and parts of the run-time system.
Který systém dnes používá capabilities? Maximum, na které se zmohli vývojáři různých dostupných OS je ACL. Ta bezpečnost, o které jsem mluvil bude vycházet z toho, že se používá managed kód a odpadne tak mnoho ze starých známých problémů.
Mikrokernelová architektura je v praxi používána v systémech, které vycházejí z NeXT STEPu, těch po světě běží dost možná i víc, než Linuxů.

Ani ten výkon nemusí být zlý:
http://blogs.zdnet.com/Murphy/index.php?p=459

Musím si v klidu to PDF prostudovat do detailů...

"Dale by mne zajimalo, jak muze byt system bez capabilities radove
bezpecnejsi nez system s capabilities."

Ono plati zasadni pravidlo --- pridavani bezpecnostnich
featur nezvysuje bezpecnost.

Napr. linux kernel 2.2 mel v sobe diru, ktera se dala pouzit
k ziskani roota, a tato dira vznikla prave kvuli capabilities.
--- pridanim bezpecnostnich featur zvysis pravdepodobnost
vyskytu bugu v nektere z nich, a tim snizis bezpecnost.

Jinak spousta capabilities jsou proste security-through-obscurity
--- kdyz utocnik ziska danou capability, tak muze stejne
ziskat neomezena prava, ale ma to tezsi. Priklad:

CAP_SYS_PTRACE --- utocnik muze modifikovat libovolny proces
vlastneny rootem a nechat ho udelat co chce
CAP_SYS_RAWIO --- utocnik pristoupi na port harddisku a
zapise si na filesystem co chce (eventualne muze pres dma
cist/zapisovat pamet)
CAP_CHOWN --- muze zapisovat do libovolneho souboru a nejakeho
daemona pak donuti, co dela
CAP_DAC_OVERRIDE --- totez
CAP_IPC_OWNER --- muze modifikovat sdilenou pamet a ziskat
kontrolu nad libovolnym procesem, co ji pouziva
CAP_MKNOD --- vyrobi si node treba na /dev/hda a pak si do
nej zapise, co bude chtit
CAP_SETUID --- ziska libovolny uid (treba root)
CAP_SETGID --- ziska libovolny gid
CAP_SYS_ADMIN --- namountuje si filesystem s inodou popisujici
block device a pres nej muze neomezene pristupovat na disk
CAP_SYS_CHROOT --- udela hard-link na suid program do adresare,
do ktereho se bude chrootovat, ale podstrci mu vlastni .so
knihovny.

Hnáno ad absurdum nepotřebujeme ani ACL nebo rwx práva...

To ale popisujete linuxove capabilities, ktere maji s pravymi capabilities spolecny jen nazev. Viz http://en.wikipedia.org/wiki/Capability-based_security

To urcite muze, ale vemte si pokud zakazete capabilities pro roota. Dokud neziska capabilities, nemuze se systemem nic moc delat. Bez capabilities pokud ziskate roota, jste kral.

Jinak se slozitosti samozrejme roste moznost chyb, ale vemte svuj argument do extremu. S jakymi featurama OS bychom dosahli nejbezpecnejsiho OS?

apokalypsa?? :)

Neee, cerna dira;)