CS 111 Scribe Notes Lecture 4

How to organize an OS

• One approach: an Object Oriented System
  • Pick a language such as Java, C++, Objective C, etc.
• But, it is too slow and does not provide hard modularity. How do we deal with this?
  • Answer: Use C. This is the approach opted for by the Linux Kernel. Can use object oriented langauges such as Java and C++ to develop apps.

Objective: Hard Modularity

1. Client Server (to be covered in Lab 4)
2. Virtualization (to be covered in Lab 2 and 3)
   1. The advatage of virtualization is that applications do not run on the actual hardware, instead they run on virtual machines, like a "sandbox." By not letting the applications run on the actual hardware, the applications are not able to trash anything. This approach mimics a "sandbox" because the app cannot affect anything outside the boundaries of the virtual machine.
   2. The simplest approach? Use an interpreter!
      • The interpreter implements and simulates all of the neccessary functionalities of a given OS (x86 for example) needed to run the application
   3. Pros:
      1. Apps can be for some other hardware
      2. Apps can't escape the sandbox. The interpreter checks if an app tries to go outside their specified domain, the interpreter halts it.
      3. Multiple virtual machines can run on a single physical machine
   4. Cons:
      1. Performance - it's slower (If written naively, it is about 10x slower; if written well, ~1.2x slower)

Virtualizable Processor

The goal of the virtualizable processor is to protect the transfer of control. This is accomplished by not letting people execute arbitrary privileged code, but instead may only execute privileged code at specific spots.

Instruction categories:

Features of a virtualizable processor

• Extra register (Am I privileged?).
  • Whether an instruction is privileged or not is part of the machine state.
  • The extra register indicates whether the instruction you are trying to execute is in privileged mode.
  • Instructions set and clear this bit, but it defaults to 1.
• Instruction Handling
  • If instruction is nonprivileged: executes as normal
  • If instruction is privileged:
    • If the privileged bit is set: executes as normal
    • If the privileged bit is NOT set: program will TRAP
• Allows us to do virtualization without any performance loss.

Structuring virtual memory

Solely partitioning memoring into a section dedicated for apps, and a section for OS does not work. If this approach were used, an app could just jump to a location in the OS, bypassing any authorization checks. Instead, We need a Protected Transfer of Control.

• This will only let unprivileged apps access code at certain locations (restricted regions of memory so that the instruction pointer can only be set to a few certain locations in that region)

• Instead, the hardware traps,
  • By convention, there is a "trap vector" built into the hardware. It contains (again, by convention) 256 entries (256 kinds of traps). Each entry points a location in the OS code to execute when that specific trap occurs
  • There is also a bit that indicates what to set the privileged bit to when the trap occurs (usually this is 1)
  • The trap vector is not visible to applications. An application trying to view the trap vector triggers a trap

When you trap, the x86 pushes:

• Certain registers are set to hold the instruction number, arguments, and return location

Operating systems can be partitioned to make sure that applications access instructions properly. The kernel can have exclusive access to privileged ones, while ordinary instructions can be accessed by everyone. There's also the idea of recursively programmed kernels using the two privileged bits in x86. These bits could be used to organize into four levels.

• k0: Core notions like memory management
• k1: Processes
• k2: Device drivers
• k3: Apps

• Lets us support the concept of a Process:
  • A program in execution in an isolated domain (think of it as a standalone program running on a virtual machine)
• What can go wrong?
  1. Problem: Program issues only non-privileged instructions, never does a system call, so the kernel never takes charge (eg infinite loop)
     • Solution: Change the hardware so that a trap occurs every so often no matter what (10ms perhaps)
  2. Problem: Program may attempt to access secrets inside other programs, such as load instructions, or even writing content
     • Solution: One possibility is that while program is running, hide the other programs on disk (however, this is slow). A faster approach is to use a virtual machine.
  3. Problem: A program can access I/O devices
     • Solution: I/O instructions, such as {inb, inst, outb} are all privileged instructions.
     • This means that I/O is more expensive because of the cost of the system call

Processes are restricted and hence can't modify their own memory. The process descriptor table (PDT) lives in memory and hold the register values and information for all processes not at the foreground. If process 3 is running, then the values in its row in the PDT are garbage (performance reasons). We can't rely on them being accurate. If the kernel performs a context switch to another process, then the PTE for process 3 is updated to last accurate values but the values for the new process are now junk.

• _Noreturn void exit(int);
  • Noreturn means its not coming back from the call, you're done after this
  • Arg is between 0 and 255
• pid_t fork(void)
  • You call fork once, but it returns twice (fork copies stack frames)
  • Returns the pid of the child process if its in the parent process, 0 if it is in the child process
  • If it fails, returns -1, sets errno
  • Example of usage with differing behavior for parent and child processes
    • p = fork();
    • switch(p) {
      • case -1: error(1);
      • case 0: Child behavior
      • default: Parent behavior
      }

Note: Execution order of child/parent processes is not predictable/guaranteed. For example, if the parent prints "hello" and the child prints "goodby," you may get the result: "hgcololdoby."