Příkazem rm lze bricknout počítač! (diskuse)

[atalax]

sudo debootstrap sid debian http://http.debian.net/debian/
for x in dev sys proc; do mount -o bind /$x debian/$x; done
sudo chroot debian
...
sudo rm -rf debian 

(nezkoušel jsem, ale nevidím důvod, proč by to nemělo fungovat)

[dustin]

Nemáš ale namontované efivars https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Mount_efivarfs

[atalax]

Aha, fajn, neuvědomil jsem si, že mount -o bind nemountuje rekurzivně.

[Conscript89]

Nemá-li EUFI "reset"

Hm, to jsou jeste dnes nejaky zakladni desky co na sobe nemaji "reset", "clear cmos" nebo neco takovyho? Takova deska si nezaslouzi byt koupena.

[blondak]

Třeba některé x86 tablety,...

[Conscript89]

Hm, tak tam je mozny, ze to jejich zakladni deska to nema. A kdyz to tak rikas tak i ten notebook muze byt sranda.

[Jendа]

Dost notebooků. Nebo to alespoň vyžaduje rozebrání.

[Lol Phirae]

Jooo, pokrok nezastavíš. Ta (U)EFI sračka je hrozně výhodná.

[SUK]

Co ale misto toho?

[Lol Phirae]

No, já teda myslim, že co se Intel architektury týče, tak většina lidí si stále vystačí s tím BIOSem bez téhle přebobtnalé a notoricky chybně implementované obludy, který se naprosto zvrhla v nebezpečný, navíc uživatele omezující paskvil.

[Dusan]

Jednoduché coreboot

https://www.coreboot.org/

je to FOSS

[Petr Tomášek]

A které deska to má? Kromě APU od PC Engines (mladší bratříček Alixů) o žádné nevím...

[nobody]

https://www.coreboot.org/Category:Tutorials

[Lol Phirae]

Ano, takže krom prehistorického šrotu a těch zmíněných desek navržených vysloveně pro embedded s coreboot žádné. A na tom "podporovaném" šrotu to "funguje" např. tak, že není podporováno vypnutí a vícejádrové procesory nikdo nezkoušel a obecně asi polovina běžné funčnosti je označená "untested".

No, pobavilo.

[Jendа]

A ještě k tomu jsou stejně na moderních deskách vyžadovány původní bloby.

[nobody]

Tak treba Lenovo T530 prehistorickej srot neni a Untested vidim jen u Infra a WakeOnLAN/Keyb/Mouse, zbytek je vse OK vcetne multicore...

[Jendа]

Proprietary components status

• ME(Management Engine) => you do not have to touch it (just leave it where it is)
• EC(Embedded Controller) => you do not have to touch it (just leave it where it is)

On se ptal čím to nahradit, ne, co dát vedle toho.

[pc2005]

Infra? To bejvá většinou jako pinmux v SuperIO, to jde nastavit i z OS.

[pc2005]

A to ještě nové verze corebootu podporují jen podmnožinu toho seznamu. Je zkrátka málo zájemců a lidi se radši nechat trollit BIOSem/UEFI než aby testovali nebo přímo vyvíjeli. Ale je fakt, že model bootování na x86 je dost naprd pro testování nestabilního "firmware".

Taky je problém, že spoustu informací o implementaci je nutné vytáhnout z totálně ohackovaných tabulek (třeba ACPI). Ledaže by výrobce desky dodal schéma (a to je třeba problém získat i pro raspberry pí).

No říkám to trochu nerad, ale v tomhle je dobrý Intel. Ten pokud dodá dokumentaci čipsetu, tak je hodně podrobná. Ovšem pokud ne, tak smůla a pak taky z té dokumentace je "cítit" ta korporace - všechno má předdefinovaný postup a nedá se hackovat okolo (což může být dobrý, ale pro hw hackera většinou ne ).

Ale není to jen o corebootu. Co jsem se tuhle koukal na uboot (hlavně pro ARMy nebo embedded), tak to je taky vývojářské maso . No a pokud je UEFI řešeno podobně, tak se není čemu divit, že funguje tak jak funguje . Obávám se, že zřejmé řešení bude omezení přístupu ve prospěch něčeho jako secureboot.

