Linux får dobbeltrask dobbeloppdatering for å fikse kjernen Oops!

Linux får dobbeltrask dobbeloppdatering for å fikse kjernen Oops!

Tidsstempel: 13. mars 2023 3:59
Linux får dobbeltrask dobbeloppdatering for å fikse kjernen Oops! PlatoBlockchain Data Intelligence. Vertikalt søk. Ai.
by Paul Ducklin

Linux har aldri lidd av den beryktede BSoD, forkortelse for Blue Screen of Death, navnet gitt til den fryktede "noe gikk veldig galt"-meldingen knyttet til et Windows-systemkrasj.

Microsoft har prøvd mange ting i løpet av årene for å riste det kallenavnet "BSoD", inkludert å endre bakgrunnsfargen som brukes når krasjmeldinger vises, legge til et superstort trist ansiktsuttrykk for å få meldingen til å føles mer medfølende, vise QR-koder som du kan snap med telefonen din for å hjelpe deg med å diagnostisere problemet, og ikke fylle skjermen med en technobabble-liste over kjernekodeobjekter som nettopp tilfeldigvis ble lastet inn på det tidspunktet.

(Disse krasjdumplistene førte ofte til at antivirus- og trusselforebyggende programvare ble klandret for hvert systemkrasj, ganske enkelt fordi navnene deres hadde en tendens til å dukke opp på eller nær toppen av listen over innlastede moduler – ikke fordi de hadde noe å gjøre med krasjet, men fordi de vanligvis lastet tidlig og tilfeldigvis var på toppen av listen, og dermed ble en praktisk syndebukk.)

Enda bedre, "BSoD" er ikke lenger det dagligdagse, forkastelige nedsettende begrepet som det pleide å være, fordi Windows krasjer mye sjeldnere enn det pleide.

Vi antyder ikke at Windows aldri krasjer, eller antyder at det nå er magisk feilfritt; bare å merke seg at du vanligvis ikke trenger ordet BSoD så ofte som du pleide.

Linux-krasjvarsler

Selvfølgelig har Linux aldri hatt BSoDs, ikke engang da Windows så ut til å ha dem hele tiden, men det er ikke fordi Linux aldri krasjer, eller er magisk feilfri.

Det er ganske enkelt det at Linux ikke BSoD (ja, begrepet kan brukes som et intransitivt verb, som i "min bærbare datamaskin BSoDded halvveis gjennom en e-post"), fordi det – i en herlig understatement – ​​lider av en oops, eller hvis ups er alvorlig nok til at systemet ikke pålitelig kan holde seg oppe selv med redusert ytelse, får panikk.

(Det er også mulig å konfigurere en Linux-kjerne slik at en oops alltid bli "forfremmet" til en panikk, for miljøer der sikkerhetshensyn gjør det bedre å ha et system som slår seg brått av, om enn med noen data som ikke blir lagret i tide, enn et system som havner i en usikker tilstand som kan føre til datalekkasje eller datakorrupsjon.)

An oops produserer vanligvis konsollutgang noe sånt som dette (vi har gitt kildekoden nedenfor hvis du vil utforske upses og får panikk for deg selv):

[12710.153112] oops init (nivå = 1) [12710.153115] utløser oops via BUG() [12710.153127] ------------[ kutt her ]------------ [12710.153128] kjernefeil på /home/duck/Articles/linuxoops/oops.c:17! [12710.153132] ugyldig opcode: 0000 [#1] PREEMPT SMP PTI [12710.153748] CPU: 0 PID: 5531 Comm: insmod . . . [12710.154322] Maskinvarenavn: XXXX [12710.154940] RIP: 0010:oopsinit+0x3a/0xfc0 [oops] [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 koblet i: . . . . . [12710.180294] ---[ sluttspor 0000000000000000 ]---

Dessverre, da kjerneversjon 6.2.3 kom ut i slutten av forrige uke, viste to små endringer seg raskt å være problematisk, med brukere som rapporterer kjerneops når de administrerer disklagring.

Kernel 6.1.16 var tilsynelatende gjenstand for de samme endringene, og dermed utsatt for den samme ujevnheten.

For eksempel fungerte det fint å koble til en flyttbar stasjon og montere den, men å demontere stasjonen når du var ferdig med den, kan føre til en oops.

Selv om en oops ikke fryser hele datamaskinen umiddelbart, er kodekrasj på kjernenivå ved avmontering av disklagring bekymringsfulle nok til at en velinformert bruker sannsynligvis vil slå av så snart som mulig, i tilfelle pågående problemer som fører til datakorrupsjon …

…men noen brukere rapporterte at oops forhindret det som er kjent i sjargongen som en ryddig nedleggelse, som krever å slå av strømmen med makt, ved å holde nede strømknappen i flere sekunder, eller midlertidig kutte strømforsyningen til en server.

Den gode nyheten er at kjerner 6.2.4 og 6.1.17 ble umiddelbart løslatt i løpet av helgen for å rulle tilbake problemene.

Gitt hastigheten på Linux-kjerneutgivelser, har disse oppdateringene allerede blitt fulgt av 6.2.5 og 6.1.18, som selv ble oppdatert (i dag, 2023-03-13) av 6.2.6 og 6.1.19.

Hva gjør jeg?

Hvis du bruker en 6.x-versjon Linux-kjerne og du ikke allerede er oppdatert, sørg for at du ikke installerer 6.2.3 eller 6.1.16 underveis.

Hvis du allerede har en av disse versjonene (vi hadde 6.2.3 i et par dager og klarte ikke å provosere en driverkrasj, antagelig fordi kjernekonfigurasjonen vår skjermet oss utilsiktet fra å utløse feilen), vurder å oppdatere så snart du kan...

...fordi selv om du ikke har hatt noen diskvolumbaserte problemer så langt, kan du være heldig, men ved å oppgradere kjernen igjen vil du bli immun av design.

UTFORSK OOPS OG PANIKKEEVENDELSER PÅ DIN EGEN

Du trenger en kjerne bygget fra kildekode som allerede er installert på testdatamaskinen.

Lag en katalog, la oss kalle den /test/oops, og lagre denne kildekoden 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);

Lag en fil i samme katalog som heter Kbuild for å kontrollere byggeparametrene, slik:

 EXTRA_CFLAGS = -Vegg -g obj-m = oops.o

Bygg deretter modulen som vist nedenfor.

De -C alternativ forteller make hvor du skal begynne å lete etter Makefiles, og peker dermed byggeprosessen mot det riktige kjernekildekodetreet, og M= innstillingen forteller make hvor du finner den faktiske modulkoden som skal bygges ved denne anledningen.

Du må gi den fulle, absolutte veien for M=, så ikke prøv å lagre skriving ved å bruke ./ (den nåværende katalogen flyttes rundt under byggeprosessen):

/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 laste og losse den nye oops.ko kjernemodul med parameteren level=0 bare for å sjekke at det fungerer.

Se inn dmesg for en logg over init og exit ringer:

/test/oops# insmod oops.ko level=0 /test/oops# rmmod oops /test/oops# dmesg . . . [12690.998373] oops: laster ut-av-tre-modulen skjemmer kjernen. [12690.999113] oops init (nivå = 0) [12704.198814] oops exit

Å provosere en oops (utvinnbar) eller en panikk (vil henge datamaskinen), bruk level=1 or level=2 henholdsvis.

Ikke glem å lagre alt arbeidet ditt før du utløser noen av tilstandene (du må starte på nytt etterpå), og ikke gjør dette på andres datamaskin uten formell tillatelse.

Tidstempel:

Mer fra Naken sikkerhet