https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=Operating_Systems_2020W_Lecture_15 2026-06-02T22:26:50Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=Operating_Systems_2020W_Lecture_15&diff=22580&oldid=prev 2020-03-20T02:35:54Z

<p>Created page with &quot;==Video== Video for the lecture given on March 6, 2020 [https://homeostasis.scs.carleton.ca/~soma/os-2020w/lectures/comp3000-2020w-lec15-20200306.m4v is now available]. ==No...&quot;</p> <p><b>New page</b></p><div>==Video==<br /> <br /> Video for the lecture given on March 6, 2020 [https://homeostasis.scs.carleton.ca/~soma/os-2020w/lectures/comp3000-2020w-lec15-20200306.m4v is now available].<br /> <br /> ==Notes==<br /> <br /> &lt;pre&gt;<br /> Lecture 15<br /> ----------<br /> <br /> - midterms mostly graded, all should be done by end of weekend<br /> - midterms will be returned through your TA<br /> - if you go over your midterm with your TA, you get 2 bonus marks<br /> - solutions are posted, will go through them at a later date<br /> <br /> <br /> <br /> Kernel modules &amp; eBPF<br /> ---------------------<br /> <br /> What do you do if system calls aren&#039;t enough?<br /> - not fast enough<br /> - insufficient functionality<br /> - insufficient visibility<br /> <br /> <br /> Consider web browsers<br /> - web pages can do some things<br /> - browser extensions can do other things<br /> <br /> Browser extensions can be very dangerous<br /> - see every page you visit<br /> - change contents of any page<br /> - change interface elements -&gt; change how your banking website works<br /> - send arbitrary data to other systems<br /> - spyware!<br /> <br /> Price for added functionality is more risk<br /> <br /> How can we extend the operating system, specifically the Linux kernel<br /> <br /> Firefox long had very powerful extensions, but more recently<br /> adopted a much more restrictive extension interface<br /> - one reason: mostly compatible with Chrome<br /> - but big reason: much safer<br /> - also, made it hard to change the browser, because they<br /> had to preserve internal interfaces for external consumers<br /> <br /> <br /> Of course, any program running on a system &quot;extends&quot; it<br /> - but extensions make use of privileged APIs to allow for<br /> tighter integration<br /> - also, extensions tend to run in the same address space as<br /> the main program, so can manipulate main program state<br /> <br /> With extending the Linux kernel, we want code running in the kernel<br /> - so, in the address space of the kernel<br /> - but this means the code can mess with arbitrary parts of the kernel<br /> - so you can see and modify any process, act as any user<br /> - interact with any device in arbitrary ways<br /> - allocate any resources you want<br /> <br /> <br /> Classic bad thing to do with a kernel module: a rootkit<br /> - hide processes<br /> - hide files<br /> - add backdoors that allow you to bypass mainline authentication<br /> - think &quot;joshua&quot;<br /> <br /> How do we control what code gets loaded?<br /> - normally requires root privileges<br /> - on some systems, code must be signed<br /> <br /> Code running in the kernel IS NOT running as root!<br /> - root is the maximally privileged user<br /> - but root is just a label for processes<br /> - the kernel is what implements the process abstraction<br /> <br /> kernel modules have maximum flexibility and maximum pain<br /> - one coding error can lead to system crashes and corrupted devices<br /> <br /> But what about adding code to the kernel in a safer way?<br /> <br /> When you run code in a web browser, where does it run?<br /> - in the address space of the browser<br /> - (compiled JavaScript)<br /> - this is safe because code is &quot;sandboxed&quot;<br /> - (sandboxing is not a technical term, it is an aspiration)<br /> <br /> We don&#039;t sandbox code loaded into a kernel<br /> - we already have processes<br /> <br /> But we can verify/check code to make sure it is safe (for some<br /> approximation of safe)<br /> <br /> Standard kernel modules have no verification<br /> <br /> eBPF does!<br /> <br /> eBPF is based on the Berkeley Packet Filter (BPF), but extended<br /> - idea was to run code in the kernel to filter packets<br /> <br /> trace uses eBPF<br /> strace, gdb uses ptrace (a system call)<br /> - designed for debugging one process at a time<br /> <br /> <br /> eBPF is very fussy about the code it accepts<br /> - all loops must clearly terminate!<br /> - no arbitrary memory access<br /> <br /> <br /> - eBPF code runs in kernel space, but is verified to make sure it is safe<br /> (supervisor mode on the CPU, in the kernel address space)<br /> <br /> - kernel modules run in kernel space, and ARE NOT verified<br /> - but they may be signed (so inauthentic modules will be rejected)<br /> - supervisor mode on the CPU, in the kernel address space<br /> <br /> - processes run in userspace, not verified but are &quot;sandboxed&quot; to a degree<br /> - user mode on CPU<br /> - own address space<br /> <br /> - eBPF is a new thing, separate from regular functionality we&#039;ve covered<br /> - NOT used to implement system calls (at this time)<br /> - NOT used for device drivers<br /> <br /> eBPF is a safer way to add code to kernel space<br /> <br /> API exposed to userspace is stable<br /> - mainly system calls, but also device files<br /> <br /> but internal kernel APIs are not stable<br /> - kernel modules, eBPF programs have to be compiled anew for each<br /> new kernel<br /> - easier with eBPF, because designed to be compiled at runtime<br /> <br /> Monolithic vs microkernels<br /> - difference is in what runs in kernel vs user space<br /> - monolithic kernels runs most networking, filesystems, device drivers<br /> in kernel space<br /> - microkernels try to put these all in processes<br /> <br /> Advantage of microkernel<br /> - potentially more stable<br /> - easier to debug<br /> - most OS code is in processes, so can use conventional tools to debug<br /> <br /> Key disadvantage<br /> - performance<br /> <br /> (Security benefit of microkernels is quite arguable)<br /> <br /> Linux does have userspace drivers<br /> - NTFS for example (main Windows file system)<br /> <br /> eBPF reduces disadvantages of monolithic kernels <br /> - safe mechanism for extensions that is faster than processes<br /> &lt;/pre&gt;</div>

Soma