[Jendа]

Já jsem teda o Intelu četl něco jiného.

[pc2005]

To spadá do tohodle:

z té dokumentace je "cítit" ta korporace - všechno má předdefinovaný postup a nedá se hackovat okolo

Ale datasheet pro Intel® 8255x 10/100 Mbps Ethernet k dispozici je a případné úmyslné chyby v dokumentaci zas tolik vyčnívat nad neúmyslnými nebudou. Jinak v té diskuzi to spíš vypadá na informace ohledně PCB návrhu. Rozhodně tím Intel nechci nijak obhajovat (je to hajzl monopoláckej ). Spíš jsem porovnával relativně vůči ostatním firmám (konkrétně SiS cipset vs Intel čipset ke stejnýmu modelu CPU).

Jinak i kdyby tam polovina registrů nebyla, tak je prostě ukradneš z běžícího OS (takhle jsem byl línej dělat autodetekci SIMM 72p paměti ).

[xm]

Např. snad všechny současné Chromebooky používají Coreboot.

[Tomáš2]

ona je spíše zajímavá ta diskuze u systemd na github issue. Ta argumentace ze strany systemd mě skoro děsí. Udělali regresi a obhajují to tím, že tomu stejně nezabrání a cesta jak zničit MB pořád bude existovat, tak proč by to dělali složitě.

[alkoholik]

Z historickych analu: HW, ktery lze znicit softwareove, si ani nic jineho nezaslouzi.
:)

[Rezza]

Jednu dobu to dokazala i Anaconda - vic instalaci zaplnilo efivars... Ale zase se strasne tesim na UEFI na Armu, protoze oproti tomu beznemu bordelu v embedded je lahoda vzit jedno genericke ISO, ktere nabootuje na vsem, co splnuje SBSA a SBBR.

[Jendа]

1) Ta deska pravděpodobně nebyla zničena, stačí znova naprogramovat.

2) Jak ve tvém modelu světa fungují FPGAčka a obecně konfigurovatelná třístavová logika? Obsahuje to například nějaký formální dokazovač, který musí před zkonfigurováním dokázat, že nemůže nastat propojení Vcc a GND? Jak pohodlně se pro takovou věc vyvíjí?

[alkoholik]

Proto pisu o "historickych analech". Slo o dobu, kdy si urcite monitory nehlidaly maximalni frekvence a podobne.

[pc2005]

To ani dneska. V mém mobilu není problém vyřadit trickle charge (na lionce je pak 4.2V a u neoriginálního akupacku to chránil jen polorozpadlej PIC MCU). Taky není problém nastavit napětí Vcore na (možná i přes) limit SoC a očekávat elektromigraci atomů.

[pc2005]

No jenže tím jsi odstranil všechny SSD a HDD . Možná i moje 5.25" disketovka by s tím měla problém .

[Sid]

kazdopadne by kazdej technickej diskuzii prospelo keby sa nezvrhavala na trollovanie. Dost ma prekvapuje ako dokaze byt niekto odbornik na systemd a init obecne a pritom mat problem pochopit k comu je JIRA a ze na vylievanie si srdca sluzia ine stranky ako napr tu

[Rezza]

Pochopit Jiru - to je nadlidsky ukol. Ale tusim ze jednou po dlouhem laborovani se me povedlo vytvorit bug (ci jak se to tam jmenuje).

[Sid]

ono som tiez nepisal pochopit JIRU ale pochopit k comu sluzi JIRA . Ale zase ked zvolis nejaky standardny flow (zrovna na rychlo nenapada nejaky rozumny ekvivalent v sk) tak pridat issue nie je problem.

[Tomáš Bžatek]

Asi nejsi dostatecne agilni!

[laloch]

Kdyz jsem issue (sam to ani nepovazuju za bug) #2402 reportoval, nemel jsem samozrejme ani tuseni v jakou frasku se zvrhne. Ta vlastnost systemd mi zkratka prisla dost nebezpecna. Rozhodne neslo o trolling. Hejno pologramotu se tam stahlo az diky zpravickam jako je tahle.

[j]

Neblbni, prece nechces ric ze to "o nejvyssi" nestvoril naprosto dokonale, to prece neni mozny ...

