"Externe" module in een monolithic kernel bakken

[Osiris]

Proloog(Lees: semi-nutteloze informatie.)
Op mijn servertje draai ik al een tijdje Gentoo en met plezier welteverstaan. Ook gebruik ik een monolithic kernel. Geen probleem. Geen issues met modules, modprobe, lijst met modules die geladen moet worden bij het booten, gewoon lekker clean en simpel: werkt het? Dan werkt het en dan werkt het probleemloos. Zo ook mijn servertje. Ding draait heerlijk monolithic uit z'n neus te vreten. Dit gaat niet veranderen, enige discussie omtrent dit gebeuren hoef je niet mee aan te komen. Zo ben ik bijv als wijze van "omdat het kan!" bezig met Hardened Gentoo, waarbij ook je /dev/(k)mem e.d. dichtgetimmerd wordt, gewoon je servertje lekker zo secure mogelijk krijgen, wederom, "omdat het kan". Zie het als een experiment.

Het probleem
Ik heb een USB webcam-geval welke "prima" werkt met de GSPCA-driver. Die zit prachtig in Portage en kun je gewoon `emerge`-en zodat je een kernel-module geleverd krijgt. Maar daar zit hem nu net het probleem, die module gaat natuurlijk nevernooitniet werken.

De (voorgestelde) oplossing
Nou, dat lijkt me "simpel". Een custom "patch" schrijven die "ff" de GSPCA-driver "in" de kernel bakt. Zou toch niet zó moeilijk kunnen zijn? Van een standaard-driver een module maken lijkt me lastiger, dus dan is andersom wel simpel Helaas, in mijn zoektocht bleek het niet zó simpel te zijn. (Probeer daar maar eens op te Googlen, uiteraard krijg je alleen maar 'hoe bak/maak ik een module' als resultaten )

Wat ik al geprobeerd heb
Nou, ik dacht, we pakken het zooitje gewoon eventjes uit en kopiëren alle broncode van "/var/tmp/portage/media-video/gspcav1-20071224/work/gspcav1-20071224/" naar de nieuwe map "/usr/src/linux/drivers/media/video/gspca/". Vervolgens nemen we "gewoon" even een kijkje in een map van een collega-driver zoals "../sn9c102/".

Wat zien we bijvoorbeeld daar?:

 1x: [i]built-in.o[/]
 1x: [i]Kconfig[/]
 1x: [i]Makefile[/]
 4x: diverse [i].h[/]-files
13x: diverse [i].c[/]-files

Die Kconfig en Makefile zien er vrij belangrijk uit. De laatste had de gspca-map al wel uiteraard, maar die eerste nog niet.

Nu staat daar niet zoveel boeiends in:

config USB_SN9C102
        tristate "USB SN9C1xx PC Camera Controller support"
        depends on VIDEO_V4L2
        ---help---
        Blabla

Dus die C/P-en we gewoon eventjes naar de gspca-map, veranderen USB_SN9C102 eventjes naar USB_GSPCA en klaar.

Kijken we naar de SN9C102-Makefile, dan zien we 't volgende:

sn9c102-objs := sn9c102_core.o \
                [me]knip *[/]
                sn9c102_tas5130d1b.o

obj-$(CONFIG_USB_SN9C102)       += sn9c102.o

Een hele lijst objecten en een obj-[y/m] op 't einde. Nou, dat kan een kind nog wel fixen.

Dus ik heb het module-gebeuren uit die GSPCA-Makefile verwijdert en hem gereduceerd tot:

VERSION    = 01.00.20

DEFINES    =
DEFINES   += -DGSPCA_ENABLE_DEBUG
#DEFINES   += -DGSPCA_ENABLE_REGISTERPLAY
DEFINES   += -DGSPCA_ENABLE_COMPRESSION
DEFINES   += -DVID_HARDWARE_GSPCA=0xFF -DGSPCA_VERSION=\"$(VERSION)\"

EXTRA_CFLAGS += $(DEFINES)

gspca-objs := gspca_core.o decoder/gspcadecoder.o
obj-$(CONFIG_USB_GSPCA) += gspca.o

('t Een en ander aan commentaar niet mee-geC/P'd)

Aangezien de originele Makefile ook slechts zo weinig qua objecten deed leek me het wel voldoende.

Enige wat nu nog hoefde, mijn inziens, was het toevoegen van de line 'source "drivers/media/video/gspca/Kconfig"' aan /usr/src/linux/drivers/media/video/Kconfig, zodat de driver ook in `make menuconfig` voor zou komen.

De issues die er nog zijn
Nu is diezelfde `make menuconfig` nogal weerbarstig. Zo staat de driver er prima in, maar alleen als module? Idem ditto voor de SN9C102-driver overigens, ik snap niet waarom. Willekeurig andere module die wel "in" de kernel kan heeft dezelfde Kconfig?

Module is prima te vinden in:

-> Device Drivers
  -> Multimedia devices
    -> Video For Linux (VIDEO_DEV [=m])
      -> Video capture adapters (VIDEO_CAPTURE_DRIVERS [=y])

