Uke 17 - Internminne, disker og filsystemer

Oppgaver til mandag 21. - fredag 25. apr

Først noen stort sett teoretiske oppgaver om internminnet og så noen oppgaver om praktisk bruk av internminne denne uken. Deretter skal dere bruke et open source verktøy som vanligvis brukes til å kartlegge hva som har skjedd på en datamaskin i forbindelse med datakriminalitet. Dere skal bruke dette verktøyet, Autopsy Forensic Browser, til å lære litt om disk-partisjoner og hvilke filsystemer som kan lages på slike partisjoner. Deretter noen oppgaver om RAID. Selve OS-konkurransen er avsluttet, men helt til slutt denne uken kommer det onsdag 23 april en lærerik og spennende oppgave med samme opplegg som tidligere med å finne en hemmelig kode. Men denne oppgaven teller ikke med i sammendraget siden premiene skal deles ut denne onsdagen.

Ved å logge deg inn på https://guacamole.cs.oslomet.no/guacamole med ditt vanlige OsloMet brukernavn og passord, kan du etterhvert (kanskje klart 11 april) få testet ut hvordan shellet vil fungere under eksamen; inkludert pwsh-shellet som startes ved å kjøre kommandoen pwsh.

  1. Størrelsen på diskens swap-område som brukes til page-lagring er relatert til det maksimale antall prosesser, n, antall bytes det virtuelle adresserommet består av, v, og antal bytes RAM består av, r. Skriv ned et uttrykk for worst-case mengde disk-plass det er behov for. Hvor realistisk er denne størrelesen?
  2. Hvis en instruksjon tar 10 nanosekunder (å hente fra minnet) og en page fault tar n nanosekunder i tillegg, gi en formel for effektiv instruksjonstid når pauge faults inntreffer for hver k'te instruksjon.
  3. En maskin har et 32-bit adresserom og en sidestørrelse på 8-KB. Hele page-tabellen liger i hardware(en enorm TLB), med ett 32-bit ord for hver page-referanse i tabellen. Når en prosess starter kopieres prosessens page-tabell til hardware fra internminnet, ett ord på 100 nanosekunder. Anta at hver prosess kjører i 100 millisekunder(inkludert tiden det tar å laste in page-tabellen). Hvor stor prosentdel av CPU-tiden blir da brukt til å laste inn page-tabellen?
  4. TLB på VAX(en datamaskin-type fra 80-tallet) hadde ikke noe R-bit. Hvorfor ikke?
  5. Kan du tenke deg en situasjon der det er en dårlig ide å supportere virtuelt minne? Hva ville man tjene på å ikke supportere virtuelt minne i denne situasjonen? Forklar.
  6. (Oblig) Kopier og kjør C-programmet i avsnitt 14.3 i forelesningsnotatene på Linux-VM og gjenta kjøringen som er vist der. Klarer du å endre koden, slik at mer av programmet lastes inn i RAM? Slik at RES blir større enn 640 (eventuelt større enn 5256 om man senere i kjøringen legger til Størrelse: 1048576).
  7. (Oblig) Studer output fra to minne-tester kjørt på en Ubuntu-maskin med en dual core Intel CPU beskrevet på denne linken. Let gjerne opp info om RAMspeed på nettet om det er uklart hva output betyr.
    rex:~/mem/ramsmp-3.5.0$ ./ramsmp -b 1 -p 1
    RAMspeed/SMP (GENERIC) v3.5.0 by Rhett M. Hollander and Paul V. Bolotoff, 2002-09
    
    8Gb per pass mode, 1 processes
    
    INTEGER and WRITING         1 Kb block: 9321.32 MB/s
    INTEGER and WRITING         2 Kb block: 9331.59 MB/s
    INTEGER and WRITING         4 Kb block: 9351.55 MB/s
    INTEGER and WRITING         8 Kb block: 9351.18 MB/s
    INTEGER and WRITING        16 Kb block: 9345.99 MB/s
    INTEGER and WRITING        32 Kb block: 9315.40 MB/s
    INTEGER and WRITING        64 Kb block: 7607.90 MB/s
    INTEGER and WRITING       128 Kb block: 7604.01 MB/s
    INTEGER and WRITING       256 Kb block: 7610.04 MB/s
    INTEGER and WRITING       512 Kb block: 7607.74 MB/s
    INTEGER and WRITING      1024 Kb block: 7548.60 MB/s
    INTEGER and WRITING      2048 Kb block: 7109.58 MB/s
    INTEGER and WRITING      4096 Kb block: 4896.64 MB/s
    INTEGER and WRITING      8192 Kb block: 2423.03 MB/s
    INTEGER and WRITING     16384 Kb block: 2184.29 MB/s
    INTEGER and WRITING     32768 Kb block: 2184.01 MB/s
    rex:~/mem/ramsmp-3.5.0$ ./ramsmp -b 1 
    RAMspeed/SMP (GENERIC) v3.5.0 by Rhett M. Hollander and Paul V. Bolotoff, 2002-09
    
    8Gb per pass mode, 2 processes
    
    INTEGER and WRITING         1 Kb block: 18109.24 MB/s
    INTEGER and WRITING         2 Kb block: 18219.90 MB/s
    INTEGER and WRITING         4 Kb block: 18154.45 MB/s
    INTEGER and WRITING         8 Kb block: 18211.36 MB/s
    INTEGER and WRITING        16 Kb block: 18159.56 MB/s
    INTEGER and WRITING        32 Kb block: 18106.97 MB/s
    INTEGER and WRITING        64 Kb block: 12689.42 MB/s
    INTEGER and WRITING       128 Kb block: 12655.80 MB/s
    INTEGER and WRITING       256 Kb block: 12678.70 MB/s
    INTEGER and WRITING       512 Kb block: 12606.43 MB/s
    INTEGER and WRITING      1024 Kb block: 12630.78 MB/s
    INTEGER and WRITING      2048 Kb block: 7212.07 MB/s
    INTEGER and WRITING      4096 Kb block: 2464.42 MB/s
    INTEGER and WRITING      8192 Kb block: 2161.78 MB/s
    INTEGER and WRITING     16384 Kb block: 2157.42 MB/s
    INTEGER and WRITING     32768 Kb block: 2096.32 MB/s
    
    Prøv å forklare nedgangen i skrivehastighet relatert til størrelesen på L1 og L2 cache. Forklar spesielt hvorfor to samtidige prosesser skriver blokker av data opp til 32KB dobbelt så fort som en enkelt prosess, mens når 32Mb blokker skrives er hastigheten omtrent den samme.
  8. Installer og kjør ramspeed på Linux-VM som følger:
    wget https://sources.buildroot.net/ramspeed/ramspeed-2.6.0.tar.gz
    tar xfz ramspeed-2.6.0.tar.gz 
    cd ramspeed-2.6.0/
    ./build.sh 
    ./ramspeed -b 1
    
    Prøv å finne spesifikasjonene for denne CPU'en i /proc/cpuinfo og på tilsvarende web-side som den nevnt over. Rimer resulatatene med cache-størrelsene? Er det stor forskjell på skriving og lesing?
  9. (Oblig) Linux-kommandoen free -m viser hvor mye ledig minnet det er og output kan se slik ut:
    $ free -m
                 total       used       free     shared    buffers     cached
    Mem:           398        386         12          0         25        100
    -/+ buffers/cache:        260        138
    Swap:          349         57        292
    
    Her er buffers antall MBytes brukt til I/O buffere og cached antall MBytes brukt til disk-cache. Kjernen kan dynamisk minske sin bruk av I/O-buffere og disk-cache ved behov for minne til andre formål. Verdien 138 Mbytes i andre linje i free-kolonnen er free + buffers + cached fra første linje. Forklar kort hvorfor dette er et tall som viser hvor mye minne som er ledig for applikasjoner.
  10. (Oblig) Kompiler og kjør dette C-programmet på Linux-VM og ta tiden det bruker med time.
    #include <stdio.h>    
    int array[2000000000];
    
    void main(int argc, char *argv[])
    {
       int i,j;
       for(i = 0;i < 2000000;i++)
         {
    	j = i*1000;
    	array[j] = i;
         }
    }
    
    
    Endre så array-linjen til
    	      array[j] = i;
    
    Vil dette endre på antall elementer av arrayet som endres i RAM? Siden vi snakker om Random Access Memory hvor det skal ta like lang tid å aksessere hvilken som helst byte i RAM, bør vel disse to versjonen av programmet bruke nøyaktig like lang tid? Hvis de ikke gjør det, diskuter hva dette kan skyldes. Legg spesielt merke til om System-delen av tidsbruken endrer seg. Hva er 'System' i forhold til 'User' og er dette relevant for forklaringen?
  11. (Oblig)

    Last ned denne partisjonen med wget og lagre den på din Linux VM (container). Dette er en veldig liten partisjon på bare 8 MB. Den har blitt laget på en Linux-PC med filsystemet ext3. Filsystemet er kort sagt systemet som er brukt for å lagre filer og kataloger på disken. Hvis man moterer dette imaget og ser på filsystemet på vanlig måte (dere har ikke rettigheter til det på Linux VM), vil man bare finne en enkelt fil der:

    haugerud@lap:~/disk$ sudo mount -o loop imgExt /mnt
    [sudo] password for haugerud: 
    haugerud@lap:~/disk$ cd /mnt/
    haugerud@lap:/mnt$ ls -l
    total 13
    -rw-r--r-- 1 root root    38 april  9  2007 fil.txt
    drwxr-xr-x 2 root root 12288 april  9  2007 lost+found
    haugerud@lap:/mnt$ cat fil.txt 
    Dette er en tekstfil.
    Her er linje2.
    
    haugerud@lap:/mnt$ 
    
    Men denne partisjonen inneholdt tidligere også en fil som het fil2.txt og som blant annent inneholdt en linje der det sto "Dette er en tekstfil. " og litt mer tekst. Men denne lille tekstfilen ble slettet med rm og den synes derfor ikke når partisjonen monteres. I denne oppgave skal du prøve å finne ut om den slettede filen fortsatt er på partisjonen eller om alle spor er slettet. For å kunne studere denne partisjonen på filsystemnivå og kunne se på deler av disken som ikke filsystemet lenger har linker til trenger vi et program som kan gjøre dette og vi skal bruke autopsy.

    Installer autopsy på Linux VM med sudo apt-get install autopsy. Kjør deretter programmet som root med kommandoen

    sudo autopsy -p 80 urlEllerPublicIpTilPCDuSitterPå
    og følg instruksjonene. Hvis du får meldingen Insecure directory in $ENV{PATH} while running with -T switch at /usr/bin/autopsy line 278 , legg inn følgende PATH-linje før linje 278, slik at filen /usr/bin/autopsy blir slik:
    $ENV{PATH} = '/usr/bin';
    $lclhost = /bin/hostname;
    
    Du må også legge inn samme PATH-linje før linje 50 og linje 88 i /usr/share/autopsy/lib/Exec.pm (se feilmeldingene). Du skal bruke IP eller url til din egen laptop og ikke Linux-VM. Men filene du skal se på skal lagres på Linux-VM. Om du ikke vet din IP, kan du finne den på www.whatismyip.com. Følg instruksjonene, slik at du får startet autopsy i browseren på din PC med noe sånt som
    https://os50.vlab.cs.oslomet.no:80/905546150256588255/autopsy
    
    hvis du har VM nr 50. NB: Pass på å sette inn .vlab.cs.oslomet.no etter os50! Velg så "new case", finn på et navn for denne "case'n", velg "new case","Add host" og igjen "Add host", deretter "Add image" og "Add image file". Skriv så inn location=/root/imgExt eller der du har lagt imgExt(må være lesbar for alle). , Type partition (ikke Disk), import method symlink, "next", filesystem type ext(som autopsy finner ut selv) og bruk gjerne mount point /1/ eller kall det noe annnet. Velg "Add" og "OK" og nå er saken klar til å etterforskes. Velg "Analyze" og klikk deretter på File Analysis, Keyword search og de andre valgene og se hva du kan finne ut om denne partisjonen. Help kan det også være nyttig å prøve. Klarer du å finne innholdet av den slettede filen fil2.txt? (Hint: hvis du klarer å finne ut på hvilken block eller fragment filen fil.txt ligger ved, kan det være lurt å lete i nærheten, siden den ble opprettet samtidig.) Under Image Details kan du se at
    Block Range: 0 - 8000 
    Block Size: 1024 
    
    og det betyr at om du legger inn Fragment Number 0 under Data Unit, får du se første block eller fragment på 1024 bytes av disken. De to filene ligger i andre blokker, men hvor?
    ASCII Contents of Fragment 0 in imgExt-0-0
    

  12. Last ned denne NTFS-partisjonen og lagre den på Linux VM. Dette er også en veldig liten partisjon på bare 8 MB. Den er laget på en Windows-PC, og bruker et helt annent filsystem, NTFS. Gjør de to forrige oppgavene omigjen med denne partisjonen. Hvis du lukker case'n med close kan du legge til denne partisjonen som et nytt image i samme case. Også i dette tilfellet har det blitt fjernet en fil, men det er ikke sikkert at du hverken klarer å montere denne partisjonen eller å finne igjen filen. Legg merke til at til forskjell fra Linux-filsystemet er i NTFS all informasjonen om filsystemet lagret i filer.
  13. Anta at du på en datamaskin kjører RAID 4 med fire disker. Anslå maksimalt hvor mye hurtigere det teoretisk sett vil kunne gå å lese en stor fil fra dette RAID'et sammenlignet med å lese den samme filen fra en enkeltdisk.
  14. Anta at det kommer inn en enkelt forespørsel om å skrive en datamengde som er mindre enn stripene i et RAID 4. Anta at hele datamengden skrives til en disk i RAID'et. Vil det likevel også skrives til en annen disk i RAID'et? Forklar kort.
  15. Anta at det hagler inn forespørsler om å skrive slike datamengder som er mindre enn stripene i et RAID 4. Hva kan da bli en flaskehals for RAID 4 og hvorfor behandler RAID 5 denne situasjonen bedre?
  16. (Oblig) RAID 3 ligner på RAID 4, men størrelssen på stripene er mye mindre. Tenkt deg at en RAID 3 stripe består av bare ett bit og at følgende er lagret på et slikt 4-diskers RAID 3:
    disk 1 disk 2 disk 3 paritets-disk
    1 0 0
    0 1 0
    1 1 1
    1 0 1
    0 0 1
    1 1 0
    Som du ser har disk 3 crashet og alle dataene (bit'ene) fra denne disken er borte. Gjenskap dataene som var på disk 3 før den crashet.
  17. Du er oppnevnt som etterforsker i en sak hvor en meget mistenkelig person har kommet med fly til Norge og har blitt arrestert på flyplassen. Han forstår norsk og er mistenkt for å komme hit for med ulovlige midler å motarbeide datalagringsdirektivet i Norge. Ditt hovedmål er å finne ut en 10 tegns hemmelig kode som personen på en eller annen måte har gjemt på datamaskinen sin. Du vet at den mistenkelige utlendingen ble gitt en minnepinne og at han ble tilsendt et jpg-foto etter at han ankom Gardermoen. Men arrestasjonen var ikke så rask som ønsket og han rakk trolig både å slette fotoet fra harddisken på Linux-laptop'en sin samt å slette en fil fra minnepinnen og i tillegg kjøre en hurtigformattering av minnepinnen for å fjerne alle sine spor. Det store spørsmålet er om du som genial etterforsker likevel klarer å hente ut nok informasjon til å finne den hemmelige koden. Bruk autopsy og eventuelt andre hjelpemidler.

    Som etterforsker får du nå tilgang til de to image'ene som utgjør en liten partisjon på laptop-disken og minnepinnen til den mistenkte. Disk-partisjonen er i denne mappen Man kan ikke liste filene på denne websiden, men for gruppe s133 ligger det der en image-fil med en disk-partisjon som heter s133 på denne websiden, tilsvarende for andre s-brukere. Minnepinnen er denne partisjonen. På din vei for å løse hovedspørsmålet, kan det være fornuftig å finne svar på følgende underveis:

    1. Monter først image'ene. Hva finnes av filer som ikke er slettet?
    2. Legg så imagene inn i Autopsy. Hvordan kan du finne frem til det slettede fotoet i Autopsy? (Hint: se først under File Analysis og let etter filen i Data Unit) Hvilke blocks (blokker) består fotoet på ext4-partisjonen av og hvor mange er disse blokkene? (har binær start og stopp av en jpg-fil noen spesielle tegn?)
    3. Prøv å velge alle blokkene som tilsammen utgjør fotoet i Data Unit samtidig og eksporter fotoet og lagre det til en fil ved å klikke på Export Contents. Endre filnavnet til standard jpg-filendelse og se om du kan se på bildet.
    4. Hva slags filsystem er det på minnepinnen?
    5. Hva er sektor-størrelsen og cluster-størrelsen på minnepinnen? (Se Image Details)
    6. Hva skjer ved en hurtigformattering av en minnepinne(quick format)?
    7. Hva er innholdet av den slettede filen på minnepinnen? (NB! Firefox kan crashe hvis man ber om å se 10 eller fler clustere på en gang fra minnepinnen; be da om færre enn 10 clustere)
    8. Og til slutt det store spørsmålet: Hvordan kan fotoet fra laptop-partisjonen og filen fra minnepinnen til sammen gi informasjon om hva den hemmelige koden er? Her har det blitt brukt avanserte metoder for å skjule informasjonen og dette er det derfor ikke så lett å finne ut av....

    For å sjekke at du har funnet det rette ordet, skriv strengen med 10 tegn inn på siden os.php uke 17 og du får beskjed om du har skrevet riktig. I tilegg blir du da med på ekstra-konkurransen om å finne denne koden fortest mulig. Denne siste oppgaven er ikke med i sammenlagtkonkurransen siden vi har premieutdeling i dag.