Lastbar kjernemodul - Loadable kernel module

I databehandling er en lastbar kjernemodul ( LKM ) en objektfil som inneholder kode for å utvide den kjørende kjernen , eller den såkalte basiskjernen , til et operativsystem . LKM-er brukes vanligvis til å legge til støtte for ny maskinvare (som enhetsdrivere ) og / eller filsystemer , eller for å legge til systemanrop . Når funksjonaliteten fra en LKM ikke lenger er nødvendig, kan den lastes ut for å frigjøre minne og andre ressurser.

Nyeste Unix-lignende systemer og Microsoft Windows støtte lastbare kjernemoduler under forskjellige navn, for eksempel kjernelastmodul ( KLD ) i FreeBSD , kernel extension ( kext ) i MacOS (nå avviklet), kernel tilleggsmodul i AIX , kernel-modus driver i Windows NT og nedlastbar kjernemodul ( DKM ) i VxWorks . De er også kjent som kjernelastbare moduler (eller KLM ), og ganske enkelt som kjernemoduler ( KMOD ).

Fordeler

Uten kjernemoduler som kan lastes inn, vil et operativsystem måtte inkludere all mulig forventet funksjonalitet samlet direkte i basiskjernen. Mye av denne funksjonaliteten vil ligge i minnet uten å bli brukt, kaste bort minne, og vil kreve at brukere bygger om og starter basiskjernen på nytt hver gang de trenger ny funksjonalitet.

Ulemper

En mindre kritikk av foretrakk en modulær kjerne over en statisk kjerne er den såkalte fragmentering straff . Basiskjernen pakkes alltid ut i ekte sammenhengende minne av oppsettrutinene; dermed blir basiskjernekoden aldri fragmentert. Når systemet er i en tilstand der moduler kan settes inn, for eksempel når filsystemene er montert som inneholder modulene, er det sannsynlig at enhver ny kjernekodeinnføring vil føre til at kjernen blir fragmentert, og derved introduserer en mindre ytelsesstraff ved å bruke flere TLB- oppføringer, noe som forårsaker flere TLB-savner.

Implementeringer i forskjellige operativsystemer

Linux

Lastbare kjernemoduler i Linux lastes inn (og lastes ut) av modprobe- kommandoen. De er lokalisert i / lib / modules eller / usr / lib / modules og har hatt utvidelsen .ko (" kerneobjekt ") siden versjon 2.6 (tidligere versjoner brukte .o- utvidelsen). Kommandoen lsmod viser de lastede kjernemodulene. I nødstilfeller, når systemet ikke starter opp på grunn av f.eks. Ødelagte moduler, kan spesifikke moduler aktiveres eller deaktiveres ved å endre listen over oppstartsparametere for kjernen (for eksempel hvis du bruker GRUB , ved å trykke 'e' i GRUB-startmenyen, og deretter redigering av kjerneparameterlinjen).

Lisensutgaver

I henhold til Linux-vedlikeholdere er LKM avledede verk av kjernen. Linux-vedlikeholdere tåler distribusjon av proprietære moduler, men tillater at symboler blir merket som bare tilgjengelige for GNU General Public License (GPL) -moduler.

Hvis du laster inn en proprietær eller ikke-GPL-kompatibel modul, setter du et "taint" -flagg i den kjørende kjernen - noe som betyr at eventuelle problemer eller feil som oppleves, vil mindre sannsynlig bli undersøkt av vedlikeholdere. LKM blir effektivt en del av den kjørende kjernen, så kan ødelegge kjernedatastrukturer og produsere feil som kanskje ikke kan undersøkes hvis modulen virkelig er proprietær.

Linuxant kontrovers

I 2004 forsøkte Linuxant, et konsulentselskap som frigjør proprietære enhetsdrivere som lastbare kjernemoduler, å misbruke en null-terminator i sin MODULE_LICENSE, som synlig i følgende kodeutdrag: 

MODULE_LICENSE("GPL\0for files in the \"GPL\" directory; for others, only LICENSE file applies");

Strengsammenligningskoden som ble brukt av kjernen på det tidspunktet, prøvde å avgjøre om modulen ble GPLed stoppet da den nådde et nulltegn ( \ 0 ), så det ble lurt til å tro at modulen erklærte sin lisens for å være "GPL" .

FreeBSD

Kjernemoduler for FreeBSD lagres i / boot / kernel / for moduler distribuert med operativsystemet , eller vanligvis / boot / modules / for moduler installert fra FreeBSD-porter eller FreeBSD-pakker , eller for proprietære eller på annen måte bare binære moduler. FreeBSD-kjernemoduler har vanligvis utvidelsen .ko . Når maskinen har startet opp, kan de lastes med kldload- kommandoen, lastes ut med kldunload og oppføres med kldstat . Moduler kan også lastes fra lasteren før kjernen starter, enten automatisk (gjennom /boot/loader.conf ) eller for hånd.

Mac os

Noen kjernemoduler som kan lastes inn i macOS, kan lastes automatisk. Lastbare kjernemoduler kan også lastes inn med kommandoen kextload . De kan oppføres ved hjelp av kommandoen kextstat . Lastbare kjernemoduler ligger i bunter med utvidelsen .kext . Moduler som leveres med operativsystemet er lagret i / System / Library / Extensions- katalogen; moduler levert av tredjeparter finnes i forskjellige andre kataloger.