VIDEO_DEV op '=y' zetten heeft geen nut. Ook de `.config` handmatig op =y zetten heeft geen nut.

Toen ik dat laatste had gedaan en `make` draaide, sloeg ie 'em gewoon over Sterker nog, de complete source is ook verdwenen uit de desbetreffende driver-map

Kortom, ik heb geen flauw idee meer waar ik tegenaan loop en hoe ik verder moet

Wellicht moet ik ook wel vanalles aanpassen in de .c-files, géén idee Bij gebrek aan How-To's ben ik gewoon wat gaan prutsen aan dingen waar ik absoluut geen verstand van heb, maar dat was al wel duidelijk geloof ik

[eghie]

Je hebt de module nu als module geintergreert in de code. Nu kun je de module mee distribueren met de kernel source. Maar dit maakt hem nog geen geïntegreerde driver. Wat daar voor nodig is weet ik zo niet, maar dat ga ik even opzoeken.

[Osiris]

eghie schreef op vrijdag 18 april 2008 @ 16:59:
Je hebt de module nu als module geintergreert in de code. Nu kun je de module mee distribueren met de kernel source.Maar dit maakt hem nog geen geïntegreerde driver.

De meeste device drivers kunnen naar mijn weten als beide gebruikt worden. Wat maakt een driver een module of geïntegreerde driver dan? Vanuit het `make menuconfig`-point-of-view alleen de 'm' of '*' en vanuit de `.config`-point-of-view alleen 'CONFIG_USB_DRIVERNAME=m' of 'CONFIG_USB_DRIVERNAME=y', right?

eghie schreef op vrijdag 18 april 2008 @ 16:59:
Wat daar voor nodig is weet ik zo niet, maar dat ga ik even opzoeken.

Dat zou fijn zijn, want ik snap dr geen biet van

[daft_dutch]

modules worden geladen er zijn load/unload commandos en zo.
ook moet je die modules ook kunnen loaden dus als nog de module load ability toe te voegen.

of daar omheen schijven.
hack on:)

[Osiris]

daft_dutch schreef op dinsdag 22 april 2008 @ 21:56:
modules worden geladen er zijn load/unload commandos en zo.
ook moet je die modules ook kunnen loaden dus als nog de module load ability toe te voegen.

of daar omheen schijven.
hack on:)

Ehm, lees nog eens goed Het zou eerder zijn "dus alsnog de module load ability verwijderen", aangezien ik 't geheel juist niet als module wil

[daft_dutch]

Osiris schreef op dinsdag 22 april 2008 @ 22:00:
[...]

Ehm, lees nog eens goed Het zou eerder zijn "dus alsnog de module load ability verwijderen", aangezien ik 't geheel juist niet als module wil

Ik weet weinig van kernel hacken. Ik weet wel dat een module systemen heeft voor het laden ontladen van de module. daar moet je omheen werken

[DeKaerften]

Je probleem is opgelost, want er is nu de Hot patch tool!

[phobosdeimos]

Osiris, elke linux kernel is monolithisch. Dat heeft niks te maken met het feit of je je drivers in de kernel compileert, of als module gebruikt.
En je zit je moe te maken om niks, want of je die driver nu inbakt of als module gebruik, heeft geen enkel verschil, voordeel of nadeel. Je bent gewoon problemen aan het zoeken waar er geen zijn.

[ Voor 40% gewijzigd door phobosdeimos op 26-04-2008 15:37 ]

[DeKaerften]

@phobosdeimos:

Natuurlijk zijn er wel verschillen. Een microkernel is flexibeler wat betreft hardware ondersteuning: er kan een module toegevoegd worden wanneer er nieuwe hardware aangesloten wordt, waardoor de kernel niet opnieuw gecompiled hoeft te worden. Bovendien hoeft dan niet alles op kernel-mode te draaien, maar kunnen bepaalde dingen ook in user-mode blijven. Een voordeel van een monolithic kernel is bijvoorbeeld dat het een prestatievoordeel biedt: Er zijn geen onnodige dingen geladen maar alles wat nodig is is sowieso geladen.

[phobosdeimos]

GuitarWeed: fout, linux is een monolithische kernel.
Ook al gebruik je geen enkele module, DAN NOG is linux een monolithische kernel, en geen microkernel!
Ik sta hier niet te beweren dat er geen verschil is tussen een microkernel en een monolithische kernel, verre van, ik zit simpelweg te wijzen op het feit dat linux van nature GEEN MICROKERNEL IS, maakt niet uit of je 0 modules gebruikt of 120.

[Jordi]

Dat is allemaal leuk en aardig, maar volgens mij wil Osiris gewoon geen loadable module support in z'n kernel hebben, vermoedelijk om bv. geen een stuk lastiger rootkit modules te kunnen laten laden, waarmee je een attack vector afdekt. Dat je dat geen zinvolle tijdsbesteding vindt, geloof ik direct, maar als hij zelf al aangeeft dat hij daar redenen voor heeft -al was het alleen maar om het experiment-, is het natuurlijk een beetje flauw om te zeggen dat er problemen gezocht worden waar die niet zijn. Je monolithic kernel vs. microkernel verhaal is helemaal waar, maar daarmee is Osiris in dit verband natuurlijk niet geholpen (ook al noemt hij deze opzet onterecht "monolithic")

