Hur fungerar mmap ' ing / dev / mem trots att det befinner sig i okontrollerat läge?
On februari 9, 2021 by adminSåvitt jag förstår går användarutrymme-program i okontrollerat läge och har därmed inte direkt tillgång till minne eller I / O.
Hur exakt kan vi då direkt komma åt minne eller I / O-platser när vi mmap / dev / mem i användarutrymme-program?
Till exempel:
int fd = 0; u8 leds = 0; fd = open("/dev/mem", O_RDWR|O_SYNC); leds = (u8 *)mmap(0, getpagesize(), PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0x80840000);
Detta är ett hack som vanligtvis används i inbäddade enheter.
Nu kan variabeln leds
användas direkt för att komma åt vilken enhet som helst som kan finnas på 0x80840000.
Vi kommer inte att använda något systemanrop för att komma åt den adressen längre.
Till och med något som
leds[0x20] = val;
skulle fungera.
Men privilegierade operationer, som att läsa / skriva direkt till / från en I / O-adress, borde bara vara möjliga genom att sätta processorn i privilegierat läge genom ett systemanrop.
Källa .
Kommentarer
har inte alla privilegier i systemläge (kör mest privilegierade instruktioner).
Svar
Tillåter åtkomst till /dev/mem
av okontrollerade processer skulle verkligen vara ett säkerhetsproblem och borde inte tillåtas.
På mitt system ser ls -l /dev/mem
ut så här:
crw-r----- 1 root kmem 1, 1 Sep 8 10:12 /dev/mem
Så root
kan läsa och skriva det, medlemmar av kmem
grupp (av vilken det råkar finnas ingen) kan läsa den men inte skriva den, och alla andra kan inte öppna den alls. Så detta borde vara säkert.
Om din /dev/mem
är något som min, skulle din oprivierade process inte ens ha kunnat öppna filen alls, än mindre mmap
det.
Kontrollera behörigheterna för /dev/mem
på ditt system för att se till att de är säkra!
Kommentarer
- Men förutsatt att jag gör detta som root … Betyder det att en process som drivs av root får kärnan nivååtkomstbehörigheter?
- Tja, om du ' gör det här som root så har du tillgång till allt. Jag ' är inte säker på vad du menar med " åtkomstbehörigheter på kärnnivå " root kan verkligen göra vad som helst, på ett eller annat sätt (särskilt till exempel genom att skapa och dynamiskt ladda en ny kärnmodul).
- Ja, att ' s korrekt: när du mappar en fil får du sedan läsa & skriva filen utan att använda ststemanrop. Det ' stämmer oavsett om du ' har kartlagt en vanlig diskfil eller en speciell enhet som
/dev/mem
. Om du föredrar kan du öppna/dev/mem
och utfärdaread()
ochwrite()
systemanrop. Då skulle du inte skicka I / O utan att använda systemanrop. Slutresultatet är detsamma, men om du har massor av små I / O att göra,mmap()
och direktåtkomst kommer förmodligen att fungera bättre specifikt eftersom du inte ' behöver inte systemanrop! Detta gäller även för vanliga filer! - @ Stark07 Jag tror att du ' har missat poängen.
mmap
(och/dev/mem
) ger INTE direkt åtkomst till systemminne, och det är omöjligt att göra det i Ring 4. Vad det gör istället är att bara mappa en fil (eller resurs) till en specifik virtuell adress i samtalsprocessen, precis som vad som händer när ett program laddas /exec
ed (i det här fallet är programbildenmmap
redigerad till det virtuella minnet). - TL; DR En okontrollerad process har inte direkt tillgång till systemresursen, men kan göra det när den resursen mappas till deras virtuella adressutrymme . Det finns ' ingen skillnad mellan åtkomst till sin stack / heap / rodata / överhuvudtaget och åtkomst till kärnminne – De får så småningom åtkomst till det faktiska fysiska minnet, medan det senare fallet råkar vara under program ' s kontroll.
Svar
Synliga adresser till en användarprocess (oavsett om den körs som root eller en icke-civiliserad användare) är virtuella adresser som mappas till fysiska adresser av MMU genom sidtabellerna. Att ställa in sidtabellerna är en privilegierad operation och kan endast utföras med kärnkod. när sidtabellerna är inställda är åtkomst till minnet dock tillåtet i användarläge.
Konkret använder din kod mmap
för att begära att kärnan ställer in sidtabeller för att ge åtkomst till ett visst fysiskt minne. Kärnan kontrollerar processens privilegier (den har läs- / skrivåtkomst till /dev/mem
) och ställer in sidtabellerna så att den får åtkomst till fysiskt minne.
Svar
Värdet av leds
är en virtuell adress. Så länge det finns i användarutrymmet för den aktuella processen kan processen komma åt den direkt via instruktioner som leds[0] = val
utan att behöva vara i privilegierat läge, oavsett var i RAM den virtuella adressen är mappad till
*
i deklarationen avleds
, men att ' bara kodar, inga bevis för att detta faktiskt fungerar som en privilegierad användare, i min (begränsade) erfarenhet går allt som rot på inbäddade enheter.root
-användaren har många behörigheter, som inkluderar att tillåta att åsidosätta traditionella behörigheter för filsystem. Vissa " -filer " har verkligen tillgång till enheter (som disk eller minne), vilket är begränsat för vanliga användare. Interoot
. Menroot
körs i användarutrymme , så det <