Linux-kommando dræber pc

Foto: Jesper Stein Sandal
Taster du en bestemt kode i kommandolinjen på din Linux-maskine, er din pc død.

Som administrator i Linux har du adgang til alt på din maskine, også til at slå den ihjel. Og det er netop, hvad en Linux-bruger er kommet til, skriver digi.no.

Ved at taste koden «rm -rf --no-preserve-root /» i kommandolinjen fik brugeren slettet hele sin Linux-installation, hvilket også var meningen. Hvad der derimod ikke var meningen var, at maskinen nu ikke kunne starte igen.

Kommandoen havde ikke alene slettet Linux-installationen - den havde også erstattet BIOS i maskinen, som derfor ikke længere kunne starte op.

Ifølge en lang debat på The Next Web skyldes problemet formentlig, at den pågældende pc havde lagret konfigurationsoplysninger i mappen (/sys/firmware/efi/efivars/), som maskinen er afhængig af for at kunne starte EFI/UEFI. Kommandoen *rm-rf *havde også slettet denne mappe og dermed adgangen til BIOS.

I en tråd på GitHub diskuterer brugere derfor nu, om det fortsat skal være muligt at skrive sin Linux-maskine ihjel. Men intet i i EFI-specifikationen tyder på, at en sådan fejl er mulig, hvilket indikerer, at fejlen kan ligge i den måde, EFI er implementeret på hos den pågældende maskine.

En fejl, der muligvis også ligger på mange andre maskiner. I debattråden oplyser to brugere nemlig, at de også har oplevet problemet på henholdsvis en Lenovo- og Asus-computer.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk

Kommentarer (22)

Henrik Kramshøj Blogger

De fleste der kender Linux tænker sikkert, lol - det har vi også prøvet. Det har også været sjovt at lokke folk til det, og fint der er kommet ekstra sikring i rm kommandoerne på Unix operativsystemerne, for at undgå det.

Det som dog er mere interessant er at dette afslører hvor dårlig vores hardware er! Faktisk er det en lang saga om EFI/UEFI, mount af samme, snak om storage nedenunder vores OS'er osv.

Vi har reelt ikke kontrollen over vores maskiner fordi der foregår for meget - FØR maskinen begynder at loade OS. Så du kan komme til at brick'e din laptop nemt, hvilket kan være ekstremt svært at reparere, og det kan ske fra software.

Så en hacket server idag er ikke langt fra, både hacket og død - som i du kan ikke boote død, pga. EFI/UEFI problemer. Jeg var til libreboot foredrag i denne weekend, og det er ikke sjovt. Libreboot er en distro af coreboot - og selvom de siger de understøtter " modern computers and embedded systems" - så er det en sandhed med modifikationer.

Læs eksempelvis https://libreboot.org/faq/ specielt
https://libreboot.org/faq/#intelbastards og https://libreboot.org/faq/#amdbastards

Basically, all Intel hardware from year 2010 and beyond will never be supported by libreboot.

og

Libreboot has support for fam15h AMD hardware (~2012 gen) and some older Intel platforms (~2006-2009 gen)