Overigens heb ik het eventjes vlugjes geprobeerd, maar als ik eenmaal V4L ook op Y zet, is die GSPCA module ook gewoon op Y te krijgen bij mij. Of het allemaal ook echt werkt, weet ik niet (alleen mijn laptop heeft een cam en erg veel zin in gepruts heb ik niet echt), maar het compilet in elk geval wel allemaal hier.

[eghie]

En als je de optie "Enable loadable module support" uitzet dan? Krijg je dan die optie wel?

Het heeft ook vooral met je Kconfig te maken:

config USB_SN9C102
        tristate "USB SN9C1xx PC Camera Controller support"
        depends on VIDEO_V4L2

Die tristate geeft aan dat die module uit kan, als module kan en helemaal ingebakken kan. Heeft dus 3 standen, vandaar dat hij tristate heet. Als je daar bool van maakt kan hij alleen maar aan of uit.

Wat me opvalt is dat die tristate wordt bepaald en ook bepaald wat de dependencies doen. Dus als VIDEO_V4L2 als module aan staat, moet deze ook als module gecompiled worden en kan hij niet er vast in worden gezet. Zet v4l driver eens op ingebakken. Dat zou kunnen helpen.

[Borromini]

Sowieso zal je de driver niet statisch kunnen meecompileren als dingen waar hij van af hangt (zoals v4l 2) als modules gecompileerd worden. Heb je loadable modules support compleet uitstaan btw? Ik heb nog nooit een compleet statische kernel gecompileerd, mij lijkt het dat je met die optie uitgeschakeld geen drivers modulair kan compileren?

Normaal gezien (ik heb ook al driver patches gebrouwen voor 2.6 kernels) kan je ook DEFAULT=y proberen in de Kconfig file (of zoiets...).

[phobosdeimos]

Jordi schreef op zaterdag 26 april 2008 @ 18:43:
Dat is allemaal leuk en aardig, maar volgens mij wil Osiris gewoon geen loadable module support in z'n kernel hebben, vermoedelijk om bv. geen een stuk lastiger rootkit modules te kunnen laten laden, waarmee je een attack vector afdekt. Dat je dat geen zinvolle tijdsbesteding vindt, geloof ik direct, maar als hij zelf al aangeeft dat hij daar redenen voor heeft -al was het alleen maar om het experiment-, is het natuurlijk een beetje flauw om te zeggen dat er problemen gezocht worden waar die niet zijn.

Iemand die modules kan inladen in je kernel, heeft root toegang op je server, en dan is het zowiezo game over.
Als de attacker per sé een rootkit wil toevoegen hercompileert ie desnoods de kernel naar zijn smaakt, met modules, aangezien hij toch al root heeft.
Even zinvol als het verplaatsen van je ssh poort op een ander nummer.

[eghie]

phobosdeimos schreef op maandag 28 april 2008 @ 17:23:
[...]


Iemand die modules kan inladen in je kernel, heeft root toegang op je server, en dan is het zowiezo game over.
Als de attacker per sé een rootkit wil toevoegen hercompileert ie desnoods de kernel naar zijn smaakt, met modules, aangezien hij toch al root heeft.
Even zinvol als het verplaatsen van je ssh poort op een ander nummer.

Is dat een excuus om dat maar niet te doen dan? Geen toegang tot compile tools en download tools en het tegengaan van SFTP en SCP erbij, wil je ook wel een hele eind op weg helpen. Zo te zien is Osiris ook aan het experimenteren daarmee, dus altijd leuk om te proberen.

[Jordi]

phobosdeimos schreef op maandag 28 april 2008 @ 17:23:
[...]
Iemand die modules kan inladen in je kernel, heeft root toegang op je server, en dan is het zowiezo game over.
Als de attacker per sé een rootkit wil toevoegen hercompileert ie desnoods de kernel naar zijn smaakt, met modules, aangezien hij toch al root heeft.

Natuurlijk ben je allang de sjaak als iemand anders root heeft gekregen... het wordt alleen nog vervelender als je dat uiteindelijk niet door hebt! Maar nog los hier allemaal van en dat zo'n custom compile met een reboot erachteraan opvalt...
Je snapt het nog niet helemaal geloof ik. Het gaat er hier niet om dat de boel hermetisch afgesloten wordt, maar dat een gemakkelijke manier van vrij onopvallend custom code in je kernel gepropt krijgen dichtgekit wordt, in dit geval ook nog eens als experiment, voor de lol, om de regenachtige zondag maandag mee door te komen. Dat jij of wie dan ook het niet zo zinvol vindt, wil nog niet zeggen dat het daarom maar niet gedaan hoeft te worden. Dat dit niet de heilige graal in beveiliging is, moge duidelijk zijn.