Svenska ElektronikForumet

Något jag funderat på ett tag men inte känner att jag förstått helt.

Om jag skriver kod som direkt avrefererar en pekare och försöker skriva så kan ett OS upptäcka att adressen är något jag inte ska ha tillgång till eller som inte är allokerad. Är det här något som kräver stöd av hårdvara som egentligen är vad som håller koll och bara skickar ett interrupt till operativsystemet?

MMU, ja det kräver hårdvarustöd.

https://en.wikipedia.org/wiki/Memory_management_unit

Finns även andra sätt att skydda access också, vissa STM32 har något de kallar Firewall.
Du kör OS:et på en nivå och tråden t.ex. i en annan OS:et sätter upp var du får tillgång till.
http://www.st.com/resource/en/product_t ... rewall.pdf
Firewall är lite mer brutal, Device reset vid felaktig access...

Finns nog fler sätt att lösa det på...

Edit: På vissa Arm så finns ARM Trustzone också, den kan även förhindra access på fel ställen https://genode.org/documentation/articles/trustzone

Japp. MS Windows och de flesta Unix och Linux på moderna processorer med MMU delar upp hela minnet i "pages" (sidor). MMU:ns sidor är vanligtvis 4096 bytes, men kan ibland vara större.
För varje process finns en "page table" i operativsystemets minnet med mappningar från virtuell adress till fysisk adress för varje sida på virtuell adress i processen. Endast de högre bittarna används: de 12 lägre bittarna (för en storlek på 4096 = 2¹²) är oförändrade.

Dessa page tables brukar inte vara rena arrayer, utan trädstruktur i flera steg indexerad på virtuell adress, och organiserade så att varje del av en "page table" själv tar upp precis en sida. På det sättet tar dessa page tables inte upp jättemycket minne (men det blir ganska mycket ändå).
I en sidas info-struktur ("page table entry") brukar det finnas en bit som säger om sidan är giltig, och också bittar som säger om den är t.ex. skrivskyddat.

Försök till åtkomst till adress i en sida som är märkt som ogiltig eller som inte finns i tabellen leder till ett s.k. "Page fault": en "exception", liknande en "trap" eller interrupt till operativsystemet.
Försök till skrivning till skrivskyddad sida eller körning av program i exekverings-skyddad sida ger också "page fault".
Page tables ligger alltså i minnet, men processorn själv cache:ar delar av tabellen i sin TLB ("translation lookaside buffer"). De flesta processorer sköter åtkomst och cache:ning av page-tabellen i sin TLB automatiskt.

Förr i tiden, innan "paging" slagit igenom så använde processorer istället "segmentering" för minnesskydd.
Varje segment pekade på ett adress-omfång i det fysiska minnet: Start-adress och storlek. Det brukade vara uppdelade i t.ex. ett segment för kod, ett för data och ett för stack. Ett åtkomstförsök till en adress utanför ett segment ledde till ett "Segmentation Fault" eller "segfault".
Denna uppdelning och terminologi lever kvar även i moderna Unix och Linux, trots att de egentligen gör "paging". T.ex. när ett program försöker sig på en otillåten minnesåtkomst så reses signalen "SIGSEGV".
En annan detalj är att operativsystem ofta gör sidor "ogiltiga" med flit för att kunna mäta hur ofta program använder olika sidor: Detta brukar dock inte märkas av programmet, men det kan leda till kryptiska meddelanden på vissa ställen i t.ex. administrationsprogram i Windows.

När malloc() och operator new() (och motsvarande i andra språk än C och C++) ska allockera minne så försöker de först att använda minnesområden som programmet redan har men inte använder. (och det finns många olika invecklade algoritmer för att göra det ....)
Om det inte finns tillräckligt så måste det be om mer minne från operatiivsystemet.
I Unix och Linux brukar utökning av ett programs minne ske på ett av två sätt:
• Man ökar storlek på programmets datasegment. Se man-sidan för "brk". Detta "segment" består numera av en mängd hela sidor på löpande addresser i page table:n.
• Programmet minnesmappar nya sidor från filen "/dev/null". Se man-sidan för "mmap". (Ganska bakvänd konvention egentligen ). En minnesmappning sker i antal hela sidor på löpande adresser, utanför datasegmentet.
Varje bibliotek som länkas in i programmet när det startar brukar också minnesmappas, förresten.
Jag har inte stor koll på Windows, men jag tror att det fungerar enligt liknande principer men använder andra termer här och där.

Det ska tilläggas att den största skillnad mellan '286 och '386 var att den senare fick just en MMU inbyggt, just för detta med att kunde skydda de olika programmer mot varandra.

