A Linux kernelfejlesztők javítást küldtek be az efivarfs "rm -rf" brickelési problémára

 ( trey | 2016. február 22., hétfő - 8:39 )

Ugyan "rm -rf /" parancsot általában csak idióták és lamer n00bok szoktak futtatni gépükön, de abban egyetérthetünk, hogy a parancs kiadásával nem kellene totálisan használhatatlanná, eltéglásított (bricked) állapotba kerülnie egyetlen számítógépnek sem. Pedig ha valaki önszántából, vagy "jóindulatú" tanácsra ezt teszi Linux alatt EFI-s gépén, akkor könnyen beleszaladhat egy hosszabb gép nélkül töltött pihenőbe.

A probléma a következő: EFI-s gépeken a /sys/firmware/efi/efivars könyvtáron keresztül speciális fájlrendszer érhető el, amely a számítógép UEFI firmware-ének konfigurációs változóit teszi elérhetővé a felhasználó számára. Ha ez a könyvtár rw-re van mount-olva, akkor a megfelelő privilégiummal rendelkező felhasználónak lehetősége van azt letörölni. Ha így tesz, akkor a rosszul megírt firmware-rel rendelkező gépek a következő újraindításkor megakadhatnak a boot folyamatban. A gép a POST folyamatnál tovább nem jut, azaz bricked állapotba kerül.

A probléma elsőként egy systemd bugreportban jött elő, így a "jóakarók" elkezdtek a systemd-re mutogatni. Matthew Garrett - aki egy ideiglenes kernelpatchet is összedobott hamarjában - azonban lehűtötte a a kedélyeket. A Twitter-en azt írta, hogy felesleges a systemd-t okolni a problémáért:

A kernelfejlesztők elkészítették a javítást (alapértelmezésben immutable flag-et kapnak az efivarfs bejegyzések), amit Molnár Ingo be is küldött az LKML-re beolvasztásra.

efi: Make efivarfs entries immutable by default

A javítással kapcsolatos dokumentáció ekképpen frissült:

diff --git a/Documentation/filesystems/efivarfs.txt b/Documentation/filesystems/efivarfs.txt
index c477af086e65..686a64bba775 100644
--- a/Documentation/filesystems/efivarfs.txt
+++ b/Documentation/filesystems/efivarfs.txt
@@ -14,3 +14,10 @@ filesystem.
efivarfs is typically mounted like this,

mount -t efivarfs none /sys/firmware/efi/efivars
+
+Due to the presence of numerous firmware bugs where removing non-standard
+UEFI variables causes the system firmware to fail to POST, efivarfs
+files that are not well-known standardized variables are created
+as immutable files. This doesn't prevent removal - "chattr -i" will work -
+but it does prevent this kind of failure from being accomplished
+accidentally.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

"Ugyan "rm -rf" parancsot általában csak az idióták és a lamer n00bok szoktak futtatni gépükön"

Te hogy szoktál cliben törölni?

Kimaradt egy /

--
trey @ gépház

:)

gondolom a "rm -rf /"-re gondolt

Ő archiválja az adatokat, nem törli. :)

mc enter, fel/le/tab/enter szükség szerint, majd F8 :-P

kérdezzük meg NevemTevét, mennyire jó buli csak ezért egy mct fordítani az AIXára :D

Itt lefagytam. Ennek a kommentnek semmi értelme.

Max te nem találod az asszociációt benne :)

Arra akartam utalni, hogy az mc azért messze nem must have. Az említett fórumtárs meg állandóan azzal küzd, hogy mindenféle dolgokat próbál lefordítani kőkorszaki AIXokra, általában elég küzdelmesen, annó mcvel is küzdött ha jól emlékszem...

4.3-ra még én is forgattam akkori mc-t, és minden komolyabb reszelés nélkül működött :-P

LOL

Hülyeség ellen egy patch sem véd. ;)

Disclaimer: I am not speaking on behalf of my employer, this is my personal opinion

--
zrubi.hu

Én személy szerint a "-o ro" paramétert gondoltam peccsként, de ez tényleg elegánsabb megoldás, alacsonyabb szintű védelem, ráadásul sokkal finomabban hangolható.

Ó B+

