Linux får dobbelt hurtig dobbeltopdatering for at rette kerne Ups!

Linux har aldrig lidt af den berygtede BSoD, en forkortelse for blå skærm af død, navnet på den frygtede "noget gik helt galt"-meddelelse forbundet med et Windows-systemnedbrud.

Microsoft har prøvet mange ting gennem årene for at ryste det kaldenavn "BSoD", herunder at ændre baggrundsfarven, der bruges, når der vises nedbrudsbeskeder, tilføjet et superstort humørikon for at få beskeden til at føles mere medfølende, og vise QR-koder, som du kan snap med din telefon for at hjælpe dig med at diagnosticere problemet og ikke fylde skærmen med en technobabble-liste over kernekodeobjekter, der lige tilfældigvis blev indlæst på det tidspunkt.

(Disse nedbrudsdumplister førte ofte til, at antivirus- og trusselsforebyggende software fik skylden for hvert systemnedbrud, simpelthen fordi deres navne havde en tendens til at dukke op på eller nær toppen af ​​listen over indlæste moduler – ikke fordi de havde noget at gøre med styrtet, men fordi de generelt loadede tidligt og tilfældigvis var øverst på listen, og dermed var en bekvem syndebuk.)

Endnu bedre, "BSoD" er ikke længere det daglige, engangsbegreb, som det plejede at være, fordi Windows går ned meget sjældnere end det plejede.

Vi antyder ikke, at Windows aldrig går ned, eller antyder, at det nu på magisk vis er fejlfrit; blot at bemærke, at du generelt ikke har brug for ordet BSoD så ofte, som du plejede.

Linux-nedbrudsmeddelelser

Selvfølgelig har Linux aldrig haft BSoD'er, ikke engang dengang Windows så ud til at have dem hele tiden, men det er ikke fordi Linux aldrig går ned eller på magisk vis er fejlfri.

Det er simpelthen, at Linux ikke BSoD (ja, udtrykket kan bruges som et intransitivt verbum, som i "min bærbare computer BSoDde halvvejs gennem en e-mail"), fordi det – i en dejlig underdrivelse – lider af en oops, eller hvis ups er alvorlig nok til, at systemet ikke pålideligt kan holde sig oppe selv med forringet ydeevne, panik.

(Det er også muligt at konfigurere en Linux-kerne, så en oops altid blive "forfremmet" til en panik, for miljøer, hvor sikkerhedshensyn gør det bedre at have et system, der lukker ned brat, dog med nogle data, der ikke bliver gemt i tide, end et system, der ender i en usikker tilstand, der kan føre til datalækage eller datakorruption.)

An oops producerer typisk konsoludgang noget som dette (vi har leveret kildekoden nedenfor, hvis du vil udforske upses , panik for dig selv):