Det kan också tilläggas att trots att övriga världen hade det så saknade såväl W95,W98 och ME fungerande minnesskydd, NT hade det men var inte avsett för hemanvändare, det var först W2000 som fick det.

Icecap skrev:Det ska tilläggas att den största skillnad mellan '286 och '386 var att den senare fick just en MMU inbyggt, just för detta med att kunde skydda de olika programmer mot varandra.

Man an väl i så fall tillägga att en 286 visst hade MMU inbyggd. Inte en Paging MMU utan en segmenterings MMU. Fast lika fullt kunde den skydda minne från access beroende på hur man ställde in segment descriptorerna. Säger inte att det var lätt... En 286a i protected mode kan adressera 1 Gigabyte virtuellt minne, medan den fysiska rymden var 16 Mbyte.

https://en.wikipedia.org/wiki/Intel_80286

Sedan kom väl Intel på att paging är trevligare i många fall än segmentering.

Nja. 386:an och alla x86:or i 32-bittarsläge sen dess använder en kombination av paging och segmentering. Hårdvaran tillåter både en ren segment-modell och ren paging-modell. Jag har för mig att en variant av Multics minnesmodell (paging inuti varje segment) skulle vara möjlig i 32-bittars x86, men med ett ganska lågt tak på segment-storlek.

Det var AMD som senare valde att inte ha med segmentering i x86-64.
Vill man ha "16-bittarsprogram" eller segmentering i "32-bittars" x86-program så är man förvisad till att köra dessa i en virtuell maskin.

Om det finns mmu, varför tar minnet slut
ibland då, när program läcker minne,
även om man stänger av dom?

Det kan ha med fragmentering av det det minne som är tillgängliga för dynamisk allokering.
Alltså allokering utöver det som allokeras permanent då OS'et bootar. Svårt att säga
något närmare om det utan att veta vilket OS som det avser.

Minnet som finns tillgängligt för OS'et att dela ut är ju först "en stor block". Sedan delas det ut till de olika processer och om de inte "lämnar tillbaka" minnet kan det ju inte friges och lämnas åt andra processer.

Memory-leak sker ju typisk vid att en programmör begär minne åt en variabel - men inte lämnar tillbaka den efter bruk. Om samma delprocess upprepas begärs det alltså minne som fan men inget lämnas tillbaka - och någonstans på vägen tar det slut.

Fast minnesfragmentering borde väl inte vara ett problem med en virtuell minnesmodell ? då har man ju ett lager mellan fysiskt minne och blocken som programmen får ?


Sen har jag en känsla av att windows fuskar med garbage collection eller nåt, för det verkar försvinna minne även när man dödar urspårade processer, ett problem man sällan ser i *IX.

Någonstans allokeras det ändå fysiskt minne. Men visst, OS'et borde ju allokera av allt minne som
tillhör en process om en process dör. Jag trodde att minnesläckor enbart är ett problem så länge
som processen lever, om inte läckan är i en del av OS'et, så klart.

Visst gör det det, men det är ju ändå random access ? OS'et borde väl hantera det sömlöst med hjälp av MMU så att processerna inte ser nån skillnad ?

Jag ska inte påstå att jag är expert på detta dock, men det är intressant.

..Ska ta diskussionen med en bekant som har skriviyt ett halvt OS själv tror jag..

Ja, processerna ser ingen skillnad så länge som det finns (går att) allokera minne.
Det är OS'et som kan få problem om vissa minnesstrukturer blir för fragmenterade.
Och då kommer i och för sig även processerna att få något slags fel tillbaka...

Sen så skiljer det nog mycket i hur olika OS hanterar det också...

Glenn skrev:Fast minnesfragmentering borde väl inte vara ett problem med en virtuell minnesmodell ? då har man ju ett lager mellan fysiskt minne och blocken som programmen får ?

Menar du att minnet "stuvas om" för att att få större sammanhängande ledigt minne?
Har virtuella maskinen tid/möjlighet att göra det medan programmet körs?

Vi kan utgå från mitt exempel ur en annan tråd:
Låt säga att programmet har 400 byte heap. Programmet allokerar matris1, 100byte, följt av matris2, 200 byte. Då är 300 av 400 byte upptagna, 100 byte ledigt. matris1 har adressen heap_start, och matris2 heap_start + 100. Efter detta frigör programmet matris1. 200 av 400 byte är nu upptagna, d.v.s 200 byte ledigt. Då försöker programmet allokera matris3, 200 byte. Men det misslyckas! (eftersom att heapen inte har 200 byte sammanhängande minne ledigt)"