By David Kim, Sina Siar, and Sheng Cheng

http://www.read.cs.ucla.edu/111
Eddie Kohler kohler@cs.ucla.edu
OH: Monday 4-5pm, Tuesday 11-12pm; Boelter Hall 4531

Jacob Lacouture jacobl@ucla.edu
Jon Salehpour jsalehpo@ucla.edu

Linux Lab: Boelter Hall 4405
Linux Users Group. For more details about Fall Install fest please go to http://linux.ucla.edu

• 1/3 Midterm (11/5 ~13%) & Final (12/14 ~20%)
• 1/3 Labs: Equally distributed. Working in pairs (Optional)
  1. Shell (2 Parts); 1A: C Programming (10/5) and 1B (10/19)
  2. Concurrency & Synchronization (kernel)
  3. File System Implementation (kernel)
  4. Distributive Systems Project
     • Design Report: 4-6 pages on one of the labs
• 1/3 Other work
  1. Mini-labs: There will be two to three smaller labs for the quarter designed to offer some hands-on experience with course concepts. Work should be submitted individually.
  2. 1 page report on current OS topics due at the end of the quarter
  3. Scribe Notes: everyone responsible for one lecture in groups of 3
  4. Other

The job of operating system is to provide computer software applications with an abstract machine.

It abstracts and virtualizes all of a computer’s resources (including I/O devices, memory, and CPU time) by permitting the use of the same hardware at once by many applications.

• Robustness: the OS is resistant to either application or underlying hardware failure (some argue that this is the most important goal of a good OS)
• Utilization: applications should be able to use all of the hardware resources
• Performance: applications run quickly
• Versatility: many different applications should be supported
  • EX. (Bad Versatility) Old Vertical Market Computers used to be specialized such that software for one application on one system could not be ran on another
• Simplicity: easy to understand and use

This class is about INTERFACES. Every program uses operating system facilities or is an operating system. Problems in the operating system's abstract machine interface can affect every program using that operating system. Improvements in the operating system interface can make every program using that operating system better. The abstract machine provided by the operating system is the most important interface in computer software. The abstract machine interface makes systems engineering challenges clear, concrete, and easy to understand.

What can go wrong with a bad interface? An example of a bad interface is when one program could overwrite other programs' memory (memory protection).


Blue screen of death of an example of a OS not having proper memory protection.

What makes a good interface good?
The abstract machine interface is one of the great ideas in computer science.

• 1971, first OS interface to come together

• Computers at that time were huge, power-hungry, and terribly slow. The pictured computer had 512K core memory. Core is old memory technology; each bit of core memory is stored in a donut-shaped magnetic ceramic ring, where the polarity of the magnetic field determines the bit's value; three wires go through the rings' holes. Roughly 1 MHz.

• The image, uncompressed, of that 1973 Materials Inventory Support System computer takes 625131 bytes; or 100843 more bytes than the computer itself could hold.
• 1973, third release of UNIX introduced C programming and Pipes
• Scaling facts: no technology in history has evolved faster than computing technology; however, Unix has survived all these years and stood the test of time.
• Some more scaling examples: 1973 Ethernet was 3Mb/s; today's Ethernet is 10Gb/s -- roughly 3333x faster. 1983 magnetic disks cost about $200,000/GB; today it is about $.10/GB -- roughly 2 million times cheaper.
  

Interfaces and implementations are tightly bounded. Operating systems demonstrate the challenges involved in implementing a good interface. The distance from a processor's instruction set to an abstract machine interface is vast.

• The processor does exactly what applications ask.
• The operating system prevents applications from misusing this power. For example,
  

      /*This code would loop forever, and the job of OS is to actually stop a process
 that is monopolizing resources.*/
      while(1){
             //do nothing
      }

Property of a system that only shows up in a whole system and not in the individual components

• Description: An untrusted program (secure) retrieves user input username/password and then communicates with a trusted program to verify whether the username/password match.
• Goals:
  1. The untrusted program does not know and cannot discover Alice’s password
  2. The trusted program can discover whether the untrusted program knows Alice’s password

/*Case 1: The following get_pwd prototype violets our first goal. Since it provide an
 interface for untrusted program to access Alice's password*/
const char * get_pwd(const char * user)

/*Case 2: The following prototype return 1 if password matches, otherwise, return 0 */
int pwd_check(const char * username, const char * password)
     //  -> 1 if password match
     //  -> 2 if password  doesn't match
/*By itself it is a good interface*/

Now consider a system as a whole where some memory is off limits (memory protection), then case 2 will not be a good interface. If the application does not own the memory, it cannot touch it; if it does the OS kills the application.

/* Case 3: If application touches bad memory, kill it. */
int pwd_check(const char * username, const char * password)
{
const char * real_password = password_for_user;
//return strcmp (real_pwd, pwd) == 0;     this would crash the entire program. 
//We need an alternative solution:
while ( * real_password) {
   if( //password is a bad address )
      kill  the process ;
   else if (* real_password != * password)
      return 0;
   else 
      real_password++;
      password++;
 }// Compare the lengths of real_pwd and pwd
}

Evil program can find the password by iterating through all characters one by one until the process is killed. Then program repeats for each following character.

Small changes to one component of a system often ends up affecting the entire system as a whole.

EX. Networking affects the file API: If a disk being run on the local machine is broken an error message is received when trying to communicate with the disk; if the disk is being accessed over a network from another computer and the line is broken then no error message is received since communication never occurred with the disk.

Not all parts of a system follow the same scaling rules, therefore a system increasing in size or speed may stop working. For example,

• A 50 foot person cannot have the same ratios of someone of normal height since weight is a cubic measurement while bone strength is a square measurement and the added weight would crush the person’s bones.
• Hard disks have gotten cheaper but not relatively faster because of its very physical operation.
  • Modern disks rotate around 7200RPM and consist of magnetic material with polarity depending on the value.
  • Assuming the desired information resides on an inner track of the disk, the magnetic arm must accelerate and move towards the inner track before coasting and stopping in the desired region. Then the head must wait for the disk to rotate such that the desired information passes over the head.

Some system goals directly conflict and the system must balance these competing requirements; typically a trade-off between robustness vs. performance.

For example, spam filtering is a trade-off between not getting any spam e-mails along with possibility of not receiving "non-spam" e-mails.