https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=Operating_Systems_2020W_Final_Exam_Review 2026-05-13T00:39:11Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=Operating_Systems_2020W_Final_Exam_Review&diff=22630&oldid=prev 2020-04-09T21:19:47Z

<p>Created page with &quot;==Video== Video from the exam review on April 9, 2020 [https://homeostasis.scs.carleton.ca/~soma/os-2020w/lectures/comp3000-2020w-examreview-20200409.m4v is now available]....&quot;</p> <p><b>New page</b></p><div>==Video==<br /> <br /> Video from the exam review on April 9, 2020 [https://homeostasis.scs.carleton.ca/~soma/os-2020w/lectures/comp3000-2020w-examreview-20200409.m4v is now available].<br /> <br /> ==Notes==<br /> <br /> &lt;pre&gt;<br /> Final Exam Review<br /> -----------------<br /> <br /> A3 topics<br /> - equivalence between named pipes and (unnamed) pipes from pipe()<br /> - general understanding of pipes<br /> - what you can and can&#039;t do with them<br /> - specifically, you can&#039;t seek on pipes (go backwards, forwards)<br /> - can only read or write (depending on which side of the pipe you have)<br /> - so can only substitute for regular files in these limited contexts<br /> (no seeking, only reading or only writing linearly)<br /> - understanding conditional variables and semaphores<br /> - why they require special implementations<br /> - the basic logic of them<br /> - how poor implementations can lead to deadlock<br /> - processes versus threads<br /> - how to create a process vs how to create a thread<br /> - how making a thread shares memory while a process copies memory<br /> - note how we had to create special shared memory with two<br /> processes but didn&#039;t have to with threads, because all is shared<br /> - character devices, block devices<br /> - how to create from scratch<br /> - significance of major/minor numbers<br /> - difference between uid and euid<br /> - how uid is used to indicate process ownership, while<br /> euid indicates process privileges<br /> - if you own a process, you can send signals to it (i.e., you can<br /> kill it)<br /> - basic understanding of what the kernel tracks (in the task_struct)<br /> versus what users see, what is in kernel space and what isn&#039;t<br /> - specifically, uid/gid vs usernames and groups<br /> <br /> A4/T8 topics<br /> - difference between virtual and physical memory<br /> - file mmap&#039;d into two processes: could have same virtual addresses<br /> but do not have to. Will have same physical addresses<br /> (because same file, loaded only once and shared)<br /> - processes can control layout of virtual memory<br /> - if you coded everything, could control where mmap puts things (mostly),<br /> ask for areas of virtual address space to be made valid or invalid,<br /> change binary so code and data are loaded in different places<br /> - processes can&#039;t directly control physical memory<br /> - kernel does what it wants with it<br /> - kernel vfs<br /> - how modules can define file operations for devices by specifying function<br /> pointers in a struct<br /> - can choose functions for read, write, lseek, ioctl, etc<br /> - if you don&#039;t define, userspace gets error when trying<br /> to do that system call on your character device<br /> - ioctl<br /> - how it only applies to devices, not regular files<br /> - how tty&#039;s are character devices, and how ioctl&#039;s allow<br /> us to control tty&#039;s<br /> - page sizes in the Linux kernel<br /> - how they are architecture dependent, but the kernel source<br /> abstracts them so most of the kernel doesn&#039;t care<br /> - page sizes are determined by the CPU<br /> - page offsets versus page numbers<br /> - how lower bits of virtual address encodes an offset in a page<br /> - walking a page table<br /> - how you do lookups at each level which give the physical address<br /> of the page containing the next level, until we get to the data page<br /> - physical address is really a &quot;page number&quot;, i.e. pointer with lower<br /> PAGE_SIZE bits set to 0<br /> <br /> A4/T9 topics<br /> - you can use -D on command line to define things in a C program, like #define<br /> - how this can be used to change how programs are compiled<br /> - how with eBPF (as implemented in bcc) the python code runs in userspace, but<br /> compiles and loads C programs into kernel space (the actual eBPF code)<br /> - eBPF programs can watch every system call and arbitrary numbers of<br /> kernel functions and functions in processes (specified by PID or by<br /> library or executable) - crazy powerful<br /> - how eBPF can do much more than ptrace-based programs (strace, gdb)<br /> - ptrace only allows for monitoring one process at a time<br /> - eBPF can watch everything in kernel and userspace<br /> - how eBPF can do powerful things so has to be restricted to root<br /> - what kind of things can it do that regular processes can&#039;t do,<br /> even ones running as root?<br /> - how ridiclously often filter() was called in 3000shellwatch.py/bpfprogram.c<br /> - probes can run on function/system call start or exit<br /> - signals (like users) are represented as numbers, not strings, in<br /> the kernel (although signals are encoded using #define&#039;s in the<br /> kernel source)<br /> - permissions<br /> - symbolic versus octal<br /> rwxrwxrwx vs 0777<br /> - only care about read, write, execute permissions<br /> (other things are encoded in these bits like setuid, not on exam)<br /> - safety of eBPF versus regular kernel modules<br /> <br /> <br /> Midterm topics<br /> - see the midterm review<br /> - see the midterm questions<br /> <br /> ------------------------------------------<br /> BELOW IS EXTRA MATERIAL<br /> <br /> Topics to discuss<br /> - mmap<br /> - page table lookups<br /> <br /> eBPF safety<br /> - clear termination (can calculate when loops terminate)<br /> - safe memory access (no dangerous pointer arithmetic)<br /> - ?<br /> <br /> Page tables are simple data structures<br /> - have to be, are traversed by hardware, and need to be done quickly<br /> <br /> What it is doing is splitting up the bits of a virtual address into<br /> offsets into lookup pages<br /> - each lookup page is an array of &quot;pointers&quot;,<br /> really page numbers (i.e., lower PAGE_SIZE bits are ignored)<br /> - in a 4K page, we can fit 2^9 64 bit pointers<br /> - we need 9 bits to specify each location in a page<br /> - so page table lookups are literally<br /> - use pointer P to find page of physical memory M<br /> <br /> 64 bit virtual addresses, 57 bit physical addresses with 5-level page tables<br /> <br /> 9-bits 9-bits 9-bits 9-bits 9-bits 12-bits = 57 bits<br /> pgd p4d pud pmd pte<br /> <br /> <br /> start with pointer to page table (which is a pointer to a page)<br /> - this is the pgd page<br /> - in that page, use pgd bits in the virtual addess to get a 9-bit number<br /> - that 9 bit number (0-511) is an offset into the page<br /> - (the page is a 512 element array, with each element<br /> consisting of an 8-byte pointer)<br /> - use this pointer to get the p4d page<br /> <br /> Do the same thing for the p4d page, pud page, pmd page, and pte page<br /> - 5 levels<br /> <br /> when you do the lookup in the PTE page, you get a pointer to the data page<br /> - where the actual process data is<br /> - last 12 bits of virtual address is an offset into this page<br /> <br /> All these calculations ARE NOT ON THE FINAL<br /> - just the idea of 5-level page tables<br /> - difference between virtual and physical addresses<br /> &lt;/pre&gt;</div>

Soma