[12710.153112] ups init (niveau = 1) [12710.153115] udløser ups via BUG() [12710.153127] ------------[ klip her]------- [12710.153128] kernel BUG på /home/duck/Articles/linuxoops/oops.c:17! [12710.153132] ugyldig opcode: 0000 [#1] PREEMPT SMP PTI [12710.153748] CPU: 0 PID: 5531 Komm: insmod . . . [12710.154322] Hardwarenavn: XXXX [12710.154940] RIP: 0010:oopsinit+0x3a/0xfc0 [ups] [12710.155548] Kode: . . . . . [12710.156191] RSP: . . . EFLAGS:. . . [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] Kode: . . . . . [. . . . . [12710.173349] [12710.174032] Moduler linket i: . . . . . [12710.180294] ---[ slutsporing 0000000000000000 ]---

Desværre, da kerneversion 6.2.3 udkom i slutningen af ​​sidste uge, viste to små ændringer sig hurtigt at være problematisk, med brugere, der rapporterer kernel oopses, når de administrerer disklager.

Kernel 6.1.16 var tilsyneladende genstand for de samme ændringer, og derfor tilbøjelig til den samme uhygge.

For eksempel virkede det fint at tilslutte et flytbart drev og montere det, men at afmontere drevet, når du var færdig med det, kunne forårsage en oops.

Selvom et ups ikke med det samme fryser hele computeren, er kodenedbrud på kerneniveau, når du afmonterer disklager, bekymrende nok til, at en velinformeret bruger sandsynligvis ønsker at lukke ned så hurtigt som muligt, i tilfælde af vedvarende problemer, der fører til datakorruption …

…men nogle brugere rapporterede, at ups forhindrede det, der er kendt i jargonen som en velordnet nedlukning, hvilket kræver, at strømmen slås fra, ved at holde tænd/sluk-knappen nede i flere sekunder eller midlertidigt afbryde strømforsyningen til en server.

Den gode nyhed er, at kerner 6.2.4 , 6.1.17 blev straks løsladt i weekenden for at rulle problemerne tilbage.

I betragtning af hastigheden af ​​Linux-kerneudgivelser er disse opdateringer allerede blevet efterfulgt af 6.2.5 , 6.1.18, som selv blev opdateret (i dag, 2023-03-13) af 6.2.6 , 6.1.19.

Hvad skal jeg gøre?

Hvis du bruger en 6.x-version Linux-kerne og du ikke allerede er bange up-to-date, så sørg for at du ikke installerer 6.2.3 eller 6.1.16 undervejs.

Hvis du allerede har en af ​​disse versioner (vi havde 6.2.3 i et par dage og var ikke i stand til at fremkalde et drivernedbrud, formentlig fordi vores kernekonfiguration beskyttede os utilsigtet fra at udløse fejlen), overvej at opdatere så snart du kan...

…fordi selv hvis du ikke har haft problemer med diskvolumen-baserede indtil videre, kan du være heldig, men ved at opgradere din kerne igen vil du blive immun af design.

---

UDFORSK OPS OG PANIKBEGIVENHEDER PÅ DIN EGEN

Du skal bruge en kerne bygget fra kildekode, der allerede er installeret på din testcomputer.

Opret en mappe, lad os kalde det /test/oops, og gem denne kildekode som 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);

Opret en fil i samme mappe kaldet Kbuild for at styre byggeparametrene, sådan her:

 EXTRA_CFLAGS = -Væg -g obj-m = ups.o

Byg derefter modulet som vist nedenfor.

-C mulighed fortæller make hvor man skal begynde at lede efter Makefiles, og peger således byggeprocessen mod det rigtige kernekildekodetræ, og M= indstilling fortæller make hvor man kan finde den faktiske modulkode til at bygge ved denne lejlighed.

Du skal give den fulde, absolutte vej til M=, så prøv ikke at gemme indtastning ved at bruge ./ (den aktuelle mappe flytter rundt under byggeprocessen):

/test/oops$ make -C /where/you/built/the/kernel 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

Du kan indlæse og aflæse den nye oops.ko kernemodul med parameteren level=0 bare for at tjekke at det virker.

Kig ind dmesg for en log over init , exit opkald:

/test/oops# insmod oops.ko level=0 /test/oops# rmmod ups /test/oops# dmesg . . . [12690.998373] ups: indlæsning af out-of-tree-modul pletter kernen. [12690.999113] ups init (niveau = 0) [12704.198814] ups exit

At provokere en oops (inddrives) eller en panik (vil hænge din computer), brug level=1 or level=2 henholdsvis.

Glem ikke at gemme alt dit arbejde, før du udløser nogen af ​​tilstandene (du bliver nødt til at genstarte bagefter), og gør ikke dette på en andens computer uden formel tilladelse.

---

• SEO Powered Content & PR Distribution. Bliv forstærket i dag.
• Platoblokkæde. Web3 Metaverse Intelligence. Viden forstærket. Adgang her.
• Kilde: https://nakedsecurity.sophos.com/2023/03/13/linux-gets-double-quick-double-update-to-fix-kernel-oops/