Nekik nem kellett megoldást találniuk. Más hülyeségét (szó szerint) kellett workarondolniuk. Ha a düddő firmware író nem szart csinálna, Pistike pedig nem törölgetne, semmi probléma sem lenne. Ezzel a lépéssel pörsenéses Pistikét eliminálták, mert életében nem hallott a chattr parancsról. A firmware író urakat pedig faszkorbáccsal kéne nyakon baszkodni (elnézést a szóhasználatárt, még a tegnap délutáni film hatása alatt vagyok).

--
trey @ gépház

A firmware-nek nem kéne megjelenni ilyen módon az FS-ben. Ahogy sok más hardver(közeli) dolog sem jelenik meg direktben - nagyon helyesen.

Kicsit erőltetett ez nem gondolod?

dd if=/dev/random of=/dev/sda

Az pedig a firmwaregyártó szegénységi bizonyítványa, hogy engedi oly módon módosítani OS felől a firmware-t, hogy az maga alá kullant.

--
trey @ gépház

A következő a /dev/cpu/microcode lesz rw módon?! Csak mert "mindenfájl"... Van, aminek ott kell lennie, és van, aminek meg nem.

A "minden fájl" ott bukik meg, hogy a network interface-k nem file-ok. Meg még sok más helyen.

De amúgy ez eleve rossz modell, hiszen /dev/cpus/cpu0/microcode lenne a helyes, hiszen eleve gondolni kéne több fizikai CPU-ra, és egységesen kezelni őket, de hát ez Linux :D

Teljesen mellékszál, de személy szerint nem tartom épelméjűnek azt a megközelítést, hogy egy több-processzoros rendszerben a különböző processzorokat különböző mikrokóddal basztatom, így szerintem jó az eredeti elnevezés. /OT

Nem kell ezt túldramatizálni. Gamer Pistike simán be tud egy pipa kivétele után a gépén NVIDIA/AMD utility-vel olyan GPU / RAM órajelet beállítani, amivel tetszőlegesen lefagyaszthatja vagy akár rommá sütheti a motyóját. Mégse cimmogunk rajta. Ha ez így van, akkor miért tiltanád meg a root felhasználónak, hogy az low level szinten piszkáljon valamit?

--
trey @ gépház

+1

+1

De nem úgy, hogy echo 100000000000000000000000000000000 > /dev/nvidiagpu/clock_freq

És minő meglepetés, pont ez a kernel feladata. Hardverabsztrakciós réteget adni. Aminek része az is, hogy a hardver hülyeségeit elrejtjük a user elől. Teljesen mindegy, mennyire fos a firmware. Vagy választható még lehetőségként az, hogy ezen a firmwaren nem támogatott a kernel, el sem indul.

Hát persze. Ezért olyan fos az összes firmware. Mert a firmware gányoló urak így gondolkodnak. Csinálunk szart, majd a kernel elrejti! Akár mottó is lehetne.

--
trey @ gépház

Jegyezzük meg, hogy itt azt kell workaroundolniuk, hogy user felé írhatóvá teszik a firmware-t. Ami ellentmond a hardverabsztrakciónak eleve.
Az, hogy egy firmware bugos vagy nem, a végfelhasználónak nem szabad észrevennie. Különben teljesen érdektelen a HAL.

"Jegyezzük meg, hogy itt azt kell workaroundolniuk, hogy user felé írhatóvá teszik a firmware-t."

Amit ugye hiába is akarna, ha azt már firmware/vas szinten megakadályozták volna.

--
trey @ gépház

Az UEFI specifikációnak része, hogy mely UEFI elemek érhetők el és módosíthatók futásidőben (nézz utána az UEFI Runtime Servicesnek). Viszont semmi nem diktálja, hogy a kernelen kívül bárki más piszkálná, sőt, használná az UEFI-t futásidőben.
Az, hogy Linuxnéknál ezt egy shellből is el lehet érni filemanipulációval - bravó, szép munka!

Az EFI specifikációról eddig jót még nem, rosszat annál inkább hallottam. Meg arról is, hogy régen feltalálták, a redundáns firmware-t, már a gagyi, elavult BIOS idejében is. Vagyis ha a master megsérül, vagy frissítés közben tönkremegy, akkor a backup elindul. Sikerült úgy tűnik megint visszafelé lépni.

