Hlavní navigace

Vlákno názorů ke zprávičce Singularity - nový systém od Microsoftu od Ondra Nekola - ...nevyšel by ze srovnání nejlépe. HURD je jenom...

  • Aktualita je stará, nové názory již nelze přidávat.
  • 8. 11. 2005 8:26

    Ondra Nekola
    Zlatý podporovatel
    ...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).
  • 8. 11. 2005 10:26

    Pedro Alvarez (neregistrovaný)
    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 ;-).
  • 8. 11. 2005 12:21

    Noname (neregistrovaný)
    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
  • 8. 11. 2005 12:46

    Ondra Nekola
    Zlatý podporovatel
    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ů.
  • 8. 11. 2005 19:32

    anonymní
    Microkernel architekture je sloziteji programovatelna nez monolitni (Doporucuju diskusi Torvalds vs. Tanenbaum). Singularity by mela byt cisty mikrokernel, tudiz vic potencialnich chyb. Managed kod pomuze od urcitych chyb (range overflows atp) ale nepomuze prevenci logickych chyb. Prave implementace pres fronty zprav, coz je jeden z hlavnich rysu mikrokernelu vede k vyssi pravdepodobnosti celkem zavaznych chyb - napriklad deadlockum.
    Sam priznavate, ze ve velmi uzke oblasti kod bude unmanaged. Tedy dalsi "vyhoda" pada. Jakmile to tam jednou je - jsou to problemy.
    Ktery system pouziva capabilities? Co takhle systemy s vyssim stupnem zabezpeceni? Napriklad od IBM - AS/400.
    Zkuste mi jmenovat jeden jediny vykonny OS urcen pro servry, ktery by byl mikrokernel. Zatim "uspesne" mikrokernel systemy jsou Mac OSX, ktery ma problemy s thread managementem a u servrovych aplikacich je na tom bidne, nebo QNX ktery je urcen uplne pro jiny segment nez je server nebo desktop.
  • 8. 11. 2005 16:17

    Mikulas Patocka (neregistrovaný)
    "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.
  • 8. 11. 2005 19:38

    Bohdan (neregistrovaný)
    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?