Osobně nemám problém dostat počítač s Windows, klidně bych snesl Firefox, Javu, Adobe Reader, 7Zip, Total Commander apod., i když nic z toho nepoužívám. Ale kdybych dostal man-in-the-middle proxy měnící výsledky vyhledávání, byl bych značně podrážděný.
Ad opruzy s tím podělaným UEFI - jasně, měli bychom na našich 64-bitových strojích nadále provozovat 16-bitový BIOS z IBM PC XT :)
Vzhledem k tomu, ze typicky vyrobce neni schopen dodat ani BIOS bez bugu, nevidim, proc by zavedenim mnohem slozitejsiho UEFI mela vyt situace nejak lepsi.
Jake problemy jako UEFI resi? Ze lidi kradou Widle? Tak to tady urcite nikoho nezajima. Nebo to, ze lidi na stroje instaluji Linux, coz se MS nelibi? A to tak, ze nektere stroje nadobro vytuhnou uz pri bootu live CD. Popravde receno, tech nekolik vyhod UEFI, ktere uvadeji na Wikipedii, opravdu nevypada jako dostatecny duvod k zavedeni UEFI. A ve svetle nevyhod to vypada, ze se zase jedna o nedomysleny nedodelek. Krome toho ta vec slouzi v podstate jen k zahajeni bootu OS, tak nevidim duvody k tomu, aby byla nadale komplikovana, kdyz by mela byt spis zjednodusovana.
UEFI standard napr. riesi rozdelovanie disku vacsieho ako 2TB. GPT particiovanie je prave sucast UEFI a PARTUUID mi pride naozaj rozumne. Dalsia rozumna vec ktoru riesi je "start" bootloaderu. Konecne uz bootloader nemusi byt 16bitovy. Co je v standarde UEFI pekne je este podpora pre bootmenu. Nainstalujete si 10 roznych systemov, kazdy s vlasnym bootloaderom bez toho aby prepisal ten predchadzajuci. A UEFI menu sa pri zapnuti PC spyta co chce spustit. Zial implementacia tohoto je miziva :-( A to je tak asi vsetko v com je UEFI standard oproti BIOS-u lepsi.
Samozrejme ze by to slo navrhnut a aj implementovat jednoduchie :D Predpokladam, ze aspon (jednoduchsi) navrh by zvladol aj priemerny citatel roota...
Vyssie uvedene veci (v predchadzajucom prispevku) su asi jedine pozitiva celeho UEFI. UEFI Secure Boot, UEFI byte code a nativne UEFI ovladace su asi tie najsprostejsie veci v celom standarde... Pevne verim ze vyrobcovia HW nezacnu davat iba UEFI ovladace k novemu HW a delegovat ovladace z kernelu do UEFI...
Ad Jake problemy jako UEFI resi - bootování z partitions větších než 2GB, RTC s podporou časových zón a RTC, lepší API pro firmware rozšiřujících karet, vyšší bezpečnost (SecureBoot), interface pro update firmware atd.
Ad nektere stroje nadobro vytuhnou uz pri bootu live CD - to bude nejspíš ta samá sada problémů, která vedla k bricknutí notebooků Samsung: nekvalitní drivery používající nedokumentovaný interface, které nebyly testované na cílovém HW. To ovšem není problém UEFI.
"While potential conflicts with a kernel module designed to access system features on Samsung laptops were initially blamed (also prompting kernel maintainers to disable the module on UEFI systems as a safety measure), Matthew Garrett uncovered that the bug was actually triggered by storing too many UEFI variables to memory, and that the bug could also be triggered under Windows as well under special conditions. In conclusion, he determined that the offending kernel module had caused kernel message dumps to be written to the firmware, thus triggering the bug."
Vytisknete si to a nalepte na zed alespon jednou v kazde mistnosti.
Jinak byste mohl popsat, jak SecurreBoor zvysuje bezpecnost. To jako ted Widle uz nebudou jak reseto, pokud viry nebudou podepsane od Microsoftu?
Ad vytisknete si to a nalepte na zed alespon jednou v kazde mistnosti - bug Samsungu je o tom, že se brickne systém když se uloží too many UEFI variables to memory. Ovšem modul samsung-laptop je přesně o tom co jsem psal: používal nedokumentovaný interface který nebyl k dispozici při EFI bootu, nebyl testovaný na cílovém HW, a v důsledku toho havaroval. Kdyby Samsung neměl tu chybu v implementaci UEFI, tak by stroj "jenom" zmrznul nebo skončil v reboot loopu. Což je přesně to o čem píšete: nektere stroje nadobro vytuhnou uz pri bootu live CD. Akorát se autoři driverů zrovna nestrefili do něčeho čím by stroj trvale odstavili.
Ad jak SecurreBoor - zajišťuje že nedojde k virtualizaci OS ještě před jeho startem. Z virtualizovaného OS totiž malware nezjistíte, natož abyste ho odstranil. Můžete tvrdit, že je to jen teoretický útok. Ovšem koncept je tu už pár let, a například HDD s nakaženým firmwarem byl ještě před pár týdny také považovaný jen za koncept.
používal nedokumentovaný interface který nebyl k dispozici při EFI bootu, nebyl testovaný na cílovém HW, a v důsledku toho havaroval. Kdyby Samsung neměl tu chybu v implementaci UEFI, tak by stroj "jenom" zmrznul nebo skončil v reboot loopu. Což je přesně to o čem píšete: nektere stroje nadobro vytuhnou uz pri bootu live CD. Akorát se autoři driverů zrovna nestrefili do něčeho čím by stroj trvale odstavili.
Chyba driveru nema zpusobit zniceni HW, pokud k tomu dojde, jedna se o spatny HW.
Jinak me tesi, ze MS tak rezolutne bojuje proti teoretickycm utokum proti Widlochodu. Teoreticke utoky ale ejsou to, co nas na Widlich trapi, ze?
Ad Chyba driveru nema zpusobit zniceni HW - to je pěkná teorie. V praxi můžete pomocí SW zničit spoustu HW, počínaje disketovými mechanikami a konče základními deskami. A i kdybychom se na tomhle neshodli, faktem zůstává, že problémů s drivery je na Linuxu víc než dost. A přesně z důvodů které jsem psal: používají nedokumentované interfacy, a nejsou zkoušené s HW se kterým jsou nakonec provozované.
Ad teoreticke utoky ale ejsou to, co nas na Widlich trapi - současný stav SW průmyslu je mizerný. Díry se objevují v každém produktu, ve kterém je stojí za to hledat. Windows bohužel nejsou výjimkou.
Byly doby, kdy zniceni firmwaru zakladni desky bylo zhola nemozne a zniceni jineho HW dosti nepravdepodobne. Dnes? Zcela bezne.
Diry jsou vsude, nejen na Widlich. Ovsem Widle jaksi byly navrzeny bez nejmensiho ohledu na bezpecnost, jakoby zamerne pro snadne sieni viru. Vsechna zlepseni bezpecnosti jsou pouze soustavou berlicek, ktere tam MS dolepil pozdeji, kdyz by bylo spis namiste cele Widle zahodit a zacit znova a tentokrat pri tom pouzit hlavu.
Firmware je dneska složitější, dělá daleko víc věcí. A protože jsou v něm také chyby, je přepisovatelný. Jinak třeba ty disketové mechaniky, ale i například jukeboxy nebo páskové roboty bylo možné zničit pomocí SW už někdy v devadesátých letech.
Ad Widle jaksi byly navrzeny bez nejmensiho ohledu na bezpecnost, jakoby zamerne pro snadne sieni viru - cenou za vyšší bezpečnost bývá menší použitelnost. Windows jsou navíc díky svému rozšíření velmi oblíbený cíl. Například MacOS je děravý jako řešeto (navíc má Apple zajímavý zvyk v případě problému strčit hlavu do písku), ale protože není tak rozšířený, je pro něj daleko méně malwaru.
A protože jsou v něm také chyby, je přepisovatelný.
Nemyslite, ze nejvetsi chybou je, ze je prepisovatelny? To by mel byt pouze tehdy, kdyz uzivatel da svoleni.
cenou za vyšší bezpečnost bývá menší použitelnost.
To je takovy widlozni paradox. Nulovym zabezpecenim byla pouzitelnost Widli maximalizovana takovym zpusobem, ze Widle byly prakticky nepouzitelne.
Tak pro koho to sakra je? Pro bfu, kterým stejně nepomůže svěcená voda? Pro odborníky, kteří to stejně nemohou použít, a stejně vědí, že hlavní průsery jsou jinde? Nebo pro pár křiklounů na rootovi, kteří mají pocit, že by jim to nějak pomohlo, ale nakonec stejně koupí HW jednou za deset let?
Řeknu ti to jinak: máš alespoň zaplej a nakonfigurování nějakej MAC? Začal jsi už používat nějaké pořádné Full Disc Encryption a ne to šidítko, co jsi míval? Máš nějaký intrusion detection? Poctivě kontroluješ logy? Pokud ještě ne, tak tě tyhle switche zajímat nemusí, to je až to poslední, co by ti pomohlo...
To je zase trochu mino. Ja nejsem ani datacenttrum ani CIA. Nepotrebuji tedy updatovat firmware bez sundavani jumperu a nepotebuji full disc encryption - staci mi siditko, ktere zastavi bezne zlodeje notebooku. Nedelej z toho spionazni film.
Kdyz mas datacentrum, nic ti nebrani do nej strkat poccitace se sundanym jumperem. Stejne tam asi nebudes provozovat Widle a urcite ne browser a MS Utlouk. Nicmene z hlediska BFU je urcite lepsi, kdyz se mu nemuze HW zkurvit pod rukama softwarovou chybou nebo malwarem.
Takže to datacentrum bude mít nepatchovaný HW, protože ty máš pocit, že jim to přinese nějakou výhodu?
A ten BFU, kterému se tak strašně výhodně nemůže HW zkurvit pod rukama... Ten taky bude mít neopatchovaný HW?
A ty to vlastně ani nechceš, takže kdo to sakra zaplatí? Když ani odporníci na rootovi vlastně nechtějí to, co požadují... tak kdo?
Tak jsem snad rekl, ze v datacentru si jumper sundas. Krome toho do datacentra asi nebudes kupovat stejne PC, jako ma Franta, co na tom masti hry nebo dokonce notebook, jako ma Marena, co na tom pise semestralku.
Tak nevim, kde porad vidis problem. Franta i Marena urcite budou tadsi, kdyz se jim PC neslozi, protoze neco prepsalo firmware nebo ze se jim nemuze do firmware vloudit virus. A nevim, k cemu by jim byl opatchovany firmware na jejich PC. Vetsina lidi ani nevi, ze tam takova vec je. Nedavno jsem upgradoval kvuli bugu, kdy v Linuxu nesla grafarna, devet ThinkPadu, kde byl porad puvodni BIOS z prodeje. Proc to nikdo neopatchoval, kdyz se na to vsichni BFU tak tresou?
takze v tom datacentru budes mit neopatchovany HW... chlape, ty jsi material na management.
Ze nevis, k cemu by nekomu bylo patchpovani firmware spis rika neco o tobe, nez o samotnem patchovani. Vygoogli si treba historii 840 EVO, to je takovy pekny, instruktivni pripad.
(Ze se BFU tresou na patchovani tu tvrdil kdo?)
Zhola nemožné? Když selhalo něco při updatu biosu (prováděl se z diskety), tak to v lepším případě znamenalo vydloubnout EEPROM z desky a jít k někomu, kdo měl programátor. V tom horším případě byla EEPROM zapájená a buď se vyhodila celá deska, nebo se to odpájelo, naprogramovalo a připájelo zpátky (nebo se tam při první "opravě" dala patice). Některé desky byly udělány dobře, takže to pak šlo ještě spravit se správným HW přes JTAG nebo vyvedené piny. Jenže dokumentace bylo minimum a JTAG v plenkách. Pro běžného uživatele tak chyba při updatu znamenala smrt desky. Z nějakého důvodu (asi Murphyho zákony) docházelo k výpadkům napájení právě jen když člověk updatoval bios. Těch "bricknutých desek" jsem viděl více než pět a informací o řešení bylo na fidonetu dost, protože to byl častý problém.
Teprve v druhé polovině devadesátých let začlo být běžné, že na desce jsou ty EEPROM dvě a když update jedné selže, tak to bootuje z té druhé.
Nicmene to nemluvite o samovolne zniceni firmware nahodnym prepsanim necim kvuli chybe v OS nebo treba ovladaci. To mluvite o neuspechu akce, kterou jste sam inicioval a ktera se, bohuzel, nepovedla. A i to se da resit, treba tusim na deskach ASUS a asi i jinych stacilo po krachu updatu BIOSu nahrat soubor s BIOSem na CD, prebootovat pocitac a po stisky nejake kombinace klaves se BIOS znovu naprogramoval z CD. Zalezi na tom, jak velky je vyrobce debil a jak moc na zakazniky dlabe.
Ad samovolne zniceni firmware nahodnym prepsanim necim kvuli chybe v OS nebo treba ovladaci - UEFI (konečně) poskytuje i interface pro update firmwaru, a to jak základní desky tak zařízení. Berte to jako další výhodu UEFI. U staršího HW si každý výrobce implementoval update firmware po svém, a pokud chyba OS nebo driveru zasáhla tenhle mechanismus, mohlo to působit problém.
Ad tusim na deskach ASUS a asi i jinych stacilo po krachu updatu BIOSu nahrat soubor s BIOSem na CD, prebootovat pocitac a po stisky nejake kombinace klaves se BIOS znovu naprogramoval z CD - to se typicky realizuje nějakým blokem BIOSu, který je nepřepisovatelný. Samozřejmě pokud potřebujete opravit tenhle blok, tak máte problém.
Ano, UEFI time/rtc functions (ci jak sa to menuje) nie ze nefunguje ale rovno zhodi cely beziaci stroj. Linuxovy kernel to ma uplne zakazne na x86, lebo kernel oopsuje pri volani EFI funkcii (dumpy su aj s lenovo UEFI firmwaru)... Takze aj stroj s UEFI musi pouzivat CMOS rtc. A je tam toho viac. 16 bit BIOS ovladany cez interrupt je za to dlhe obdobie aspon odladeny a ked uz nic ine, tak vracia volanie spat do operacneho systemu.
Ano je to problem s UEFI RTC implementaciou. Dohladajte si o tom viac!
https://lkml.org/lkml/2014/10/3/148
https://bugzilla.kernel.org/show_bug.cgi?id=84241#c21
Z toho co jsem četl jednoznačně nevyplývá, že by šlo o bug v implementaci UEFI RTC. A i kdyby, tak například bugů v implementaci ACPI bylo původně tolik, že MS ignoroval ACPI u všech BIOSů datovaných před January 1, 1999. Přesto se ACPI už léta bez problémů používá.
https://msdn.microsoft.com/en-us/library/windows/hardware/ff540487(v=vs.85).aspx
Jaké problémy UEFI řeší? Problém neposlušných uživatelů, kteří si, hajzlové, chtějí na PC nainstalovat třeba Linux? I to ti parchanti už obešli a umí to... Zbývá jen znepříjemnění instalace na některých laciných hračkách. Trochu chabý výsledek.
GPT není argument. To může umět i BIOS nebo cokoliv jiného.
Po bootloaderu chci, aby zavedl a spustil operační systém nebo umožnil nastavení některých parametrů hardwaru. Nic víc. Pohádky o nutném securebootu si nechte na nějaký motivační meeting u vás na pobočce.
Ad chtějí na PC nainstalovat třeba Linux? I to ti parchanti už obešli a umí to - UEFI boot není nutné nijak obcházet, stačí ho implementovat :). Pokud jde o SecureBoot, tak i to už Linux umí, protože MS podepsal bootloader. Ano, zlý MS se tak moc snaží zabránit instalaci Linuxu, že dokonce podepsal linuxový bootloader, aby komunitě ušetřil nutnost dohadovat se s výrobci HW :)
Ad aby zavedl a spustil operační systém nebo umožnil nastavení některých parametrů hardwaru. Nic víc - firmware musí zvládnout inicializaci HW, boot z řadiče o kterém nic neví, síťový boot, poskytovat interface pro RTC, a v neposlední řadě není špatný nápad mít API pro update firmwaru jak základní desky, tak dalších zařízení. Plus potřebujete interface pro zjišťování informací o konkrétním HW, například pro NUMA je to celkem důležité.
Ad to může umět i BIOS nebo cokoliv jiného - BIOS je fosilie z doby IBM PC XT, která dávno přestala vyhovovat potřebám doby. Samozřejmě je možné vymyslet něco lepšího. Výrobci HW a OS to udělali, a přišli s (U)EFI. Původně pro stroje na platformě IA-64, pro které BIOS jaksi nebyl vhodným firmwarem. Když později hledali cestu vpřed na platformě x86/x64, vzniklo UEFI, dnes používané i na ARMu. Jak se můžete přesvědčit, za UEFI stojí všichni významní výrobci HW.
http://www.uefi.org/members
Pokud se autorům Linuxu UEFI nelíbí, měli se možná přestat utápět ve sporech uvnitř komunity, začít jedním hlasem jednat s výrobci HW, a prosazovat to co chtějí. Od čeho máte komunitu, Linux Foundation, FSF a další, když vás nedovede reprezentovat? Proč se výrobci HW umí dohodnout na dlouhé řadě průmyslových standardů, které tvoří dnešní PC, ale vaše komunita neumí prakticky k ničemu vydat jednotné stanovisko, natož aby ho byla schopná obhajovat a prosazovat?