Vlákno názorů k článku Děravý Intel Management Engine lze nahradit minimalistickým Linuxem a Go od Lael Ophir - Takže děravý firmware částečně necháme na místě, a...

Takže děravý firmware částečně necháme na místě, a částečně ho nahradíme pomocí Linuxu? Samotný kernel Linuxu měl loni 217 zranitelností, letos už 407 (z toho 167 z kategorii Code Execution), a to ještě není konec roku. Podotýkám že je to opravdu jen kernel, jehož API (syscalls) mají cca 300 funkcí, nic jiného, ani glibc.

Není trochu šílené nahradit firmware - který má občas nějakou díru - pomocí Linuxu, který má těch děr stovky ročně? Když máte díru v hrnci, tak ho přece nebudete nahrazovat pomocí cedníku.

Navíc ten firmware v těch strojích něco dělá. Stará se o inicializaci každého kusu HW, řízení režimů procesoru, uspávání, probouzení, řízení ventilátorů, vzdálený shutdown, boot a reboot, emulaci klávesnice a myši pro OS bez podpory USB, bootování ze sítě, bootování z disků, vzdálený přístup ke konzoli (keyboard, video, mouse), přesměrování disků atd. Chápu že Google na těch pár modelech serverových desek nemusí tyhle věci nijak pálit, i když třeba možnost jen s přístupem na remote management nainstalovat OS, bez toho aby člověk strčil nohu do serverovny, by mohla potěšit i Google. Dále chápu že Google neřeší nějaké notebooky a jejich power management, a nakonec ho nemusí trápit ani ty stovky zranitelností ročně, protože na těch počítačích jsou to "jenom" naše osobní data. Ale co zbytek světa?

Podle mě bude řešením spíš opravit stávající chyby a víc dohlížet na výrobce. To ovšem bude znamenat vyšší cenu. On je ten problém mimo jiné důsledkem toho, že výrobci díky tlaku na cenu a rychlost (obojí dělá radost zákazníkům) nemají čas se pořádně věnovat firmwaru. A asi by se vyplatil nějaký tvrdší certifikační program, jehož podmínkou by byla podpora HW od výrobce po spoustu let.

Ad Zranitelnosti jsou hlavne v driverech - Máte k tomu nějaká čísla? Co jsem se koukal, tak mi nepřišlo, že by zranitelnosti byly hlavně v driverech. Navíc firmwre musí zajistit inicializaci HW, a musí uživateli poskytnout prostředí, což dneska i u BIOSu bývá GUI. Takže stejně potřebujete spoustu driverů, včetně USB, HID a nějaké grafiky (UEFI implementuje Graphics Output Protocol).

Ad Ja nechci mit SW, ktery bude naslouchat na siti i kdyz je pocitac vypnuty - Když máte server na druhém konci světa, tak je celkem strategické mít nějaký BMC. Díky němu můžete mimo jiné počítač vzdáleně zapnout, nainstalovat OS bez toho abyste fyzicky připojoval instalační médium, provést tvrdý reboot, vidět konzoli a používat vzdáleně klávesnici a myš.

Ad Bez reseni ze strany OS power management nefunguje. - Bez podpory ze strany firmwaru také ne.

Ad Kdyz jsou tam zadni vratka nebo diry, tak to zvladne i Putin, Trump, nejakej cinan nebo treba severokorejec, ktery na to prisel. To by si pomohli. - A ona jsou tam zadní vrátka?

Ad Google to prave trapi, jinak by to neresil. - Google je autor nejděravějšího OS na světě, Android je naprostá bezpečnostní katastrofa. Myslíte že je dobré dát Googlu šanci, aby svoje děravé příšernosti nacpal na další miliardu strojů? Podle mě by to byla velká chyba.

jsu, jo? :P

Pradon, mělo bejt jsi.

https://www.spiria.com/sites/default/files/blog/troll-alert.png

