Na minulom cvičení ste napísali niekoľko utilít, ktoré používali systémové volania. V tomto cvičení napíšete dvojicu systémových volaní, ktoré vám pomôžu lepšie pochopiť interné mechanizmy jadra xv6 a ako samotné systémové volania fungujú. S pridávaním systémových volaní sa stretnete aj v niektorých ďalších cvičeniach.
Než začnete programovať, preštudujte si kapitolu 2 z xv6 knižky, sekcie 4.3 a 4.4 kapitoly 4 a príslušné zdrojové súbory.
Na prvých troch cvičeniach musíte pracovať na školských počítačoch, aby ste si zvykli na prostredie, ktoré budete používať na všetkých troch testoch. Na prvom cvičení ste vytvorili vzdialený repozitár, ktorý si teraz musíte na virtuálku stiahnuť. Postupujte podľa pokynov na stránke Synchronizácia repozitára v sekcii Stiahnutie repozitára na cvičení.
Na začiatok sa prepnite do vetvy syscall:
|
1 2 |
$ git fetch $ git switch syscall |
Riešenia úloh z tohto cvičenia ukladajte do vetvy syscall.
Ak spustíte make grade, zistíte, že hodnotiaci skript nemôže spustiť (execnúť) trace. Vašou úlohou je pridať potrebné systémové volania a podporný kód, aby trace fungoval. Naviac ste si mohli všimnúť, že test attacktest neprešiel.
Vo väčšine prípadov si vystačite s ladením prostredníctvom výpisov, ale niekedy budete potrebovať krokovať kód po riadkoch alebo vypísať funkcie na zásobníku stack backtrace. Na tieto a iné činnosti súvisiace s ladením kódu budeme používať nástroj gdb.
Predtým, ako sa pustíte do riešení ďalších úloh si vyskúšajte prácu s GDB. V koreňovom priečinku xv6 spustite príkaz make qemu-gdb a v druhom okne/karte spustite gdb-multiarch (alebo riscv64-unknown-elf-gdb, prípadne iný príkaz pre spustenie gdb pre architektúru RISC-V; bližšie informácie si prečítajte na stránke s pomôckami v sekcii Ladiace tipy). Keď máte otvorené dve okná/karty, napíšte do okna s gbd:
|
1 2 3 4 5 6 7 8 9 10 |
(gdb) b syscall Breakpoint 1 at 0x80002142: file kernel/syscall.c, line 243. (gdb) c Continuing. [Switching to Thread 1.2] Thread 2 hit Breakpoint 1, syscall () at kernel/syscall.c:243 243 { (gdb) layout src (gdb) backtrace |
Príkazom layout src alebo stlačením skratky Ctrl+x a rozdelíte okno na dve polovice, kde budete vidieť aktuálnu pozíciu v zdrojovom kóde. Príkazom backtrace vypíšete funkcie na zásobníku. Pozrite si prezentáciu Používanie gdb (EN) od našich kolegov z MIT pre ďalšie užitočné príkazy GDB.
Odpovedajte na tieto otázky (odpovede uveďte do súboru answers-syscall.txt):
syscall?
Stlačte dvakrát klávesu n, aby ste prešli za riadok struct proc *p = myproc();. Zadajte print /x *p, čím vypíšete obsah štruktúry struct proc aktuálneho procesu (viď kernel/proc.h) v hexadecimálnej forme.
p->trapframe->a7 a čo reprezentuje? (Pomôcka: pozrite sa do user/initcode.S na prvý program, ktorý xv6 spustí.)
Procesor beží v móde supervízora, takže môžeme vypísať hodnoty privilegovaných registrov, ako napríklad sstatus (viď privilegované inštrukcie RISC-V pre bližší popis):
|
1 |
(gdb) print /x $sstatus |
Kód xv6 obsahuje kontroly konzistencie. Ak tieto kontroly zlyhajú, vyvolá to kernel panic. Skúsme takúto chybovú situáciu zámerne vyvolať. Najprv ukončite gdb príkazom quit a na prvej karte nezabudnite ukončiť bežiace qemu. Nahraďte výraz num = p->trapframe->a7; výrazom num = * (int *) 0; na začiatku funkcie syscall, zavolajte make qemu, a uvidíte výstup podobný tomuto:
|
1 2 3 4 5 6 |
xv6 kernel is booting hart 2 starting hart 1 starting scause=0xd sepc=0x80001bfe stval=0x0 panic: kerneltrap |
Ukončite qemu.
Aby ste zistili miesto v kóde, kde panic nastal, hľadajte vypísanú hodnotu registra sepc v súbore kernel/kernel.asm, ktorý obsahuje inštrukcie v jazyku assembly pre skompilované jadro.
num?
Aby ste mohli skontrolovať stav procesora a jadra počas zlyhania vykonania inštrukcie, spustite gdb a nastavte breakpoint na adresu epc zlyhanej inštrukcie (adresa inštrukcie sa vo vašom prípade môže líšiť):
|
1 2 3 4 5 6 7 8 |
(gdb) b *0x80001bfe Breakpoint 1 at 0x80001bfe: file kernel/syscall.c, line 138. (gdb) layout asm (gdb) c Continuing. [Switching to Thread 1.3] Thread 3 hit Breakpoint 1, syscall () at kernel/syscall.c:138 |
Príkazom layout asm prepnete horné okno do zobrazenia inštrukcií jazyka assembly. Skontrolujte, či sa zlyhávajúca inštrukcia zhoduje s inštrukciou, ktorý ste našli v kernel/kernel.asm.
scause vyššie? (Pozrite si popis registra scause v príručke privilegovaných inštrukcií architektúry RISC-V).
Aj keď pri panicu vypíše jadro kód scause, často sa musíte pozrieť na ďalšie informácie, aby ste zistili presný problém, ktorý spôsobil panic. Napríklad, aby ste zistili, ktorý proces bežal keď nastal panic, môžete si vypísať jeho meno:
|
1 |
(gdb) print p->name |
Podľa potreby sa počas riešenia cvičení môžete vrátiť k prezentácii Používanie gdb (EN). Na stránke s pomôckami nájdete tipy k ladeniu systému.
trace(), ktorým bude možné riadiť trasovanie. Bude mať jeden argument, celočíselnú „masku“, ktorej bity určia, ktoré systémové volania budú trasované. Napríklad, na trasovanie systémového volania fork() program zavolá trace(1 << SYS_fork), kde SYS_fork je číslo systémového volania definované v kernel/syscall.h. Vaším cieľom je modifikovať jadro xv6 tak, aby tesne pred ukončením systémového volania jadro skontrolovalo, či je v maske nastavené číslo prebiehajúceho systémového volania. V takom prípade jadro vypíše riadok s id procesu, názvom systémového volania a jeho návratovou hodnotou. Systémové volanie trace() by malo povoliť trasovanie pre proces, ktorý ho zavolal a pre jeho detské procesy, ktoré neskôr vytvorí zavolaním fork(), ale nie pre ostatné procesy.
V repozitári nájdete užívateľský program trace, ktorý spustí iný program so zapnutým trasovaním (viď user/trace.c). Ak ste volanie správne naimplementovali, mali by ste vidieť niečo takéto:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
$ trace 32 grep hello README 3: syscall read -> 1023 3: syscall read -> 966 3: syscall read -> 70 3: syscall read -> 0 $ $ trace 2147483647 grep hello README 4: syscall trace -> 0 4: syscall exec -> 3 4: syscall open -> 3 4: syscall read -> 1023 4: syscall read -> 966 4: syscall read -> 70 4: syscall read -> 0 4: syscall close -> 0 $ $ grep hello README $ $ trace 2 usertests forkforkfork usertests starting test forkforkfork: 407: syscall fork -> 408 408: syscall fork -> 409 409: syscall fork -> 410 410: syscall fork -> 411 409: syscall fork -> 412 410: syscall fork -> 413 409: syscall fork -> 414 411: syscall fork -> 415 ... $ |
V prvom príklade trace spustí trasovanie programu grep, konkrétne systémového volania read. Číslo 1<<SYS_read je rovné 32. V druhom príklade sa jedná o ten istý proces, ale trasujú sa všetky systémové volania. Číslo 2147483647 má nastavených všetkých 31 dolných bitov. V treťom príklade program nie je trasovaný, takže nie je ani vypísaný žiadny výstup. V štvrtom príklade sú trasovaní všetci potomkovia testu forkforkfork zo sady testov usertests. Vaše riešenie je korektné, ak program má rovnaké správanie ako je uvedené vyššie (ID procesov môžu byť rozdielne).
Pomôcky:
Pridajte $U/_trace do premennej UPROGS v súbore Makefile.
Spustite make qemu a uvidíte, že kompilátor nemôže skompilovať súbor user/trace.c, pretože užívateľské útržky kódu pre systémové volanie trace ešte neexistujú: pridajte prototyp systémového volania trace do user/user.h, útržok do user/usys.pl, a číslo systémového volania do kernel/syscall.h. Súbor Makefile spustí perl skript user/usys.pl, ktorý vytvorí user/usys.S, kde sú uložené skutočné útržky systémových volaní, ktoré obsahujú inštrukciu ecall architektúry RISC-V, ktorá slúži na prechod do jadra. Potom, ako opravíte kompilačné problémy, spustite trace 32 grep hello README. Uvidíte, že zlyhá, lebo samotné systémové volanie v jadre ešte nie je implementované.
Pridajte funkciu sys_trace() do kernel/sysproc.c. Jej úloha je uložiť argument systémového volania do novej premennej v štruktúre proc (viď kernel/proc.h). Funkcie na prevzatie argumentov systémového volania nájdete v kernel/syscall.c a príklady ich použitia nájdete v kernel/sysproc.c. Pridajte smerník na novú funkciu sys_trace() do poľa syscalls v súbore kernel/syscall.c.
Upravte fork() (viď kernel/proc.c), aby skopíroval trasovaciu masku z rodiča do detského procesu.
Upravte funkciu syscall() v kernel/syscall.c, aby vypísala trasovací výstup. Musíte pridať pole názvov systémových volaní, ktoré sa budú vypisovať.
Po úspešnom dokončení úlohy nezabudnite vytvoriť commit!
Jadro xv6 izoluje používateľské programy navzájom a zároveň izoluje jadro od používateľských programov. Ako ste videli v úlohách vyššie, aplikácia nemôže priamo zavolať funkciu v jadre alebo v inom programe. Namiesto toho môžu interakcie prebiehať len pomocou systémových volaní. Ak ale je v implementácii systémového volania chyba, útočník môže zneužiť túto chybu na prelomenie izolačných bariér. Do xv6 sme naschvál vniesli chybu, aby ste si vyskúšali, ako môžu byť takéto chyby zneužité. Vašou úlohou je zneužiť túto chybu, aby xv6 odhalila citlivé dáta z iného procesu.
Chyba spočíva v tom, že pri kompilácii tohto labu je vynechané volanie memset(mem, 0, sz) na riadku 272 v súbore kernel/vm.c, ktorého úlohou je vynulovať novo alokovanú stránku. Podobne sú vynechané dva riadky zo súboru kernel/kalloc.c, ktorých úlohou je zneplatniť obsah uvoľňovaných stránok pomocou memset(). Kvôli vynechaniu týchto troch riadkov (všetky sú označené podmieneným príkazom ifndef LAB_SYSCALL) si novo alokované stránky zachovajú pôvodný obsah z predchádzajúceho použitia.
Program user/secret.c zapíše tajné dáta s veľkosťou 8 bajtov do pamäte a potom sa ukončí (týmto je jeho pamäť uvoľnená). Vašou úlohou je napísať niekoľko riadkov kódu do súboru user/attack.c, ktoré nájdu tajné dáta, ktoré predtým zapísal program secret.c do pamäte. Tieto dáta potom program vypíše do súborového deskriptora 2. Úloha je vyriešená, ak test attacktest vypíše OK: secret is ebb.ebb (tajné dáta sú náhodné a odlišné pri každom behu).
Upravovať môžete iba user/attack.c. Zdrojové kódy jadra, secret.c, attacktest.c a iné nesmiete upravovať.
Pomôcky:
|
1 2 |
$ attacktest FAIL: no/incorrect secret |
Aj napriek tomu, že v xv6 chýbajú 3 riadky, systém funguje korektne: spustil shell a program attacktest. Dokonca ak spustíte usertests, väčšina z nich prejde!
32 na 0 a útok by už nemal fungovať. Prečo to tak je?
Malé chyby, ktoré priamo neovplyvňujú korektnosť, ale napriek tomu môžu byť zneužité na narušenie bezpečnosti (ako tá v úlohe), robia programovanie jadra náročným. xv6 takéto chyby pravdepodobne má, aj keď sa im jeho autori snažia vyhnúť. Skutočné jadrá, ktoré majú oveľa viac riadkov kódu ako xv6, majú dlhú históriu podobných chýb. Pozrite si napríklad verejný zoznam zraniteľností Linuxu a ako nahlásiť zraniteľnosť.
Po úspešnom dokončení úlohy nezabudnite vytvoriť commit!
Týmto je cvičenie hotové. Skontrolujte, či vaše riešenie prejde všetkými testami make grade. Aby ste prešli posledným testom time, musíte vytvoriť nový súbor time.txt, v ktorom uvediete počet hodín, ktorý ste strávili nad zadaním ako celé číslo. Na záver nezabudnite svoje zmeny commitnúť do repozitára.
Prvý riešiteľ každej úlohy môže dostať bonusové body po kontrole riešenia. Informujte sa u prednášajúceho alebo cvičiaceho. Voliteľné úlohy môžete riešiť až po vyriešení všetkých úloh základnej časti cvičenia! Riešenia prijímame iba do konca štvrtého týždňa semestra.