NetWare

En NetWare-kjernemodul blir referert til som en NetWare Loadable Module (NLM). NLMer settes inn i NetWare-kjernen ved hjelp av LOAD-kommandoen, og fjernes ved hjelp av UNLOAD-kommandoen; de modulene kommandoen lister lastet inn for øyeblikket kjernemoduler. NLM-er kan ligge i hvilken som helst gyldig søkesti som er tildelt på NetWare-serveren, og de har .NLM som filtypenavn.

VxWorks

Et nedlastbart prosjekt av kjernemodul (DKM) kan opprettes for å generere en ".out" -fil som deretter kan lastes til kjerneområdet ved hjelp av "ld" -kommandoen. Denne nedlastbare kjernemodulen kan lastes ut ved hjelp av "unld" -kommandoen.

Solaris

Solaris har en konfigurerbar innlastingsbane for kjernemodul, den er som standard / platform / platform-name / kernel / kernel / usr / kernel . De fleste kjernemoduler lever i underkataloger under / kernel ; de som ikke anses som nødvendige for å starte systemet til det punktet at init kan starte, er ofte (men ikke alltid) funnet i / usr / kernel . Når du kjører en DEBUG-kjerne, prøver systemet aktivt å laste ned moduler.

Binær kompatibilitet

Linux gir ikke et stabilt API eller ABI for kjernemoduler. Dette betyr at det er forskjeller i intern struktur og funksjon mellom forskjellige kjerneversjoner, noe som kan forårsake kompatibilitetsproblemer. I et forsøk på å bekjempe disse problemene plasseres symbolversjonsdata i .modinfo- delen av lastbare ELF- moduler. Denne versjonsinformasjonen kan sammenlignes med informasjonen til den kjørende kjernen før du laster inn en modul. hvis versjonene er inkompatible, vil ikke modulen lastes inn.

Andre operativsystemer, som Solaris , FreeBSD , macOS og Windows, holder kjernen API og ABI relativt stabil, og unngår dermed dette problemet. For eksempel fungerer FreeBSD- kjernemoduler som er kompilert mot kjerneversjon 6.0, uten rekompilering på noen annen FreeBSD 6.x-versjon, f.eks. 6.4. De er imidlertid ikke kompatible med andre store versjoner og må kompileres på nytt for bruk med FreeBSD 7.x, ettersom API og ABI-kompatibilitet bare opprettholdes innenfor en gren.

Sikkerhet

Selv om innlastbare kjernemoduler er en praktisk metode for å modifisere den kjørende kjernen, kan dette misbrukes av angripere på et kompromittert system for å forhindre deteksjon av deres prosesser eller filer , slik at de kan opprettholde kontrollen over systemet. Mange rootkits bruker LKM på denne måten. Merk at moduler på de fleste operativsystemer ikke hjelper privilegieheving på noen måte, ettersom forhøyet privilegium kreves for å laste inn en LKM; de gjør det bare lettere for angriperen å skjule innbruddet.

Linux

Linux tillater deaktivering av modulinnlasting via sysctl- alternativet /proc/sys/kernel/modules_disabled. Et initramfs- system kan laste inn spesifikke moduler som trengs for en maskin ved oppstart, og deretter deaktivere modulinnlasting. Dette gjør sikkerheten veldig lik en monolitisk kjerne. Hvis en angriper kan endre initramfs, kan de endre binærkjernen.

Mac os

I OS X Yosemite og senere utgivelser, må en kjerneforlengelse kodesigneres med et utviklersertifikat som har en bestemt "rettighet" for dette. Et slikt utviklersertifikat leveres bare av Apple på forespørsel og blir ikke automatisk gitt til Apple Developer- medlemmer. Denne funksjonen, kalt "kext-signering", er aktivert som standard og den instruerer kjernen om å stoppe oppstart hvis usignerte kjerneutvidelser er til stede. I OS X El Capitan og senere utgivelser er det en del av System Integrity Protection .

I eldre versjoner av macOS, eller hvis kext-signering er deaktivert, kan en lastbar kjernemodul i en kjerneforlengelsespakke lastes inn av ikke-root-brukere hvis egenskapen OSBundleAllowUserLoad er satt til True i pakkeens eiendomsliste. Imidlertid, hvis noen av filene i pakken, inkludert den kjørbare kodefilen, ikke eies av rot- og gruppehjul, eller kan skrives av gruppen eller "annet", vil forsøket på å laste inn den kjernelastbare modulen mislykkes.

Solaris

Kjernemoduler kan valgfritt ha en kryptografisk signatur-ELF-seksjon som bekreftes ved belastning, avhengig av innstillingene for bekreftet oppstart. Kjernen kan håndheve at moduler er kryptografisk signert av et sett med pålitelige sertifikater; listen over pålitelige sertifikater holdes utenfor operativsystemet i ILOM på noen SPARC-baserte plattformer. Innlasting av kjernemodul som initieres av brukerområdet er bare mulig fra den klarerte banen når systemet kjører med funksjonen Immutable Global Zone aktivert.

Se også

Referanser