A Linux dupla gyors dupla frissítést kap a kernel javításához Hoppá!

A Linux soha nem szenvedett a hírhedt BSoD-től, a rövidítéstől kék képernyő a halál, a Windows rendszer összeomlásához kapcsolódó rettegett „valami szörnyen rosszul sikerült” üzenet elnevezése.

A Microsoft az évek során sok mindent megpróbált, hogy megrázza ezt a „BSoD” becenevet, beleértve az összeomlási üzenetek megjelenésekor használt háttérszín megváltoztatását, egy szuper méretű szomorú arcú hangulatjel hozzáadásával, hogy az üzenet együttérzőbb legyen, és QR-kódokat jelenítsen meg. pattintsa a telefonjával, hogy segítsen diagnosztizálni a problémát, és ne töltse ki a képernyőt a kernelkódobjektumok technobablistájával, amelyek éppen akkor éppen betöltődnek.

(Those crash dump lists often led to anti-virus and threat-prevention software being blamed for every system crash, simply because their names tended to show up at or near the top of the list of loaded modules – not because they had anything to do with the crash, but because they generally loaded early on and just happened to be at the top of the list, thus making a convenient scapegoat.)

Még jobb, hogy a „BSoD” már nem a mindennapi, elvetemült pejoratív kifejezés, mint korábban, mert a Windows sokkal ritkábban omlik össze, mint korábban.

Nem azt állítjuk, hogy a Windows soha nem omlik össze, és nem azt állítjuk, hogy most varázslatosan hibamentes; pusztán megjegyezzük, hogy általában nincs szüksége a BSoD szóra olyan gyakran, mint korábban.

Linux összeomlási értesítések

Természetesen a Linuxnak soha nem volt BSoD-je, még akkor sem, amikor úgy tűnt, hogy a Windows mindig rendelkezik velük, de ez nem azért van, mert a Linux soha nem omlik össze, vagy varázslatosan hibamentes.

Egyszerűen arról van szó, hogy a Linux nem alkalmazza a BSoD-t (igen, ez a kifejezés intransitív igeként is használható, mint a „laptopom BSoDded félúton egy e-mailben”), mert – elragadóan kifejezve – szenved. hoppá, vagy ha a hoppá elég erős ahhoz, hogy a rendszer még csökkent teljesítmény mellett sem tud megbízhatóan fent maradni, pánikba esik.

(Linux kernelt is beállíthatunk úgy, hogy egy hoppá mindig „előléptetnek” a pánik, olyan környezetekben, ahol biztonsági megfontolások miatt jobb egy olyan rendszer, amely hirtelen leáll, bár egyes adatok nem kerülnek mentésre időben, mint egy olyan rendszer, amely bizonytalan állapotba kerül, ami adatszivárgáshoz vagy adatsérüléshez vezethet.)

An hoppá általában valami ehhez hasonló konzolkimenetet produkál (az alábbiakban megadtuk a forráskódot, ha szeretnéd felfedezni hoppá és a pánikba esik magadért):

