OSWebSec: L4

Operating System and Web Security October 9, 2012 Proposal

abstract (200 words) primary paper supporting papers (3-5)

Talk about all of them. How it relates. If you want to give more, Anil will read it and give feedback. If you want to get an A – get a well written abstract primary paper.

Conferences: WWW OSDI ACM SOSP Usenix Security ACM CCS IEEE Symposium on security and privacy NDSS

Micro kernels

kernel – what is a kernel? The one piece of software that is to have access to privileged operations on the hardware. Multiprogramming – we want to run more than one program on the computer at the same time. They could run sequentailly to completion, they could be taskswitched. We have to have a way of sharing. If we want to have rules for sharing. Implement them using a program. There's a program that will decide how other programs share resources. If you are doing multiprogramming and want to enable sharing. How can that one program enforce sharing. All programs have to be on their best behaviour. If they start hogging resources, doing other things to other programs.. this is bad. With enforced sharing with some set of policies. You need a program that stands above the others, a program that has powers. People that are empowered like this: the police / military. They have the power of force – they have guns. We have to give the program a gun, we have to give it a way to kill other programs, or at least beat them up. What's the stick you are going to give them? It has to have power over resources that other programs do not. We mediate access to resources. Creating a police state, where you have to have permission to do anything at all. Decides who gets what resources. Need hardware support – to empower one program. Change the laws of physics of the computation, so that one program can do things that other programs cannot. That's the notion of modes – user and supervisor mode. The kernel is the boss because it's running as the supervisor mode. Hypervisor mode is the boss's boss. CPU boots up in supervisor mode. Kernel boots first and the first program it runs is init. Every process requires a parent. Init is it's own parent. When init dies, the system reboots. Whenever any processes parent's are killed, the parent becomes init. In order for a program to exit it must make a system call. Permission to die. In order to have that kind of power, the kernel has to be able to detect itself. It has to have guaranteed access to cpu time and memory. If another program can access each of those things, the kernel cannot function. You need some sort of memory protection. And you also need protected access to devices. Code that is running in supervisor mode – bugs in a kernel are traditionally very hard to debug. How are you going to make sure the kernel, when it does something stupid . How are you going to deal with it. This is where microkernels come in. It's often argued that they improve security. More often from a software engineering standpoint. All about abstraction dividing into pieces, understanding the smaller pieces. Kernel is a big spaghetti ball of code – all running in high privileged mode. Make it as small as possible, simple as possible, then the system should be more robust. Now we can replace components on the fly.

Load a bad device driver into your kernel, now your system can crash. Microkernel's saying, let's not do that. Of course we should make it as small as possible. What's the price? Performance – why? Context switching. A context switch means regular user program loads a file, go from userspace to the kernel. With a microkernel – you have to bounce back and forth from userspace to the supervisor mode. This is not cheap. Processors have gotten so much faster – you'd think it'd gotten cheaper, but it's got more expensive. Modern CPU's store a ridiculous amount of state.

You have to deal with: 1) registers 2) pipeline (instructions partially executed) (branch prediction) 3) TLB (virtual memory associations 4) L1, L2, L3 (tagged / multiple processes) modern processors don't execute code sequentially.

When you switch into supervisor mode you should make it count. There are context switches and code complexity. Tried to build non trivial programs – these two are now so heavily connected – splitting of it made it more complicated. Other places it makes nice division. Separating out the disk device driver from the file system. Separating out IPC from the network stack. Making these things in separate, you are putting in a boundary – what have you really gained by this? Why the security issues are often overdone. I want to compromise your system. If I have a buffer overflow inside a kernel, inject it only into a process – implementing a file system driver you haven't infected the whole system. If you are in the network code – you can change the IPC on the system. The amount of power you get by putting code into these things is still so large that the possibilities for privilege escalation seems immense. If any of these fail, you are pretty screwed. QNX is the main commercially viable microkernel out there. It means that they can remove functionality not needed for a given application. Also means that it's useful for hard real time. Microkernel can enforce strict scheduling. Real time scheduling – deadlines are met at that particular timeframe. Kernels typically nowadays have priority and round robin scheduling. How tightly enforced it is. For realtime you must ensure you meet deadlines. If someone's in a restaurant, and you want to be able to get out of the restaurant in a fixed amount of time. As a result in the buffet what are you doing, you have to assemble it yourself, but because you have access to all the resources you can decide what's necessary. The kitchen is like your kernel – providing a lot of functionality, but depending on the constraints – you might be waiting on a really large order. The kernel is not going to be developed for a particular application – embedded folks dealt with this – screw the notion of the kernel. The real time development folks have moved away from that because of code complexity. Have higher degrees of concurrency. Mobile programs be separately debuggable. Small kernel that enforce policy. If you don't turn off that valve at the right moment, you get a gas explosion.

“loss of life is unacceptable, play nicely!”

address spaces – enforce memory protection IPC – how are programs going to talk to each other. Also need something for controlling I/O ports.

Mach – didn't have an external pager – much more functionality inside the main kernel. How much functionality can you factor out? Device drivers – straightforward. Can you get the TCP/IP stack out, can you get the pager out? They pushed a lot of things out. Example: bring your own wait staff to the buffet. Resources might be a pain to use.

Windows NT – started off as a microkernel architecture – not a completely minimalistic design – NT 3.51 – NT 4 – a really nicely designed system with crap graphics performance. Too many context switches for graphics. Look @ the unix API – 2-300 system call – the window's api couple thousand. The kernel has that much functionality because of increased performance. What has been the modern solution for this?

Virtualization – what is a hypervisor? A kernel that runs multiple kernels – manages both. A kernel that multiplexes between kernels. How can one kernel take over from other kernels? Has a higher supervisor mode. Talk about rings – with unix – user and supervisor mode – multex – 0, 1, 2, and 3 one way to do this: paravirtualization (zen) hack your os – modify it in small simple ways to run on top of my architecture. What did they do instead? Talked to intel – ring -1 – hardware virtualization entire class of attacks – inject a hypervisor take over -1 (the blue pill).

Mainframes – can run multiple os/ not just their cpu but their devices are setup to multiplex to multiple oses. one os setup as management os but it only runs to setup the policies. Multiplexing happens at the hardware level. Disks that expect to talk to multiple oses.