Normalne lze totiz presne takhle "znicit" jakekoli HW. Ovsem svepravny SW za normalnich okolnosti nepovoluje zapis. Sak se SW da prepsat firmware naprosto cehokoli ze ...

[Lol Phirae]

Ty tomu vůbec nerozumíš. Máš přece použít /etc/fstab, který se jinak ten vymaštěnej brejlatej teplouš snaží již mnoho let zničit. Hlavně zásadově, soudruzi!!!

[AraxoN]

Na systemd sa to poslednou dobou nejak zosypalo. Tu sa ukazuje, aké je zhubné snažiť sa všetko natrepať do jedného monolitu. Je len otázkou času, kedy zložitosť toho na čo sa podujali prekročí kombinované schopnosti všetkých zúčastnených programátorov.

[Václav "Darm" Novák]

To že je argumentace ze strany systemd validní potvrdil i Matthew Garret.

Ale jasně, je v tom interesovaný Lennart, takže viník je všem jasný.

[Lol Phirae]

Šmarjá... LP žádnou validní argumentaci nepředvedl. To, že po třech dnech usilovného přemýšlení a uzamčení komentářů vypotil to, že se přes systemctl dá přece přebootovat do EFI, opravdu není validní argument k tomu, aby to celou dobu bylo namountované RW. O ostatních "argumentech" škoda mluvit.

[mirec]

V tom má celkom pravdu. Na mieste kernelistov heneď vyhodím podporu a pre istotu prehlásim, že kdbus nebude nikdy začlenený, je to predsa problém systemd.

[Ovocníček]

IMHO ukázka toho, že absolutní prosazování principiálních zásad nemusí být vždycky k dobru věci. V tomhle případě "everything is a file". Začlenění takovéhle citlivé speciální paměti do základního fs systému mi přijde že má hodně velké nevýhody, zatímco výhody fakt nevidím (kromě že je to "unix way" či co).

[nobody]

"vse je soubor" je rozhodne v pohode a neni to ten problem, ono staci aby se u nebezpecneho jednalo jednoduse o pripojeni readonly...

[Václav "Darm" Novák]

Čímž zazdíš celkem fajn vlastnosti které to má. Nebylo by lepší apelovat na tvůrce desek, aby implementovali UEFI normálně, tak že to takovou blbostí bricknout nepůjde? Pamatuju si jak linuxové drivery likvidovaly LG vypalovačky… V té době bohužel Lennart nebyl, tak nebylo komu nadávat :)

[Lol Phirae]

Náš administrátor shledal tento komentář závadným.

Vulgarity.

Zobrazit komentář

[Václav "Darm" Novák]

Sorry, ale ani ro a remount na rw v případě potřeby problém neřeší, jen ho odkládá. Stát se to může i tak. Požadavek na to aby se patřičné soubory připojovaly jako +i mi připadá docela validní.

[Lol Phirae]

Jistě, stát se to může i tak. Akorát, že když se budu vrtat v konfiguraci (U)EFI z OS, tak s tím tak nějak budu počítat, že. Při mazání disku tedy opravdu nepočítám s tím, že ten křáp už neprojde ani přes POST.

[Václav "Darm" Novák]

Což immutable řeší a to tak že mnohem lépe. Navíc má pak systemd možnost používat proměnné uefi i na věci na které se opravdu hodí.

[Lol Phirae]

Mně je tedy úplně jedno, jestli to bude immutable nebo read-only a jistě je možné o tom technicky debatovat; v této fázi je celé shrnutí problému v tom, že suverénně nejhorším "řešením" je opět, znova a zase přístup Lennarta, který prostě nebude dělat nic, protože jednou za rok asi tak půl promile uživatelů touží přebootovat z OS do EFI, a když se to uživatelům nelíbí, tak bug uzamkneme a oponenty označíme za "peanut gallery".

[Václav "Darm" Novák]