K poctu a zavaznosti zranitelnosti Linuxoveho kernelu v tomto kontexte: Ono si ten zoznam code execution vulnerabilities treba aj poriadne pozriet. Da sa z neho velmi rychlo zistit, ze code execution chyby v kerneli samotnom (kernel core & surroundings) su dokopy asi 4. Za zvysok mozu device drivery, ktorych zdrojovy kod bol commitnuty do kernelu. Zdrojovy kod kernelu naozaj nie je len tych 300 syscallov, bootloader a obrazok tucniaka na terminali pocas bootu. Prve a najdolezitejsie je, ze Linux pouzity ako nahrada FW nema dovod na tieto zariadenia sahat a teda nemusi mat prikompilovane prakticky ziadne ovladace zariadeni. Za inicializaciu ovladacov zodpoveda operacny system a FW musi mat iba minimalnu infrastrukturu k tomu, aby vedel zariadenia vyenumerovat. K tomu zrejme bude potrebny iba driver pre PCI-E zbernicu. Ak vobec. Druhy postreh k tym chybam: su to ovladace zariadeni prevazne pritomnych iba na SoC pouzivanych v mobiloch, iba par z nich sa tykalo PC class HW. Postreh treti: predpokladam, ze prevaznu vacsinu toho kodu napisali vyvojari vendorov daneho HW (aby nad tym slo spustit Android). Je blahove predpokladat, ze ti vyvojari budu radovo (horsi/lepsi) ako vyvojari, ktori pisu kod do FW inych druhov zariadeni. Kvalita toho kodu bude +- rovnaka ako kod vo FW alebo (podpisanych, alebo nepodpisanych) ovladacoch. Alebo aj horsia, pretoze uplny humac si musia nechat pre closedsource, Linuxovy kernel este aku-taku uroven ma a Torvalds nastastie nema problem niekomu znadat ak sa pokusi dnu dostat nieco, co uz lezie cez ciaru. Postreh piaty: ze tam tie chyby su ukazuje, ze open source nie je nepriestrelny a da sa donho prepasovat umyselne alebo neumyselne problem. Closed source, kde oci k review je radovo menej na tom bude radovo horsie (a to mozem potvrdit, kolkokrat na review v uz zrevieovanom kode nachadzam detske chyby) - ktora korporatna code review ma viac ako 10tich reviewerov? Dve denne na celej planete?

No a teraz k tomu zvysku. Ze zranitelnosti firmware nie su zverejnovane/nachad­zane neznamena, ze tam nie su. To mate ako s testovanim. Testovanie (a test driven development) je velmi dobre na dokazovanie toho, ze v kode su chyby. Ale zlyhava (bez ohladu na to, ako dobre alebo podla akej metodologie sa to bude robit) v dokazovani toho, ze v kode ziadne chyby nie su. Len preto, ze o niecom neviete nemozete prehlasit, ze to nie je.

Co sa tyka inicializacie HW a role FW v tomto procese, tak sa obavam, ze je velmi obmedzena. Je to mozne velmi lahko dokazat sporom: Ak by FW mal byt zodpovedny za inicializaciu kazdeho kusu HW co sa do zariadenia strci do takej urovne, ze o nom nieco velmi specialne musi vediet, nebolo by mozne zobrat nahodnu sietovku alebo nahodny usb dongle a strcit ho len tak do pocitaca. FW v PC hraje velmi obmedzenu rolu pri inicializacii akehokolvek zariadenia. Asi nie vacsiu ako rolu postara - poskytuje unifikovane rozhranie (ACPI) ktorym sa moze operacny system dohodnut so zariadenim, ako budu nasledne komunikovat a ako bude zariadenie pristupovat k zdrojom systemu. Ziadna raketova veda, nahradenim closed source FW sa nestane, ze magicky pride uplne vsetok HW o funkcionalitu. Samozrejme je ale nutne podpodovat tie uplne najesencialnejsie veci "z opacnej strany". Co viem, tak v Core Boote sa ACPI ignorovalo a pouzival sa miesto toho podstatne lepsie postaveny a sirsie akceptovany OpenFirmware interface. Sice to s widlama nefunguje, ale koho by to trapilo, ze?

Power management riesi v prevaznej vacsine zasa operacny system, pretoze len ten vie, kolko prace pocitac v skutocnosti ma. Je mozne, ze niektore casti ACPI ide virtualizovat, ale pokial viem, tak povodnym ucelom ACPI bolo vytvorit HW nezavislu platformu, ktorou FW moze OS oznamit ako sa naraba s HW kvoli dosiahnutiu nejakej konkretnej cinnosti a OS si potom tieto cinnosti robi sam a FW sa mu do toho nestara. Je to zbytocne pomale a obmedzuje to operacny system v architekture (co je dovod preco zakapal PM BIOS).