Lehet itt kenni a szart, hogy a hardver/firmware gyártó miért gyárt olyan fos rendszert, amit OS oldalról el lehet így baszni... Semmi gond nincs vele, mert magának csinált vele problémát. majd szépen addig garanciáztatják nála ezt a szart, amíg meg nem oldja az elmaradt házi feladatát.

--
trey @ gépház

Van egy specifikáció, amit vagy betart valaki, vagy sem. Az, hogy minden rw módon userland-be ki van vezetve, nos, az vélhetően a "vagy sem" eset. Ha egy szabály/specifikáció valaki szerint rossz, arra nem a szabály/sepckó nem tetsző részének az ignorálása a megoldás.

"Due to the presence of numerous firmware bugs where removing non-standard UEFI variables causes the system firmware to fail to POST,"

Kérlek, ne.

--
trey @ gépház

Eleve ami implementációspecifikus (nem-standard) változó, ahhoz a kernelnek hozzá sem szabad nyúlnia egyáltalán. Pont azért implementációspecifikus, hiszen nem tudhatja, hogy a módosításnak milyen következménye van. De a Linux baromi okos, csakazértis hozzányúl, és kiengedi a user felé is. Mert az biztosan jó dolog.

Tehát kiderült, hogy a firmware bugos, a gyártó nem szabvány változókat vezetett be, amit ha letörölnek (megjegyzés: _root jog mellett_ úgy, ahogy értelmes ember azt sosem csinálja), az egész szara összeborul és még mindig a Linux a hülye... OK.

--
trey @ gépház

Ha van nem szabványos változó, akkor az nem ok nélkül van ott. Implementációs részlet. Amíg az UEFI a kernel felé a szabványos interfészt mutatja, addig nincs is baj. Csak éppen Linuxék megengedik az UEFI implementációspecifikus részeit is basztatni tetszőleges root jogú szoftver által. Gratulálok.
Olyan ez, mintha engednéd, hogy a GPU regisztereket módosítsad a GPU driveren kívül, majd csodálkoznál, hogy nincs kép.

Ahahahahaha

--
trey @ gépház

Az NVIDIA utility hol ütközik azzal, hogy "a GPU driveren kívül"? Mesélj még.

Ha implementacios reszlet, akkor miert erheto el egyaltalan a kernel felol?

És ez miért is baj?
Nem lenne ezzel semmi baj, ha legalább egy checksum ellenőrzés lenne a firmware-ben, és csak akkor flashelne, ha az rendben. Eddig ez így ment (lásd pl. intel hex).

Nem firmware cseréről és image checksumról van szó, hanem EFI változókról. Mint anno a BIOS adatterületről.

Tudom, de attól még ott is lehetne ellenőrző összeg. Nem jó példa, de pl. AVR konfigurációs biteknek is van checksumja.

A root azert root, hogy ertsen hozza, nem? Vagy ha nem ert hozza, legalabb akkor is vallalja erte a felelosseget, ha valamit elbasz. De ha ert hozza, akkor a kernel miert kene hogy megakadalyozza, hogy tudjon valamit allogatni?

Milyen szép világ is lenne, ha az egyszeri home usernek hivatalos vizsgát kellene tennie, mielőtt számítógépet használhat. :)

Bizonyám! Valami ilyesmi lenne az ECDL-vizsga is, ha értelmesen lenne megcsinálva.

A kernel nem nyul hozza, csak ad egy interface-t amin keresztul hozzanyulhat valaki aki ert hozza. Miert implementaltak volna egyaltalan, ha senkinek sem szabad hozzanyulni?

A HAL az a kulombsegeket kellene elrejtse. Ha egy gyarto hozzaad valami HW-specifikusat, akkor azt miert ne engedne a kernel, hogy piszkaljuk?
Amugy is csak root-nak van joga a firmware-t piszkalni, es ahogy valamelyik disztro alatt kiirja, elso alkalommal, sikeres sudo utan: "With great power comes great responsability" :)