Osobně s ním souhlasím v tom, že tuhle věc by měl řešit kernel. Řešení v systemd by sice vedlo k menší pravděpodobnosti chyby, ale ta pravděpodobnost by zůstala. Nějaký rootkit ti třeba vesele brickne počítač. V případě řešení navrženém Lennartem to bude mít mnohem těžší. Přes /sys/ třeba můžeš nastavovat frekvenci CPU, GPU, dělat různé jiné věci… Když něco z toho náhodou bude mít potenciál zničit hardware, budeš to řešit mountováním dané věci jako read only a zbavením se funkcionality, nebo zařídíš v kernelu aby to udělat nešlo?

[Lol Phirae]

Přes /sys/ třeba můžeš nastavovat frekvenci CPU, GPU, dělat různé jiné věci…

Nějak té myšlence nerozumím. Viz https://github.com/systemd/systemd/blob/master/src/core/mount-setup.c#L109 - co má jako kernel řešit na tomhle Lennartově natvrdo zadrátovém nesmyslu?

[Václav "Darm" Novák]

Možná se mýlím já, ale pokud se něco mountuje, nedělá to nakonec právě kernel? Není kernel ta vrstva, která dovede zabezpečit nesmazatelnost souboru?

[Lol Phirae]

Upřímně řečeno, ani nevím, zda efivarfs něco takového jako immutable umožňuje, a z "dokumentace" toho tedy opravdu mnoho nevyčtu.

[Václav "Darm" Novák]

IMO je celkem jedno co je to za souborový systém, pokud to co ho připojí a obsluhuje bude mít svá vlastní pravidla.

[kyknos]

nejen lennart, ale vsichni, co mu to basti a to je bohuzel vetsina lidi, kteri dnes rozhoduji o vyvoji majoritnich distribuci

[j]

Tvurci distribuci jsou jeste vetsi idioti nez myslis, protoze defaultne /boot nemountujou vubec. A treba takovej genkernel ma dokonce v konfiguraci volbu, jestli si to ma primountovat sam. A default je ze ne.

[⧠ A = 0]

Lennart je čůrák.

s/čůrák/čurák/g

„Čůrák“ je nesmysl, už jen z etymologického hlediska.

[Gilhad]

Ale to je Lennart taky, takze si nemaji co vycitat :)

[Jendа]

Nebylo by lepší apelovat na tvůrce desek, aby implementovali UEFI normálně, tak že to takovou blbostí bricknout nepůjde?

Proč si myslíš, že je to chyba desky? Možná v tomto konkrétním případě je to proti specifikaci (nevím, neznám), ale obecně na konceptu „deska zpřístupňuje firmware jako FS“ nevidím nic špatného.

[Lol Phirae]

Ale tak přece chyba desky není to, že je něco zpřístupněno, ale že se to nechá bricknout smazáním nějakého konfiguráku toho EFI paskvilu. Implementovat failsafe fallback by patrně stálo tak 0.000001 centu za kus, pročež by patrně výrobce zkrachoval.

[Jendа]

Implementovat failsafe fallback by patrně stálo tak 0.000001 centu za kus, pročež by patrně výrobce zkrachoval.

A ta failsafe věc by byla read-only, aby to někdo omylem nepřepsal? Co když by se v ní našla chyba?

[Lol Phirae]

No, nějak nevím, co by se tam mělo přepisovat. Když si resetnu CMOS, tak mi ten počítač taky naběhne s nějakými natvrdo v BIOSu zadrátovanými defaultními hodnotami. Dokonce existují takové vymoženosti, jako je to, že když si nastavím nějakou úplnou kravinu (např. zběsilé přetaktování) a několikrát po sobě počítač nenaběhne, tak se to taky přenastaví na defaultní hodnoty a počítač opět naběhne.

[Jendа]

No, nějak nevím, co by se tam mělo přepisovat.

Pokud je to konfigurace, tak by to nějakou obnovu mít mohlo.

Pokud je to ale třeba flashka s firmware, tak tam když smažeš firmware, tak prostě smůla (můžeš ji normálně naprogramovat programátorem zvenku).

[pc2005]

Za předpokladu, že to není BGA (ideálně PoP BGA) nebo že ten HW má JTAG .

[R]

Samozrejme, ze je to konfiguracia. Preco by sa to volalo "variables"?

[Sten]