[12710.153112] oops init (szint = 1) [12710.153115] oops kiváltása a BUG()-on keresztül [12710.153127] ------------[ vágd ide ]------------- [12710.153128] kernel BUG itt: /home/duck/Articles/linuxoops/oops.c:17! [12710.153132] érvénytelen műveleti kód: 0000 [#1] PREEMPT SMP PTI [12710.153748] CPU: 0 PID: 5531 Comm: insmod . . . [12710.154322] Hardvernév: XXXX [12710.154940] RIP: 0010:oopsinit+0x3a/0xfc0 [hoppá] [12710.155548] Kód: . . . . . [12710.156191] RSP: . . . ZÁSZLÓK: . . . [12710.156849] RAX: . . . RBX: . . . RCX: . . . [12710.157513] RDX: . . . RSI: . . . RDI: . . . [12710.158171] RBP: . . . R08: . . . R09: . . . [12710.158826] R10: . . . R11: . . . R12: . . . [12710.159483] R13: . . . R14: . . . R15: . . . [12710.160143] FS: . . . GS: . . . knlGS: . . . . . . . . [12710.163474] Call Trace: [12710.164129] [12710.164779] do_one_initcall+0x56/0x230 [12710.165424] do_init_module+0x4a/0x210 [12710.166050] __do_sys_finit_module+0x9e/0xf0 [12710.166711] do_syscall_64+0x37/0x90 [12710.167320] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 12710.167958] RIP: 0033:0x7f6c28b15e39 [12710.168578] Kód: . . . . . [. . . . . [12710.173349] [12710.174032] A modulok linkjei: . . . . . [12710.180294] ---[ végnyom 0000000000000000 ]---

Sajnos, amikor a múlt hét végén megjelent a kernel 6.2.3-as verziója, két apró változtatás gyorsan bebizonyosodott. problematikus, a felhasználók a kernel meghibásodásáról számolnak be a lemeztár kezelése során.

A 6.1.16-os kernel láthatóan ugyanazoknak a változásoknak volt kitéve, és így ugyanarra a hibára hajlamos.

Például egy cserélhető meghajtó csatlakoztatása és felszerelése jól működött, de a meghajtó leszerelése, miután végzett vele, hoppá.

Bár egy hoppá nem fagyasztja le azonnal az egész számítógépet, a rendszermag szintű kód összeomlása a lemeztár leválasztásakor elég aggasztó ahhoz, hogy egy jól tájékozott felhasználó valószínűleg mielőbb le akarja állítani, ha folyamatos, adatsérülést okozó probléma esetén. …

…de néhány felhasználó arról számolt be, hogy a hopp megakadályozta azt, amit a zsargonban an szabályos leállás, amely megköveteli a tápellátás erőszakos bekapcsolását, a bekapcsológomb néhány másodpercig tartó nyomva tartásával, vagy ideiglenesen megszakítja a kiszolgáló tápellátását.

A jó hír az, hogy a kernelek 6.2.4 és a 6.1.17 azonnal kiadták a hétvégén, hogy visszaállítsák a problémákat.

Tekintettel a Linux kernel-kiadások sebességére, ezeket a frissítéseket már követték 6.2.5 és a 6.1.18, amelyeket maguk is frissítettek (ma, 2023-03-13). 6.2.6 és a 6.1.19.

Mit kell tenni?

Ha 6.x verziójú Linux kernelt használ és még nem vagy naprakész, ügyelj rá, hogy közben ne telepítsd a 6.2.3-at vagy a 6.1.16-ot.

Ha már megvan az egyik verzió (néhány napig a 6.2.3-as verziónk volt, és nem tudtunk illesztőprogram-összeomlást előidézni, feltehetően azért, mert a kernelkonfigurációnk véletlenül megóvott minket a hiba kiváltásától), fontolja meg a mihamarabbi frissítést…

…mert ha eddig nem is szenvedtek lemezkötet alapú problémákat, lehet, hogy szerencsére immunisak vagytok, de ha újra frissíti a kernelét, akkor is immunissá válik.

---

HOPP- ÉS PÁNIKESEMÉNYEK FELFEDEZÉSE EGYEDÜL

Szüksége lesz egy forráskódból összeállított kernelre, amely már telepítve van a tesztszámítógépen.

Hozzon létre egy könyvtárat, nevezzük /test/oops, és mentse ezt a forráskódot másként oops.c:

#include <linux/kernel.h> #include <linux/module.h> #include <linux/moduleparam.h> #include <linux/init.h> MODULE_LICENSE("GPL"); static int level = 0;
module_param(level,int,0660); static int oopsinit(void) { printk("oops init (level = %d)n",level); // level: 0->just load; 1->oops; 2->panic switch (level) { case 1: printk("triggering oops via BUG()n"); BUG(); break; case 2: printk("forcing a full-on panic()n"); panic("oops module"); break; } return 0; } static void oopsexit(void) { printk("oops exitn"); } module_init(oopsinit); module_exit(oopsexit);

Hozzon létre egy fájlt ugyanabban a könyvtárban, melynek neve Kbuild az összeállítási paraméterek vezérléséhez, például:

 EXTRA_CFLAGS = -Fal -g obj-m = hoppá.o

Ezután építse meg a modult az alábbiak szerint.

A -C opció elmondja make hol kezdje el keresni Makefiles, így az építési folyamat a megfelelő kernel forráskódfára mutat, és a M= beállítás megmondja make hol található az erre az alkalomra építendő modul tényleges kódja.

Meg kell adnod a teljes, abszolút utat M=, ezért ne próbálja meg menteni a gépelést a használatával ./ (az aktuális könyvtár az építési folyamat során mozog):

/test/oops$ make -C /ahol/a/a/kernelt építetted M=/test/oops CC [M] /home/duck/Articles/linuxoops/oops.o MODPOST /home/duck/Articles/linuxoops/ Module.symvers CC [M] /home/duck/Articles/linuxoops/oops.mod.o LD [M] /home/duck/Articles/linuxoops/oops.ko

Be- és kirakhatod az újat oops.ko kernel modult a paraméterrel level=0 csak hogy ellenőrizze, működik-e.

Benéz dmesg egy naplóért a init és a exit felhívások:

/test/oops# insmod oops.ko level=0 /test/oops# rmmod oops /test/oops# dmesg . . . [12690.998373] hoppá: a fán kívüli modul betöltése megrontja a kernelt. [12690.999113] hoppá init (szint = 0) [12704.198814] hoppá kilépés

Provokálni egy hoppá (visszanyerhető) vagy a pánik (leakasztotta a számítógépet), használja level=1 or level=2 illetőleg.

Ne felejtse el menteni az összes munkáját, mielőtt bármelyik feltételt aktiválná (utána újra kell indítania), és ne tegye ezt valaki más számítógépén hivatalos engedély nélkül.

---

• SEO által támogatott tartalom és PR terjesztés. Erősödjön még ma.
• Platoblockchain. Web3 metaverzum intelligencia. Felerősített tudás. Hozzáférés itt.
• Forrás: https://nakedsecurity.sophos.com/2023/03/13/linux-gets-double-quick-double-update-to-fix-kernel-oops/