"... speciális fájlrendszer érhető el, amely a számítógép UEFI firmware-ének konfigurációs változóit teszi elérhetővé" Kicsit magyartalan, de érthető: nem a firmware érhető el, nem írható. Ha egy firmware egy hiányzó (mert pistike letörölte) konfig miatt eldobja magát, az legyen már a firmware hibája.

Tudom, hogy maga a megtestesult gonosz, de miert nem lehet mondjuk Solarisos modon megoldani?:

rm of / is not allowed

--
L

Nagy tradíciója van ezekben a körökben, hogy nem a rendszer fogja megmondani, hogy mit tehetsz. Ha lábon akarod lőni magad, akkor megtehesd.

--
trey @ gépház

A Solaris sem tiltja az "rm-rf /*" parancsot.

Akkor az egész rendszert át kell pakolni a root alól egy rejtett könyvtárba, és máris megmarad ;-)

"velem nem csesztek ki dd if=/dev/urandom of=/dev... " :))

Megint a "védjük meg a hülyéket önmaguktól" amcsi gondolkodás. Annyira védünk már mindentől mindenkit, az emberiség meg elkorcsosul a hülyéktől. Aki hülye, ne használjon linuxot admin joggal. Aki meg mégis, az majd megtanulja. Ha meg nem, hát istenem, ezt hívják természetes szelekciónak.

---
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!
Mindenki jó valamire. Ha másra nem, hát elrettentő példának.

Főleg, hogy a gyökérnek ki is írja, hogy amit el akar követni, az nem helyes:

# rm -rf /
rm: it is dangerous to operate recursively on '/'
rm: use --no-preserve-root to override this failsafe

Képen:

https://flic.kr/p/EkXVJw

Ennél többet mit lehetne?

Szerintem be kéne tiltani az rm parancsot! Faszt akar valaki törölni?

--
trey @ gépház

Hát, skacok, nekem még valamikor a 90-es évek nagyon elejéről van valahol egy szép, A4 méretű könyvem a számítógépről. Mottóként emígy nyitott: intelligens eszköz intelligens kezelőt kíván.

manapság már az a szó, hogy könyv, komoly minőségi előszűrést eredményez. lesúlytó eredménnyel általában. :)

--
xterm

Lesúlytó, az.....

A fenti hozzászólásod is elég lesújtó…

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Lyaly... :-D

ahogy nézem egyedül neked derenghetett fel egyedül, hogy miért pont úgy írtam azt a szót (a többiek csak azt látták, hogy ott egy szó, hibásan). persze nem írtam idézőjelben, vagy *SIC* jellegű megjegyzéssel. :) sebaj, legalább pöröghettek valamin, aminek a tartalomhoz semmi köze. azt úgy sem biztos, hogy megértették.

--
xterm

Megmagyaráz, imádom! :)

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

te, mint hiba nélkül való nyilván értetted amit és ahogy írtam. csak az alteregód inkább rugózik egy olyan dolgon, aminek semmi köze a topikhoz ,) trollkodik, "imádom" (nem mellékesen nem magyarázat volt, hanem tény. még akkor is, ha népszerűbb hibát keresni bárkiben ,)

--
xterm

Azóta eltelt 25 év. A számítógép pedig a mindennapok része lett, és ahhoz, hogy r=1 userek is használhassák, úgy kellene működnie, mint egy mosógépnek, vagy mikrónak. Bedugod, bekapcsolod, elindul, használod, kész.
Vagy mint egy modern autó: feltankolod, beülsz, bekötöd magad, elindítod, oda megy, ahova akarod. És nem szarozol, ha valami gond van, elviszed szervizbe.
Az emberek használni, és nem üzemeltetni akarják a számítógépet. Nem te vagy a gépért, hanem a gép csak egy eszköz a munkád/szórakozásod számára.

Hát pont az autós példa járt a gondolataimban délután.Azt tudja mindenki,hogy dízelbe-gázolajat,benzinesbe-benzint.Valamilyen szinten a kettő összekeverésének a lehetősége védve van, de nem 100%-ban.Viszont azt is tudja minden autó tulajdonos,hogy a víz beöntése az üzemanyag tankba rövid időn belül a motor károsodását okozhatja.Viszont ettől a lépéstől a józan gondolkodáson kívűl semmi sem óvja meg a motort.Kívéve, ha van egy másik ember mellette aki normálisan gondolkodik és lebeszéli róla az idiótát.