Mnoho zařízení má dvě EEPROM paměti, které při flashování střídá, a pokud jedna nenaběhne, naběhne druhá. Flashuje se vždy ta paměť, která zrovna neběží. Podobně to má Chromebook nebo CoreOS při aktualizaci (má dvě verze /usr, mezi kterými přehazuje). Nevidím problém to samé implementovat i pro UEFI, tedy kdyby výrobci desek trochu přemýšleli. Nejen chybný rm totiž může poškodit firmware.

[j]

No vidis, a proto maji MB uz roky dualni BIOSy, takze i kdyz to preflashnes na nejakou cypovinu, nabootuje to z toho sekundarniho, kterej flashovat nejde.

[R]

Co som videl (GigaByte a nejake HP servery), tak idu flashovat oba.

[Jendа]

Pamatuju si jak linuxové drivery likvidovaly LG vypalovačky… V té době bohužel Lennart nebyl, tak nebylo komu nadávat :)

Když Linux začal rozbíjet vypalovačky, vývojáři na to nereagovali stylem „stejně by to šlo rozbít nějak jinak, tak to tak necháme“, ale přidali tam workaround pro postižené modely.

[Václav "Darm" Novák]

Ano. A tady je podle mě mnohem lepším workaroundem řešit to tak, že dané soubory co se měnit nesmí budou immutable, než prostým mountem jako read only.

[pc2005]

Chyba v kernel driveru ti tenhle problém s UEFI vyvolá i když to bude namountovaný readonly (driver tohle neřeší). Tohle vyřeší sanity test v UEFI inicializaci.

[R]

Som zvedavy, kedy sa objavi nejaky malware pre Windows, ktory bued zneuzivat tento bug vo firmware :D

[aceman]

Doteraz som nepochopil naco je dobre, aby firmware dosky (UEFI) mal akysi subor na disku (ci dokonca cele particie v pripade Windows). Co uzitocne v nom je? To sa to nezmesti do ROM dosky? Co sa stane ak sa tento disk vyberie? Co ak chcem tam chcem dat iny disk?

[Václav "Darm" Novák]

To nejsou soubory na disku, ty soubory jsou v UEFI.

[pc2005]

Když si ségra kupovala notebook, tak ten disk měl před formátováním nějakou special partišnu a byly v tom soubory související s UEFI.

[mankind_boost]

Ano, ale to není samotné UEFI.

[Lol Phirae]

Tos asi nepochopil problém; tohle právě na disku vůbec není. To je pseudofilesystém zapisující proměnné do NVRAM.

[pc2005]

Do stejného (flash) čipu jako kód UEFI (čuchám zajímavé budoucí chyby, jak ta flash bude postupně umírat )? Nebo něco jako PC CMOS zálohovaná baterií (ta ale mívala stěží 256 bajtů)?

[Lol Phirae]

Do stejného (flash) čipu jako kód UEFI (čuchám zajímavé budoucí chyby, jak ta flash bude postupně umírat )

Ono se tam taky moc nezapisuje. Např. když se něco smaže, tak se fakticky nic nemaže, akorát se to označí jako smazané a při rebootu, pokud tam dochází místo, se udělá garbage collection. (S tímhle nějak souviselo bricknutí Samsungů o kterém se psalo před pár lety.)

[pc2005]

No je fakt, že do záruky se to vejde i kdyby tam systemd zapisovalo jako o život.

[little.owl]

Tak ja jsem patril k prvnim adopterum UEFI, kdy to bylo rozbite na vsech stranach a podarilo se mi takto bricknout laptop a desktop motherboard. Ted jiz je to pohoda jazz.

V danem pripade je to chyba na vsech stranach: (a) vyrobce zarizeni pouzije firmware, ktery se slozi po precteni neocekavaneho zaznamu v NVM, bez moznosti recovery, (b) kernel, ktery umoznuje primy zapis treba bez predchoziho odemknuti - s tim se mapovani vse jako file nevylucuje a (a) systemd, ktery to v danem stavu pripojuje trvale jako writable.

[Ondrej Santiago Zajicek]

umoznuje primy zapis treba bez predchoziho odemknuti

Prijde mi, ze mount rw je prave ekvivalent odemknuti.

[AsciiWolf]

systemd is not responsible for allowing kernel code that I wrote to destroy your shitty firmware. I think you get to blame me instead.

Zdroj