K tym sluzbam, ktore firmware poskytuje: to ma dva problemy. Poprve charakter sluzieb. Vacsina z nich (remote shutdown a spol) ide na akomkolvek aspon trocha stabilnom systeme spravit bez nutnosti mat uberlayer. Proste sa ide do systemu lognut a bud ho rebootnut, alebo vypnut. KVM je tiez obezlicka, ktora sa objavila v dobach, ked boli remote access schopnosti windowsu takmer na bode mrazu a nejakym podivnym sposobom dodnes nevymrela. Podruhe: kolko percent pouzivatelov naozaj tuto funkcionalitu potrebuje a kolko z nich, ktori ju potrebuju ju naozaj aj pouzivaju? U desktopov a notebookov, kde nezanedbatelna cast predajov ide beznym frantom uzivatelom a len relativne maly fragment korporaciam (kde navyse nejaky deep remote management maju v sieti implementovany len niektore) to nebude zhave. U serverov by sa zakaznici nasli, ale ti sa uspokoja 1) remote accessom v OS, ked je system stabilny, netreba ho podryvat 2) ILO a spol. ktore maju dedikovany HW umoznujuci vzdialeny pristup nejakym kontrolovatelnym sposobom.

Emulacia obsolete HW pre OS, ktore ho nevedia. To myslite vazne? Aky nie uplne archaicky system nenabootuje a nebude vediet pouzivat USB mys a USB klavesnicu? Windows 98, Netware? Zvysne vymenovane funkcie ide realizovat plne v rezii dedikovaneho HW tak, ze nanho FW nemusi sahat ani mysliet. Specificky netboot bol historicky realizovany prioritne dedikovanym FW v sietovke.

Takze na vasu otazku "A co zbytek sveta?" tvrdim, ze zbytok sveta bude bez IME fungovat uplne v pohode a mozno si jeho odchod ani nevsimne. Velmi velka cast tych, ktori by bez neho zit teoreticky nevedeli bude bez neho zit aj tak, pretoze ho k vami proklamovanym funkciam aj tak nepouziva, takze si jeho odchod tiez nevsimne.

Je mi ale jasne, ze k masovemu ustupu od implementacie IME do strojov, kde nie je dovod ho mat (Atom? to fakt?) nedojde, pretoze existuju vyssie zaujmy.

Ad Da sa z neho velmi rychlo zistit, ze code execution chyby v kerneli samotnom (kernel core & surroundings) su dokopy asi 4 - bavme se o vulnerabilities a jejich procentu způsobenému drivery. Máte k tomu nějaká data? Já se zběžně koukal, a nepřipadá mi to, že by většina vulnerabilities byla v driverech. Navíc pokud nahradíte firmware Linuxem, tak musí inicializovat HW (například nastavit parametry RAM modulů), spravovat senzory a chlazení, obsluhovat grafiku (UEFI implementuje Graphics Output Protocol), USB hub a HID zařízení, bootovat asi budete pomocí driverů SATA a nějakých RAIDů, a musíte zavést OS z FS, takže přidejte driver FS.
K té inicializaci HW třeba tady: https://en.wikipedia.org/wiki/Memory_Reference_Code

Ad ze tam tie chyby su ukazuje, ze open source nie je nepriestrelny a da sa donho prepasovat umyselne alebo neumyselne problem - Souhlas, do open source SW může přispívat prakticky kdokoliv. Nevíte jestli ten člověk fyzicky existuje, nebo jestli je to tým nějaké tajné služby, který desetkrát přispěje zajímavým kódem, aby se otupila pozornost toho kdo commity kontroluje, a pak zanese backdoor který se dá považovat za chybu. Nevíte kdo za commitem stojí, neexistuje bezpečnostní prověrka, neexistuje žádná trestní ani jiná odpovědnost, neexistuje dohledatelnost. Není to dost hrozivé?

Ad ktora korporatna code review ma viac ako 10tich reviewerov - standardně commity prochází vedoucí týmu, a pak později reviewers, případně externí auditoři, a pravidelně také automatizované nástroje. U zaměstnanců se kontroluje minimálně průkaz totožnosti, jestli absolvovali deklarované vzdělání a pracovní posize, u citlivějších věcí se běžně dělá bezpečnostní prověrka.

