class: center, middle ### Secure Computer Architecture and Systems *** # OS Models and Security ??? - Hi everyone - This video concludes our focus on operating systems - Here we'll talk about how essential OS design decisions impact the security of the systems they are integrated with --- # OS Design Models - Several **OS design models** have been derived by the industry and scientific community - Design model: core design choices defining how the OS functions are organised ??? - Since the first OSes were proposed in the 1950s, we have several classes of OS design models that have been derived, coming from both the industry as well as academia - By OS design model here we mean a collection of core design choices that define how the OS' architecture is organised -- - Each have they pros and cons in terms of performance, but also **security** ??? - Each of the OS design models that are relevant today have their pros and cons in terms of things like speed, memory footprint, reliability, real-time capabilities, and of course, security -- - Here we briefly: - Present each of the main OS models - Discuss each model's performance and security aspects ??? - Here we'll briefly cover the OS design models that are relevant to security, and discuss their performance and security implications --- # Monolithic Kernel <div style="text-align:center"><img src="include/monolithic.svg" width=650 /></div> - Application and kernel generally live in the same address space - The kernel itself is a large monolithic unit of trust: no internal isolation ??? - The monolithic kernel is among the most widespread class of OS designs today - This is the model we focused on in this unit - Its key idea is that all kernel components are packed together within a single monolithic piece of trust: there is no isolation between kernel subsystems, and they all live within the same address space - Further, there is a also a close coupling of the kernel with the application: both are also located within the same address space -- - Application and kernel isolated with privilege levels - Supervisor CPU execution mode, supervisor bit in the page table - Medium level of isolation, good performance - Less isolation means less costly security domain crossings ??? - The kernel is isolated from the application using CPU privilege levels: the kernel runs in supervisor mode and the kernel's memory is protected with the supervisor bit in page table entries - Applications are isolated from each other by running in different address spaces - Overall the monolithic kernel gives us a middle ground security vs. performance trade off - The isolation between the kernel and application, and between application themselves, is good but not ideal as we will see next in this unit - There is also no isolation inside the kernel - This medium level of isolation means that there is a limited amount of security domain crossing, which is good for performance - Many derivatives of UNIX are monolithic, the most popular example being Linux, but you also have FreeBSD, NetBSD, or OpenBSD - MS-DOS is another example of monolithic kernel --- # OS Design Space <div style="text-align:center"><img src="include/design-space-1.svg" width=800 /></div> ??? - So we have our monolithic kernel design which is a nice middle ground solution between security and performance - We could place it there in the design space - Let's have a look at other, more extreme points in that design space --- # OS Design Space <div style="text-align:center"><img src="include/design-space-2.svg" width=800 /></div> ??? - Basically we have two choices - We can decide to increase the degree of isolation, and that is going to have a performance cost - Or we can also decide to sacrifice security for the sake of performance - And drop isolation to get faster operating systems --- # OS Design Space <div style="text-align:center"><img src="include/design-space-3.svg" width=800 /></div> ??? - You may already know about micro kernels - It's a type of design which favours security at the expense of performance --- # Microkernels <div style="text-align:center"><img src="include/microkernel.svg" width=800 /></div> - Many kernel functionalities are offloaded to user space processes, **servers** - Only core functionalities left in the kernel: scheduling, process/memory management, etc. ??? - With a microkernel, most of the OS functionalities are moved into user space processes sometimes named servers, each running within its own address space - The microkernel itself is very small and contains only the core functionalities that cannot be offloaded to user space - These are memory management, scheduling, as well as inter-process communications - These IPCs are key for micro kernel, because this is the way subsystems offloaded to user space can communicate with the rest of the system -- - **More secure vs. monolithic**: 1 server fails/gets compromised does not mean it's game over for the entire system - **Slower vs. monolithic:** apps and servers must communicate with IPCs, involve security domain crossings (syscalls, context switches) ??? - The microkernel is more secure compared to the monolithic kernel, because of the increased level of isolation between kernel components - If one server gets compromised, the attacker will be confined to the relevant address space, and it will be difficult for them to get access to the rest of the system - Of course this additional security comes with a performance cost: communicating with IPCs is slower compared to a monolithic kernel where everything lives within a single address space: with a microkernel, although the communication can be heavily optimised, it still involves security domain crossings and possibly data copies, all of which is expensive - Examples of microkernels are MINIX v3, or L4 --- # OS Design Space <div style="text-align:center"><img src="include/design-space-4.svg" width=800 /></div> ??? - Now on the other hand if we are ready to drop security to go faster, we can go the exokernel and unikernel way --- # Exokernel <div style="text-align:center"><img src="include/exokernel-1.svg" width=400 /></div> - Minimal exokernel handle core OS functionalities, ~microkernel - Applications embed OS services: **library OS** (1 per app/group of apps) - Exokernel exposes a low level interface that securely multiplexes the hardware between the (untrusted) libOSes - More management responsibilities given to libOSes, they can be specialised on a per-app basis ??? - With the exokernel each application or group of applications is compiled with a library providing most of the operating system services - This is called a library operating system - LibOSes instance run on top of a microkernel-like kernel named the exokernel - In its original version the exokernel idea was to specialise each LibOS instance for the applications it runs to maximise performance --- # Unikernel <div style="text-align:center"><img src="include/exokernel-2.svg" width=400 /></div> - An **hypervisor** can play the role of the exokernel - Each application runs within its own virtual machine, compiled with a libOS: a **unikernel** - No need to isolate the application from the LibOS: system calls that do not necessitate going to the hypervisor are fast - More on unikernels in the virtualisation part of the unit ??? - The exokernel idea was proposed in the 90s but did not really take off - Fast forward in the 2010s, people realised that a small hypervisor could very well play the role of the exokernel - And that applications could be compiled with small library operating systems and run within virtual machines on top of that hypervisor - This is the unikernel design model - In terms of security, unikernels are well isolated from each other because they run in separate VMs - The hypervisor is also isolated from the unikernels - There is no isolation between a unikernel instance and the applications it runs - This has some performance advantages, in particular system calls become function calls which are much faster - However it is obviously concerning from the security point of view: if an attacker can exploit a vulnerability in an application, they may easily access the entire unikernel instance --- # Summary - **Monolithic kernel** - Privilege levels separates kernel from applications - No intra kernel isolation - **More secure, slower: microkernel** - Runs minimal core functionalities in supervisor mode - Run OS services in user mode, within their own address spaces - Trades off performance for security - **Faster, less secure: unikernel** - Drops user/kernel protection for the sake of performance ??? - To sum up, we have seen 3 important points in the OS design space, each with its own pros and cons in terms of security and performance - The monolithic kernel is a good middle ground solution, with a medium level of isolation and acceptable performance - The microkernel brings more isolation between kernel subsystems, at the cost of a performance slowdown due to communications between these subsystems - Finally, the unikernel model drops the user/kernel protection to gain a performance boost, at the expense of security