A "Bedugod, bekapcsolod, elindul, használod, kész"-be az rm -rf / nem tartozik bele.

A mosógép veszélyes üzem, gyapjú vagy csipkés cuccokat simán el lehet indítani 95 fokos programon, lehet egybemosni fehér és sötét színű ruhákat, és ha elfelejted beakasztani a kifolyó csövét, akkor jobb esetben csak a fürdőszobát áztatod el, rosszabb esetben a parkettázott közlekedőt is.
A mikró szintén, sokféle étel tud felrobbanni a benne fejlődő gőztől, és ha pont nem volt rajta fedő, akkor lehet takarítani, és esetleg még az ebéd is oda. Fém tárgyak, macskaszárítás... hagyjuk.
Az autó meg aztán főleg, meg lehet benne halni, és meg lehet vele ölni másokat.

rm -rf /-t egy fosul megírt script is okozhat, lásd anno a bumblebee installert, ami letörölte a /usr-t egy typo miatt, lásd itt: https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/commit/a047be85247755cdbe0acce6f1dafc8beb84f2ac.

Nem kéne azt gondolni, hogy egy user szándékosan ad ki ilyet.

Aki rendszert buzerál, annak mindig tudatában kell lennie, hogy mit csinál, illetve, hogy annak mik lehetnek a következményei. Legyen az admin, vagy fejlesztő.

(PS: url után nem teszünk pontot)

--
trey @ gépház

Az igazi rendszergazda életében legalább egyszer letörölte a libc-t. Vagy a teljes rendszert :-P

Az igazi rendszergazda kezében elvileg bármikor benne van, hogy egy billentyűleütéssel agyonvághat egy rendszert, ha nem figyel. Mondjuk aki bohóckodik napi szinten storage-okkal, virtuális diszkekkel és hasonlókkal, az tudja, hogy egy álmos kézmozdulattal rövid idő alatt tetemes kárt tudna okozni.

Nyilván (jobb helyeken) a fizetésébe bele van kalkulálva, hogy extra felelősséggel kell a munkáját végezni.

--
trey @ gépház

Egy elcseszett ch[mod|own] valamimask -R / sokkal viccesebb, ott még van esély rendet tenni csúf szopások árán. Egy rm -rf / után sok izgalmas opció nincs.

Kedvenc (látott) hibáim egyike volt a rossz ablakban kiadott chmod 640 * , ahol is a hibabejelentés szerint a júzerek nem tudnak bjelentkezni egy felvillanó "No shell" hibaüzenettel. (Root be tud lépni.) És milyen szép volt a / tartalma a maga egységes sormintának tűnő jogosultsági beállításaival.

Valami ilyesmit csináltam én is, de végül valami kézitákol, get-selections, apt reinstall dologgal kb rendberaktam az életet...

x86-on kitömöríteni /-re egy ARM-s rootfs-t. Be szép is...

Nem, én azt gondolom, hogy a számítógép már most is kb egy kategória a mosógéppel, mikróval, stbvel: veszélyesek, és mindig is azok maradnak.

És ráadásul nem azért veszélyesek, mert egyszer csak nem indulnak el. Ez a kisebbik probléma. A nagyobbik az, hogy a hozzá nem értők (a felhasználók túlnyomó része) olyan adatokat tárol rajtuk különösebb óvintézkedések nélkül, aminek elvesztése vagy kompromittálódása nekik nagyon fájhat.

Igen, a számítógépek kezelése veszélyes üzem. Ha tetszik, ha nem. Odafigyelést igényel. De pl. abban is biztos vagyok, hogy anyósomék a linuxos számítógépükön sosem fogják kiadni az rm -rf / parancsot. Egyrészt, nincs rá jogik, másrészt azt sem tudják, hogy van ilyen.

Azoknak is van felelősségük, akik értenek a gépekhez és olyanok kezébe adják, akik nem. Ilyen esetben gondoskodni kell(ene) a megfelelő betanításról és/vagy a jogkörök megfelelő korlátozásáról.

Ha pedig a felhasználó ezekből nem kér && elbassza a gépét, akkor viselje a következményeit.

--
trey @ gépház