Operating Systems 2019F Lecture 22

Video

Video from the lecture given on November 27, 2019 is now available.

Notes

Lecture 22
----------
* assignment 4
* assignment 3 solutions
* virtualization & containers

accepting questions on the #lecture channel

Review session on Dec. 13th or 16th?  Please indicate your preferences on discord (thumbs up or down)

Virtualization and containers
-----------------------------

* on openstack and virtualbox, you are using "virtual machines"
* in CS, there are LOTS of virtual machines
  - simulation of another machine
  - that other machine may never be "real"
* for example, the Java Virtual Machine (JVM) has nothing to do
  with the VMs we get with virtualbox and openstack

With hardware virtual machines
 - the virtual machine is roughly the same as the physical machine
 - so you can run a regular OS on the virtual machine (because it thinks
   it is running on real hardware)

Key advantages of HVMs:
 - strong isolation
 - universality

Key disadvantage of HVMs:
 - expensive!  you're running lots of kernels
   (one per VM)


processes (on one of the kernels)
Kernels * n
Hypervisor
Hardware

Process is running on CPU, makes system call (software interrupt)
 - hardware recognizes event
 - hardware calls hypervisor handler for system call
 - hypervisor calls a kernel's system call handler
 - kernel's system call handler does the work, calls scheduler
 - hypervisor scheduler decides which kernel to next run, kernel
   schedule decides which process

emulation versus virtualization
 - HVMs only interpose on system events, instructions run directly on CPU
 - emulators interpose on/translate every instruction

You can use an HVM if the expected CPU architecture is the same;
emulation if they are different
 - so WINE really virtualizes, but MAME emulates
   (WINE is running x86 binaries on an x86 processor, while
    MAME may be running 6502 or ARM binaries on an x86 processor)

Running multiple kernels on a hypervisor may be safer, but it is less efficient

What you often want to do is to partition a system so it can run multiple
applications without them interfering with each other, while still trusting the binaries (they aren't trying to attack each other)

Contrast with a linux distribution
 - upgrade one package, it can break an arbitrary number of programs
 - dependencies help, but they only work when they are tested carefully

Containers are a strategy for avoiding this work

Basic idea: a container is everything in an OS *except* the kernel
 - all of userland
 - libraries, config files, binaries, data files
 - normally these are minimized so they are just enough for one application,
   but this is not strictly necessary

Docker is just containers

Docker is a bit tricky when running on a non-Linux system because it
has to supply its own Linux kernel (i.e., it will do hardware
virtualization under the containers).  A system running Linux natively
has no need to do this.
 - in theory you could have containers of MacOS or Windows userlands,
   but that just isn't a thing


Next time: containers from scratch
 - they are a pain but you can do it

The problem with containers is security
 - UNIX/Linux kernels weren't designed for this kind of separation
 - lots of ways containers can interfere with each other on the same machine

In general, you should only run containers that you trust

WebAssembly?  Have you heard of it or not?

WebAssembly is a technology for running arbitrary programs inside a web page
 - use C, C++, Rust, whatever, inside of a web page
 - compile code to webassembly and the browser will run it
 - allows us to avoid JavaScript

But...JavaScript is not trusted, but we normally trust the binaries we run
in other languages.

JavaScript is sandboxed...using a language-based virtual machine
 - JavaScript code inherently can't access your filesystem, other processes,
   etc - it can just make system calls

WebAssembly gets it safety because its code runs inside the same JavaScript
sandbox

This safety is so important it is moving beyond the web browser to servers
(meaning containers)

Instead of compiling down to x86 or ARM, you'll compile to WebAssembly and
run the binary anywhere - and the binary will be nicely sandboxed so everyone
is protected.
 - this solves the main limitation of containers


WebAssembly is safe because of the lack of direct access to system calls
 - which says something about system calls

system calls, even with users, groups, and permissions, are not that safe of an interface
 - not designed to prevent real malicious behavior

so we're moving away from system calls as the general abstraction for accessing
system resources

So really in the future OS and web classes will have to merge
 - it will be all the same technology stack
 - but give it a decade, and still a conventional UNIX-like kernel will
   be there underneath it all

And to be honest...I don't think webassembly helps us much today in the browser,
because most of the code running there is user hostile (ads, tracking, miners)