Operating Systems 2015F Lecture 24
Video
Video from the lecture given on December 4, 2015 is now available.
Notes
Lecture 24 ---------- * /dev/random * the Future Randomness - unpredictable - unbiased (not predictable even in a statistical sense) More precisely 1. sequences of numbers that appear to be random according to statistical tests of randomness 2. unpredictable There exist sequences that pass #1 but not #2 pseudo-random numbers - digits of irrational numbers (e.g., pi) - almost any cryptographic primitive (encryption, hash) - pseudo-random number generators How can computers ever be unpredictable? - generating pseudo-random numbers is easy, just run the right algorithm - using a random "seed" you can get arbitrarily long sequences of random-looking numbers that vary over time - but how do you get the seed? And what about reversing the algorithm? Computers cannot produce randomness on their own. They need help from the outside world. Sources of "real world" randomness observable by the OS - user input (keyboard, camera, microphone, mouse) - network traffic (inter-arrival time of packets) - device behavior (settling time of a spinning hard drive) But *why* do you want randomness in a computer system? * unpredictable program behavior - shuffling songs - games * simulations * randomized algorithms - genetic algorithms, other search algs * cryptographic keys For everything except cryptography, pseudo-random number generators are more than good enough - caveat: some simulations need "high quality" random number generators For crypto, you need things that are truly unpredictable What sources of real world behavior are not observable/potentially influenced by attackers? * most can be observed or influenced Solution: CPUs include hardware random number generators * but, do you really trust them? Instead, trust nobody but use everything you can /dev/random & /dev/urandom - grabs whatever source of randomness it can, adds it to an "entropy pool", "stirring" it using cryptographically secure hash functions /dev/random - only outputs as many bits as its estimate of entropy in the entropy pool /dev/urandom - produces as many bits as requested; security is limited to number of bits in entropy pool Use /dev/urandom for short-term keys, other stuff Use /dev/random for long term keys How good is /dev/random in a virtual machine? - depends on the hypervisor The future ---------- An operating system turns the computer you have into the computer you want to program (or use) - abstraction and resource management OSs change when computers change and when how we use them change Embedded systems - many many kinds Internet-of-Things Personal devices Tablets Laptops Workstations Clusters Data centers Mainframes Why in the world would one OS ever span all of these? But we do! Top-level concerns - network connectivity - heavy concurrency, certain device drivers - security - power constrained - in data centers, they care about "performance per watt" - because power and cooling are huge expenses Feasible to use same code base because hardware is all "powerful enough" The future will be roughly the same, OS-wise Change comes from duplication and refactoring - containers are just packaged OS-level virtualization Learn the tools New tools will come along to help handle complexity - but the concepts will be the same - and most of the mechanisms