https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=Operating_Systems_2015F_Lecture_24 2026-04-22T13:25:15Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=Operating_Systems_2015F_Lecture_24&diff=20419&oldid=prev 2015-12-04T21:04:07Z

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

Soma