Operating Systems 2018F Lecture 10

Note this lecture did not take place in our usual classroom; instead, it took place via BigBlueButton.

I forgot to hit record so I don't have a recording of the session. If any of you recorded the audio please let me know and I will post it. Sorry!

Notes from Lecture

Lecture 10
----------
Topics
 - shared memory
 - format, questions on Test 1
 - Assignment 2 finalized, submissions open

 - randomness
 - /dev/random, /dev/urandom
 - interrupted system calls

Randomness

randomness versus pseudo-randomness

pseudo-random
  - looks statistically random
  - but is generated by an algorithm
  - so, it is deterministic
  - to get different outputs, need a different "seed"


Staticstical randomness is relatively easy
has no relationship to predictability

If you want hard to predict, you need a "cryptographically secure"
pseudo-random number generator

/dev/urandom - cryptographically secure pseudo-random number generator...
               seeded by /dev/random (or, the data behind it)

/dev/random - source of "true" randomness

ultimate source of randomness is physics
 - flipping a coin
 - radioactive decay
 - turbulent movement

/dev/random is connected to device drivers
 - devices can have access to real randomness (physics phenomena)
 - examples
   - time for a hard drive head to settle down in a new position
   - inter-arrival times of network packets
   - CPUs have built-in "random number generators" based on
     physical phenomena
   - static on an audio device

physical processes won't be unbiased - there will be a probability distribution

So, what /dev/random does is
  - gathers events from different "random" sources
  - merges them together and processes them so you get a set
    of uniform random bits

/dev/random is expensive in two ways
  - processing (whitening) costs some cycles
  - but most expensive is waiting for the events!



Interrupted system calls

this borders on a complex topic: scheduling

How does the kernel switch between running processes?

When a system call happens
 - process makes a system call
 - CPU switches to supervisor mode, jumps to system call handler
 - kernel processes system call
 - kernel switches CPU to user mode and sets up
   registers so process resumes where it left off
   (with results of system call in registers and the stack)

Why does the kernel have to return to the same process that
made the system call?
 - IT DOESN'T

What about sleep?

system call nanosleep just tells the kernel to wait for a while before
running this process again

Supervisor mode versus user mode

Supervisor mode
---------------
 - kernel code
 - entered by a
    - process making a system call
    - interrupt from a hardware device
 - runs on CPU directly with full privileges
 

User mode
---------
 - process code
 - entered by kernel running the process (switching from supervisor->user mode)
 - runs on CPU directly, but with limited privileges
 
Could I run strace for ALL system calls on a system