Ad Power management riesi v prevaznej vacsine zasa operacny system, pretoze len ten vie, kolko prace pocitac v skutocnosti ma. - Jenže firmware ví jaké teplotní senzory stroj má, jaké jsou cílové teploty, jak se řídí větráky, jak reagovat na stisk klávesy Fn+Sleep, umí probudit CPU který je úplně zastavený atd.
Ad povodnym ucelom ACPI bolo vytvorit HW nezavislu platformu, ktorou FW moze OS oznamit ako sa naraba s HW kvoli dosiahnutiu nejakej konkretnej cinnosti a OS si potom tieto cinnosti robi sam a FW sa mu do toho nestara. - ACPI má poskytovat interface pro OS. Mimo jiné se z něj dozvíte jestli máte cc:NUMA systém a jaká je cena přístupu k různým zdrojům z různých jader CPU. List těch tabulek a API by byl dost dlouhý.

Ad charakter sluzieb:
Proste sa ide do systemu lognut a bud ho rebootnut, alebo vypnut. - Jistě, to funguje dokud vám například neztuhne OS, nezůstane viset kernel panic, neztuhne OS během shutdownu atd.
KVM je tiez obezlicka, ktora sa objavila v dobach, ked boli remote access schopnosti windowsu takmer na bode mrazu a nejakym podivnym sposobom dodnes nevymrela. - Stačí abyste si nastavil, že při bootu musíte vybrat OS a není tam timeout, a už KVM oceníte. Navíc když stroj přestane reagovat, tak na KVM vidíte co se děje na konzoli. Jako bonus můžete pomocí KVM provést instalaci OS.
kolko percent pouzivatelov naozaj tuto funkcionalitu potrebuje a kolko z nich, ktori ju potrebuju ju naozaj aj pouzivaju - Většina serverových instalací.
U desktopov a notebookov... - Těch jde velké procento do firemního sektoru. Typicky domácích modelů se pokud vím současný problém netýká.

Ad Specificky netboot bol historicky realizovany prioritne dedikovanym FW v sietovke. - Jistě, ale tu síťovku někdo musí inicializovat, zavést její modul firmwaru, dát tomu modulu API pro vstup z klávesnice a výstup na obrazovku (firmware mívá vlastní setup) atd.

Ad tvrdim, ze zbytok sveta bude bez IME fungovat uplne v pohode - Jenže firmware není zdaleka jen o IME. Je to velká spousta funkcionality, která by chyběla každému. IME jako takový by chyběl řadě firem.

>> Ad Da sa z neho velmi rychlo zistit, ze code execution chyby v kerneli samotnom (kernel core & surroundings) su dokopy asi 4 - bavme se o vulnerabilities a jejich procentu způsobenému drivery. Máte k tomu nějaká data?

https://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2017/opec-1/Linux-Linux-Kernel.html

Su to 4 stranky, staci si to zbezne prelistovat. Na prvej stranke vidim 4 exec zranitelnosti, ktore sa dotykaju kernelu samotneho, zvysok su HTC/Qualcomm bootloadery / drivery. Na druhej stranke som videl tiez asi 3 zranitelnosti tykajuce sa samotneho kernelu, zvysok zasa drivery prim ma asi NVidia.

Takze to vychadza zhruba tak, ze na 1 zranitelnost v kode kernelu, kde sa da predpokladat, ze commituju tie neoverene osoby o ktorych ani nikto nevie, ci v skutocnosti existuju pripada cca 10 zranitelnosti v kode driverov kam commituju ti prevereni programatori u ktorych sa overilo, ze maju deklarovane vzdelanie a kod presiel mnohostupnovym review.

Takze nie, nedesi ma, ze kod opensource software-u nerobia ludia s previerkami, pretoze samotny fakt, ze je kod otvoreny je lepsou previerkou, ako ked si jedna korporatna krysa zreviewuje kod druhej korporatnej kryse. Neviem, pre koho pracujete a teda ci to, co mi o korporatnych review hovorite je niekde skutocnostou, vyplodom vasej fantazie, alebo vlhky sen, ale moja skusenost s 10k+ SW domom je, ze nic z toho co hovorite nie je pravda.

(Jeste nad ostatni reakce poznamenam, ze Google trapi samozrejme i notebooky - Chromebooky jsou asi nejvetsi deployment corebootu na pocet instanci, tipl bych si.)