Så ja, du kan få en skodgammel laptop op at køre, som måske kan bruges til at generere dine PGP nøgler "sikkert", men som ikke kan understøtte gængse brugssituationer, som virtualisering og moderne performance :-(

TL;DR vi har ikke fri BIOS på vores moderne CPU og systemer, verden er bygget på lerfødder, vores sikkerhed er i grus. Velkommen til 2016

PS Jeg går for tiden og venter spændt for i denne måned!!!11111 skulle jeg gerne modtage min Librem 15 som bruger "coreboot", det lyder godt. Helt fri for ballade er den dog ikke, for den bruger en del blobs :-( Til gengæld er der mulighed for at de blobs kan udskiftes, og vi ved hvilke blobs det er. Det betyder for mig at hvis man en dag får analyseret dem kan vi gå tilbage og verificere om samme findes i mine blobs osv. osv. Altså det bedste man kan gøre efter min mening nu. Ja, så snart jeg får den kommer der et væld af blog posts, bare rolig. Jeg er også klar til at slås omkring libreboot/coreboot/librem hvorfor jeg er vild med alle tre projekter aligevel osv. :-D

Jimmy Knudsen

Nu vil jeg lige starte med at sige at jeg ikke har forstand på Linux, så beklager hvis det er et dumt spørgsmål: Hvis den ikke kan boote efter du wiper din harddisk, hvad så hvis du er nødt til at skifte harddisken? Vil det ikke også give samme problem? Hvis, så er det da en KÆMPE brøler.

Thomas Sevelsted Lauritzen

"And" som i "og" på engelsk? Eller som i "And" på dansk, underforstået at der er tale om en falsk historie?

Da det ikke er en helt ligegyldig sag at man kan brick'e ens computer ved at slette indholdet fra harddisken, kan det næppe være "og" der menes. For det er da ikke en ".. og hva så..." ting, imo.

Så kan det passe at historien ikke er sand?

Rasmus nix

Undertegnede formåede engang at smadre bootloaderen på en ældre windows xp maskine så motherboardet måtte skiftes. Også kun vha. software.

Daniel Rasmussen

Hvis den ikke kan boote efter du wiper din harddisk, hvad så hvis du er nødt til at skifte harddisken? Vil det ikke også give samme problem? Hvis, så er det da en KÆMPE brøler.


Nej. Kort sagt beder du Linux om at slette alt, også de variabler i UEFI der, når linux er kørende, er mounted i read/write. Det vil sige at Linux sletter noget som reelt set ikke ligger på harddisken, og derfor er det et potentielt kæmpe problem.

For lige at præcisere; problemet er også eksisterende på Windows, en virkelig ondsindet virus kunne gøre det samme, altså skrive til UEFI, fra operativ systemet.

Det er dog kun hvis du benytter UEFI, men det gør de fleste i dag.
De fleste UEFI bundkort kan nulstille de variabler der slettes via en knap på bundkortet, eller en anden metode der kræver fysisk adgang til maskinen.
Det er sgu bare en kende træls hvis man skal betale 1000kr i timen for at få nulstillet UEFIen, hvis man normalt bare kan geninstallere operativsystemet over AMT eller KVM (fjernkontrol som sad du foran maskinen-like).

Steen Poulsen

Skal man lade root kommando "rm -rf -no-preserve-root /" være mulig ? - ja, gud fanden skal man kunne kvaje sig - med vilje ! - root har INGEN restriktioner.

Nå, men man kunne jo overveje at slå "writeprotect" til i sin bios hvis man ikke vil kunne overskrive den.

Eller boote i legacy mode på en usb live, og geninstallere EFI delen.

Jeg har også prøvet at slette EFI indholdet i en PC - øv der røg min Windows 8/10 license - men helt ærligt, hvem savner en Windows 8/10 ?? :-D jeg har jo linux stadigvæk.

Men må jeg foreslå at nøjes med at reinstallere enten Linux eller (hvem der måtte have lyst) Windows ? - det andet har jeg sku aldrig gjort ! (rm -rf -no-preserve-root / - ?? kuk kuk )

Christian Nobel

Hvis man fra Lunix overskriver sin gamle BIOS med skrammel, kan maskinen heller ikke starte op!!1

Jeg er ikke helt med på hvad det nye her er?

Forskellen er at hvis man skal overskrive BIOS data, så kræver det en handling, der eksplicit gør det, men her er der udelukkende tale om hvis man sletter hele disken, vil UEFI data også slettes.

Men ville det samme så ikke også ske ved en formatering, for så kunne man vel sagtens opnå det samme på en Windows maskine, da den vel også gemmer UEFI data på disken?

Thomas Jensen

Det vil sige at Linux sletter noget som reelt set ikke ligger på harddisken, og derfor er det et potentielt kæmpe problem.

Men det er ikke helt det der siges i artiklen.

"den pågældende pc havde lagret konfigurationsoplysninger i mappen (/sys/firmware/efi/efivars/), som maskinen er afhængig af for at kunne starte EFI/UEFI. Kommandoen *rm-rf *havde også slettet denne mappe og dermed adgangen til BIOS."

Umiddelbart lyder det du siger rigtigt, men hvordan kommer mappen /sys/firmware/efi/efivars/ ind i billedet?

Lars Lundin

Forskellen er at hvis man skal overskrive BIOS data, så kræver det en handling, der eksplicit gør det, men her er der udelukkende tale om hvis man sletter hele disken, vil UEFI data også slettes.

Men man sletter jo ikke en disk, mens den er monteret, og slet ikke med den nævnte kommando.

Faktisk kan jeg ikke rigtigt se, hvornår man skulle have en god grund til at udføre rm -rf /.

Jacob Larsen

Umiddelbart lyder det du siger rigtigt, men hvordan kommer mappen /sys/firmware/efi/efivars/ ind i billedet?

Alt under /sys/ er ikke data på harddisken men er Linux kernens map af diverse hardware og driver variable. Normalt vil sådanne ting være read-only, men i dette tilfælde kan man skrive til dem. Jeg gætter på at kompleksiteten i UEFI har gjort det nødvendigt at kunne skrive til dem inde fra Linux.

Peter Makholm Blogger

Umiddelbart lyder det du siger rigtigt, men hvordan kommer mappen /sys/firmware/efi/efivars/ ind i billedet?


Det lader til at folk ikke er helt klar over hvilken funktion UEFI har.

Det er korrekt at UEFI erstatter den BIOS vi traditionelt kender fra IBM-PC. Men på mange måder minder UEFI meget mere om DOS end om BIOSen. Man har en prompt, adgang til filsystemer og man kan køre programmer skrevet til UEFI (oftest specielle programmer der starter et styresystem).

En del af de data UEFI har adgang til ligger enten som key/value-par i en nvram eller på et specielt FAT-filsystem på harddisken. Begge dele kan manipuleres gennem UEFI's kommando-prompt.

For at lette konfiguration af UEFI giver Linux adgang til at tilgå key/value-parene gennem et et filsystem der hedder efivarfs, som normalt er tilgængelig som /sys/firmware/efi/efivars/.

Denne tilgang opfører sig som vidt muligt som et helt normalt filsystem. Det vil sige at man kan åbne og redigere filer og altså også slette dem. Så når man beder Linux om at slette alle filer rekursivt på '/' så bliver efivars selvfølgelig også slettet og dermed ødelægger man sin UEFI.

Man kunne sagtens overskrive son BIOS og dermed på tilsvarende vis ødelægge en BIOS-baseret computer. Men det krævede specielle værktøjer og var ikke lige noget man kom til.

Den uheldige bruger havde en valid use-case: Han ville slette alle filer på harddisken for at lave en ny installation. Desvære har ham muligvis ikke forstået hvordan fil-hierarkiet og filsystemer hænger sammen på unix eller måske tænkte han sig bare ikke om. Den rigtige løsning ville selvfølgelig bare have været at formatere rod-partitionen og lægge en nyt filsystem på, alternativt huske '--one-file-system' flaget til 'rm' for virkelig kun at slette data på den partition man vil slette.

Jeg er ikke på at dette er en historie om hvor dårlig vores hardware er, som Henrik Kramshøj ellers antyder. Men samspillet mellem hardware og software har ændret sig i forhold til den gamle PC-BIOS.

Det vi tidligere opfattede som hardware bliver mere og mere software. Det er naturligt at styresystem-udviklerne ønsker at gøre dette tilgængeligt inde fra styresystemet med den naturlige grænseflade (her som et filsystem).

Martin Kristiansen

Problemet er vel at vedkommende kun har tænkt på at slette root disken. Men med kommandoen pløjes alle devices der er mountet jo igennem og slettes, inklusive eventuelle USB keys, NFS, NTFS mounts etc.

For det første nuker man ikke en root partition på den måde. For det andet skulle han have brugt rm -rf --one-file-system --no-preserve-root / istedet for rm -rf --no-preserve-root /

IMO, er brugeren selv skyld i miseren, han har ikke vidst hvad han har lavet; Det svarer jo til at flashe BIOS med en mp3 fil.

Peter Makholm Blogger

Men ville det samme så ikke også ske ved en formatering, for så kunne man vel sagtens opnå det samme på en Windows maskine, da den vel også gemmer UEFI data på disken?

Som sagt bruger UEFI både data der ligger i en nvram og på disken. I det aktuelle tilfælde at det oplysningerne fra nvram som brugeren er kommet til at slette.

De data UEFI lægger på harddisken er normalt på en speciel partition (EFI System Partition) og vil derfor ikke tage skade af en normal formatering (ala 'format c: eller 'mkfs'). Hvis man repartitionerer sin harddisk kan man selvfølgelig fjerne denne partition. Det bør dog ikke bricke ens bundkort, men kun fjeren den (eller de) UEFI-programmer man bruger for at starte det egentlige styresystem. Man bør stadigvæk bare kunne boote fra en CD eller tilsvarende, eventuelt gennem UEFI-prompten.

Jonas Iversen

Dvs. hvis man ikke har clearet NVRAM'en (som er mappet til en folder) via den omtalte kommando, så kan man roligt skifte harddisk?
UEFI, og den nødvendige konfiguration for at boote, vil i alle tilfælde ligge i NVRAM'en (forudsat at den ikke er clear'et altså).

Nikolaj Brinch Jørgensen

På en Mac kan man resette NVRAM og SMC.
Gad vide om dette eksperiment, med at installere Linux på en Mac og så udføre kommandoen, for derefter at resette NVRAM og SMC, ville bringe den tilbage i live?
I så fald vil der være en model for noget hardware, som er designet til at man ikke brick'er det.
Er der nogen som kender til dette?

En anden ting er, at den kommando der udføres er lidt uforsvarlig, da den jo også sletter netværks-mounts og alt muligt andet udforvarende. måske den der option one-filesystem burde være default, og ikke optional, så man aktivt skal benytte all-filesystems eller lignende.

Det er svært at skyde skylden på brugere for forkert brug (men en ofte benyttet undskyld), når noget er designet forkert ud fra en brugsmæssig synsvinkel. Det virker sært at man med en rimelig simpel kommando kan forårsage så megen ødelæggelse. Det burde være en del mere indviklet, så de få, der virkelig havde brug for det måtte benytte sig af lidt ekstra arbejde og andre ikke udforvarende kom til det.
I bedste fald kan man sige at kommandoen i hvert fald bør advare enhver der udføre den i de potentielle skader der kan ske - er dette ikke tilfældet, efterlader det ikke et særlig positivt indtryk af det pågældende system.

Thomas Andersen

Grunden til at dette dukker op nu er, at systemd i nyere version mounter efivars som read/write, hvor den tidligere typisk var read only. Skiftet til read/write skete fordi man gerne vil kunne genstarte til efi firmware setup fra et kørende system. Det er der ikke noget særligt i. Det har bare afdækket et problem i enkelte stykker hardware, som ikke kan boote hvis specifikke efi vars ikke er sat. For at imødekomme dette problem har Matthew Garrett skrevet en rettelse til linux kernelen, så disse variable ikke kan slettes:
"Block most UEFI variable deletions

Some systems appear to become upset if certain UEFI non-volatile variables are delted, to the point of no longer POSTing successfully. For a short-term fix, let's just block deletion of most variables while we figure out a better approach."
https://gist.github.com/mjg59/8d9d494da56fbe6d8992

Log ind eller opret en konto for at skrive kommentarer