Názory k článku
Počítač s UEFI se může nenávratně poškodit použitím rm -rf /
-
FíkZlatý podporovatelnojo, to tam je teprve od roku 2007, to my ze staré školy neznáme :)
navíc je to myšleno obrazně, ne aby to někdo zkoušel -
. . (neregistrovaný)
o živě nemluvím, ale "rm -rf /" je pro mě termín a ne příkaz :). Ono je ve výsledku jedno, jestli napíšeš "rm -rf /*", "rm -rf /sys" či "cd / && rm -rf ."
Argumentace a ani přístup systemd se mi nelíbí, provedli regresi a mají to napravit. Smazání rootu před incriminovanou verzi nic nezpůsobilo, po aktualizaci rozbije MB, na tom není co diskutovat. A ano, občas se dá podobným způsobem zničit dost věcí, třeba nahrávat nový firmware, ale nezkontrolovat si jeho checksum má občas také fatální následky.
-
. . (neregistrovaný)
Nechci v tomhle slovíčkařit, máš samozřejmě pravdu. Ale v Linuxu se mezi vývojáři, hlavně co vidím u kernelu, drží zásada, že změnu nezpůsobíš jiné chování, ikdyž není dokumentované.
Tady jednoznačně příkaz rm -rf / před touhle verzí a potéhle verzi má jiné důsledky. Nejde o to na čí přesně straně je chyba a kdo jí bude postupně opravovat, ale v systemd by mělo mountování zůstat zhodné a nezpůsobovat nežádoucí side effect. Můj názor.
-
darm (neregistrovaný)
Před touto a po této verzi by měl mít ten příkaz naprosto identické výsledky, pokud jsou efivars kernelem mountované do /sys/ jako rw.
Co jsem koukal, nejpopulárnější varianta řešení je zařídit na úrovni kernelu, aby ty soubory které nesmí být přepsány byly immutable a zbytek normálně dostupný. -
. . (neregistrovaný)
kernel to nemountuje, to si mountuje systemd a ten to začal dělat až teď, kdy přidaly (ano správně y :-D) podporuje pro změnu boot a zavaděče.
To ano, tuhle chybu má ošetřovat kernel, na druhou stranu vývojový cyklus kernelu není tak flexibilní jak vývojový cyklus HW. Tohle je jednoznačně bug MB a musí si to opravit, ale doteď se neprojevoval, protože nešlo tak snadno si to omylem smazat.
Immutable být nemohou, jinak nemůžeš měnit boot parametry, v konkrétních případech ho potřebuješ mít připojený jako rw a kernel ho připojí tak, jak si řekne systém a ten si ho připojuje jako rw, což dříve nedělal.
-
. . (neregistrovaný)
jo takhle to myslíš, prostě u některých souborů nastavit příznak. (U)EFI neznám, nevím tedy jestli jsou dané soubory součástí specifikace a mají nějakou roli, u které se nevylučuje příznak immutable nebo to je věcí implementace konkrétního výrobce.
Za mě pořád platí, že využití bugu způsobil systemd a měl by ho také ošetřit a ne říkat, že to tady hnije dlouho, tak to řešit nebude.
-
darm (neregistrovaný)
Osobně jsem toho názoru že bug nezpůsobil, ale byl pomocí něj odhalen. Aneb Matthew Garret:
>The simple answer of "Make it read-only" is missing the point - there's a bunch of legitimate reasons to want to be able to write here
>fixing the typo case without fixing the underlying problem still makes it possible for malicious actors to do damage
>We need to fix the actual problem rather than implementing an inherently racy solution that blocks other legitimate use cases -
Od kdy je bug, když kernel dělá to, co se po něm chce? Lze to připojit RW, mám na to oprávnění, není co řešit a není důvod, aby to kernel neudělal. Je snad chyba kernelu, když nechám bez dozoru PC s přihlášeným růtem a někdo mi vyzeruje /dev/sda? Nebo je to moje chyba, že jsem ten PC tak nechal? Největším problémem je vždy uživatel, je proto správné, aby systém neumožnil nikomu přihlášení?
-
darm (neregistrovaný)
Je to bug HW který lze řešit na úrovni kernelu, jako tomu bylo mnohokráte předtím. Připojit to vůbec jít nemusí, ale je důvod pro to aby to připojit šlo. Ve chvíli kdy to připojit jde, je dobré postarat se o to, aby chyba v návrhu hardware nemohla vést vedle legitimního účelu i k poškození zařízení. Už jen proto že případná breberka s právy roota teď může udělat remount a zlikvidovat uefi, systemd nesystemd. Ostatně, jsem zvědav kdy k tomu dojde u Windows systémů.
-
Klidně mi můžeš věřit, že breberka s právy roota je pro mě, hlavně na serverech, mnohem větší tragédie než to, že se dá zlikvidovat deska. Pokud breberka neudělá nic jinýho, pouze toto, potom jí pěkně poděkuju a šťastněj, že se nestalo nic horšího, objednám novou desku.
On totiž kdokoliv může přijít k tobě domů, vykopnout dveře a ukrást ti celej PC, což je asi trochu horší než deska. A co pro to dělám, aby se to nestalo? Nenechávám dveře dokořán a pro jistotu klíče v zámku, kdyby je náhodou zabouchl průvan. Na druhou stranu si asi PC nezavřeš do trezoru a nezahodíš klíče, aby jsi si s ním náhodou něco neudělal sám. -
. . (neregistrovaný)
nepíši, že bug způsobil, ale do vydání nové verze systemd nešel bug snadno omylem využít, teď to jde.
Při práci, ke které potřebuje systemd rw, si to může remount, práci udělat a znovu remoutnout na r.
Souhlasím s tím, že oprava se musí zajistit, ale vem to prakticky, než výjde patch kernelu, potrvá to relativně dlouho (nevidím, že by se dostal do prioritních oprav), jestli MSI vydá nový firmware je otázka, ale rozhodně to nebude rychlé. Takže se může stát, že nová feature systemd, která ne svoji chybou umožňuje zničení MB tady bude několik měsíců.
-
V tomto případě nechápu, na co patch kernelu. Připojit trvale efivars RW je prostě volovina srovnatelná s trvale přihlášeným rootem. NIKDY, rozhodně NIKDY se nesmí kernel přizpůsobovat Poetteringovi a jeho bugwaru, to je cesta do pekel. Je to z 50ti procent chyba HW, ze 40ti procent chyba SystemD a z 10ti procent chyba uživatele, kterej si to brickne. Kernel udělá jen to, co se po něm chce a to prostě NENÍ bug. Jestli má kernel něco začít aktivně z vastní vůle blokovat, potom je to SystemD.
-
. . (neregistrovaný)
Kernel patch jen v případě, kdy se tímhle způsobem povedlo smazat soubor, který nedovoluje specifikace EFI změnit a má být immutable (neznám ale do těhle podrobností EFI a ani soubor, který reálně bug způsobil).
Bohužel, blokace systemd ze strany Kernelu už neprošla, bylo by to nejlepší řešení pro nás všechny, kterým je přístup systemd proti srsti a způsobuje problémy.
-
. . (neregistrovaný)
tím, že nenechám bug využít jiným naprosto nesouvisejícím příkazem, který je legitimní občas použít není zakrytí. Bug bude pořád existovat, pořád se může projevit při neodborné manipulaci s efi třeba při instalaci systému a očekávám, že k jeho opravě dojde nebo dojde k poklesu MSI notebooků :)
-
Ne, bug se nemá zakrývat, o bugu se ví, ale má se řešit na správných místech. V prvé řadě je to výrobce HW a v druhé řadě potom SystemD, který zcela zbytečně připojuje něco, po čem je mu 99,999999 procent času úplný prd. Vůbec nerozumím tomu, proč by za normální situace nějaké nástroje měly něco zapisovat do efi, případně pokud opravdu potřebují, stejně to mají ošetřený i bez SystemD. Tohle jsou prostě klíče zapomenutý v zámku jak vyšitý.
-
Ked uz ma niekto rootovske prava a CHCE ti uskodit, efi/vars je ten najmensi problem. efi/vars maju byt nepripojene alebo pripojene RO pre pripad chyb ako je tato.
Proste, "Poettering povedal" nieje dost dobry dovod riskovat poskodenie HW. Ani ked si to zasluzi :)
-
darm (neregistrovaný)
Asi holt hodlám věřit člověku který stojí za implementací UEFI v kernelu, když tvrdí že oprava v jádře bude jednodušší a lepší řešení než ošetřit všechny možné varianty v userspace a odmítám připojovat se k "lovu na čarodejnice". Zajímalo by mě jestli by takový poprask nastal kdyby podobný problém nastal jinde.
-
S tím se nedá, než nesouhlasit. Řešit v jádře opravy blbě udělanýho HW je prasečina, i když možná jednoduchá. Největší problém je v tom, že se Poettering zachoval opět jako největší debil, evidentně se před jeho zásahem tento problém neprojevoval, nikdy předtím neexistoval důvod, proč mít trvale připojené efivars RW a najednou to tak musí být, všichni jsou kreténi a on jediný má pravdu.
-
Pořád nejsem ochotnej se smířit s tím, že je chyba, že si uživatel může přepsat něco, co se přepsat dá. To je snad kromě Widlí samozřejmost a jsou pro to dobré důvody. Ale nesmířím se s tím, že ten kretén tvrdí, že je v pořádku, aby to bylo trvale připojený RW. Na co? Na těch několik málo operací jednou za sto let? SystemD je prostě nápad chorýho mozku, nenapadá mě nic jinýho, než že je to pokus o získání významného vlivu nad Linuxem.
-
Kernel developerom vsetka ucta, ale nie :)
https://twitter.com/mjg59/status/693496443395399680
V idealnom svete by som s nim suhlasil. V realnom svete preklepov a tisicov rozne dodrbanych implementacii UEFI by som to neriskoval.
-
Ivan (neregistrovaný)
Ono staci aby nejaky admin spustil restore a efi/vars si muze prepsat zalohou z nejakeho jineho systemu. Pred nejakou dobou zase najednou pribyl na Linuxu filesystem (.gvfs) kam nemuze ani root a nejde zalohovat. Opravdu bych nechtel pracovat ve firme ktera vyrabi komercni zalohovaci sw pro Linux.
-
Ano, mountuje ho kernel, ale nemountuje ho jen tak z vlastní vůle. Jsou to věci, které za určitých okolností mají být RW a úlohou kernelu není, aby v tom někomu bránil. Pokud si to někdo chce smazat, budiž mu to umožněno. Největší chyba je rozhodně na straně HW, kterej by měl pro tento případ obsahovat nějaké záchranné mechanismy. A druhá blbost je mít to připojené trvale RW a za to může ten zmetek. To, že kernel připojí něco RW, když je to možné, někdo to po něm chce a má na to patřičná oprávnění, to rozhodně není bug, ale snad samozřejmost. Nebo mi něco uniká a mluvíme tady o MS Linuxu 10?
-
j (neregistrovaný)
A proc by proboha mel kernel resit, co si mountujes? Ten to vubec nezajima. Pokud mountujes neco co muze byt potencielne nebezpecny, tak je predevsim na tobe aby sis to osefoval.
Nechces taky aby ti kernel znemoznil prepsat boot? Protoze kdyz si ho primountujes a neco tam blbe zmenis, tak ti to taky nenabootuje. A prekvapive spousta dister to resi tak, ze maji tools, kdyz neco menis (treba konfiguraci gruba) tak si to pripojej RW, a pak to zas odpojej, takze bydefault nic pripojenyho neni.
-
peci1Stříbrný podporovatelTo je teda argumentace... Ne, nebudeme mountovat efivars readonly by default, protoze podobne si muzes prepsat treba /dev/sda a taky ti to nikdo nezakazuje. Jsem rad, ze Lennart Poettering ty komentare promazal, protoze si vazne nedovedu predstavit, co za zumpu tam bylo pred promazanim... Jak kdyby vetsi polovina diskutujicich nevedela, ze poskodit system na disku je o trochu mensi problem nez bricknout mobo. I kdyby to bylo, jak pisou, (klasicky) spatnou implementaci UEFI ze strany nekterych vyrobcu.
-
Lol Phirae (neregistrovaný)
To je teda argumentace... Ne, nebudeme mountovat efivars readonly by default, protoze podobne si muzes prepsat treba /dev/sda a taky ti to nikdo nezakazuje.
No to víš, ze systému do EFI každý uživatel pravidelně rebootuje nejméně 10x denně, takže by ho přemountování na rw hrozně zdržovalo. :-P
-
Ivan (neregistrovaný)
Uz jsem zazil situaci kdy na produkcnim serveru nebylo misto na disku a tak nekoho napadlo vytvorit zalohu databaze v /dev/shm. Proc taky ne, kdyz podle vystupu z df je tam dost mista. Problem nemusi byt v tom, ze se to smaze. Staci to zaplnit na 100% anebo tam nahrat nejaky bordel a nektere biosy to nevydychaji.
Systemd mysli za uzivatele a snucuje nim svuj podled na svet pri ruznych prilezitostech. V tomhle pripade ale dava lidem svobodnou volbu si svuj system rozbit.
-
Moba (neregistrovaný)
HW, který poškodíte pomocí software, si nic jiného nezaslouží!
Skutečně, takový HW neměl spatřit světlo světa!
Něco jiného je přetaktování a něco jiného je bricknutí pomocí skriptu nějakého vtipálka, který do repozitáře přidá vhodně zakuklený příkaz rm. App, on ze příkaz rm rf dá velmi pěkně obfuskovat, že na první pohled vypadá naprosto neškodně, třeba jako úklid nějakého pracovního adresáře. -
Klasická ukázka arogance správců issue trackerů (nebo vlastních programátorů), všichni považují lidi z okolního světa za blbce.
Mám podobné zkušenosti z vývojem Bitcoinu, otevřít issue znamená, že je během chvíli zavřeno s nějakou pitomou výmluvou. A podobné problémy u NW.js, takže tam v zásadě už žádné chyby radši nereportuju.
-
Lol Phirae (neregistrovaný)
No, suverénně nejhorší zkušenost mám z nedávné doby s DD-WRT. To, co se děje v "bugzille" tam, nad tím zůstává rozum stát. Bug o bricknutí routeru v důsledku moc velkého souboru s FW (po aktualizaci nějaké "nezbytnosti" na novější, nabobtnalejší verzi) asi 20x dokola označen jako invalid, aby byl po několika měsících opraven. A naprosto stejně to tam vypadá s většinou ostatních.
-
jan2son (neregistrovaný)
No je fakt, ze sem si uz stacil premazat MBR u disku s cryptsetup partition. Zrovna zaloha tabulek UEFI na konci disku me zachranila. Ufff - skvelej vynalez. Premazano prave zapisem do sda (dd if=/dev/zero of=/dev/sda). Stane se, kdyz clovek pouziva yocto-like komercni systemy ktere obsahuji zastarale deployment skripty.
Pripadne mi, ze se systemd se chova podobne jako instalace MS-DOS. Instalace automaticky premazala MBR - bez upozorneni, dotazovani uzivatele, autodetekce jinych partition nebo instalovanych OS - proste nezajem.
ČLÁNKY DO MAILU