Class 1: What is an Operating System?

Posted: Tue 14 January 2014


Videos

Action Items

You should do at least these three things before Thursday's class:

  1. Read the Course Syllabus.

  2. Setup Rust on your computer by either:

    • Installing VirtualBox following these directions. (This should work for everyone. It takes a long time to download so get started early. This is the simplest way to get started, but can be a bit slow and klunky.)
    • Setting up Rust to run natively on your machine, following these directions. If you are running Mac OS X or Linux, this is probably the best option. There is a native Windows version of Rust also, but it requires quite a bit of effort to set up.
    • Setting up an Amazon EC2 instance for running Rust following these directions.
  3. Set up your student github account, following these directions.

By 4:59pm on Sunday, you should also submit Problem Set 0 which includes completing part 1 of the Rust tutorial and course registration survey.

Before next Tuesday's class:

  • Read Introduction to Operating Systems from Remzi H. Arpaci-Dusseau and Andrea C. Arpaci-Dusseau's Operating Systems: Three Easy Pieces book. (This book is freely available on-line, but may also be ordered as a printed book for $29. We will have several readings from the book during the semester, all of which are also freely available on-line, but if you prefer to read things in printed form I encourage you to buy the printed book.)

Don't forget to bring your laptop to Thursday's class. If you do not have access to a suitable machine for use in this class, please contact me right away. The department does have a few loaner machines that may be available for you to borrow.

Operating Systems

What is an operating system?

What fraction of a baby's toys had an operating system in 1990? What about in 2014? What fraction would you expect in 2020

What aspects of computing seem like magic to you today?

Programming Languages

Why are there so many programming languages?

  • Languages change the way we think.

  • Languages provide abstractions for machine resources. The abstractions they provide are engineering tradeoffs between:

    • expressiveness and "truthiness"
    • freedom and safety
    • flexibility and simplicity
    • efficiency and ease-of-use

Which of these should we prefer for a programming language for systems programming?

What's the difference between a language and an operating system?

Rust

Rust is a systems programming language developed by Mozilla Research. It is a new and immature language: the release we are using is Version 0.9 (released last week).

Rust is designed with a particular focus on providing both safety and control. This means it provides programmers with a lot of control over how memory is managed to enable efficient programs, but without the opportunity to shoot yourself in the foot so readily provided by C/C++. Much of the design is driven by the needs of Servo, an experimental, highly-parallelizable web browser engine.

Discussion

In the discussion, please answer "What aspects of computing seem like magic to you today?" and feel free to also use the discussion below for any comments about Class 1 (including thoughts on the questions above).

Next Class

comments powered by Disqus


Class 10: SSL, Sharing, and Scheduling

Posted: Tue 25 February 2014

Problem Set 3 is due on Monday, 3 March. You should have definitely at least finished Problem 4 by today. [Note: extended to 5 March.]


Videos

goto fail;

Apple's SSL implementation (extracted from sslKeyExchange.c): (original indentation and whitespace preserved for lack-of-clarity)

static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
                                 uint8_t *signature, UInt16 signatureLen)
{
    OSStatus        err;
    SSLBuffer       hashOut, hashCtx, clientRandom, serverRandom;
    uint8_t         hashes[SSL_SHA1_DIGEST_LEN + SSL_MD5_DIGEST_LEN];
    SSLBuffer       signedHashes;
    uint8_t         *dataToSign;
    size_t          dataToSignLen;

    signedHashes.data = 0;
    hashCtx.data = 0;

    clientRandom.data = ctx->clientRandom;
    clientRandom.length = SSL_CLIENT_SRVR_RAND_SIZE;
    serverRandom.data = ctx->serverRandom;
    serverRandom.length = SSL_CLIENT_SRVR_RAND_SIZE;

    ...
    hashOut.data = hashes + SSL_MD5_DIGEST_LEN;
    hashOut.length = SSL_SHA1_DIGEST_LEN;
    if ((err = SSLFreeBuffer(&hashCtx)) != 0)
        goto fail;

    if ((err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0)
        goto fail;
    if ((err = SSLHashSHA1.update(&hashCtx, &clientRandom)) != 0)
        goto fail;
    if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
        goto fail;
    if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
        goto fail;
        goto fail;
    if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
        goto fail;

    err = sslRawVerify(ctx,
                       ctx->peerPubKey,
                       dataToSign,              /* plaintext */
                       dataToSignLen,           /* plaintext length */
                       signature,
                       signatureLen);
    if(err) {
        sslErrorLog("SSLDecodeSignedServerKeyExchange: sslRawVerify "
                    "returned %d\n", (int)err);
        goto fail;
    }

fail:
    SSLFreeBuffer(&signedHashes);
    SSLFreeBuffer(&hashCtx);
    return err;

}

Test your SSL implementation Apple's Security Post Apple's SSL/TLS Bug (Adam Langley)

What are differences between Rust and C that make this time of fail much less likely?

What software development practices should be followed for any production code to greatly reduce the chances of these types of mistakes not being caught?

Theory Excursion

How hard is it to detect unreachable code in theory?

What should compilers do when desired decision procedures are undecidable?


Catch up on your theory with Dori-Mic and the Universal Machine!

Sharing across Tasks

unsafe2.rs

static mut count: uint = 0; 

fn update_count() { unsafe { count += 1; } }

fn main() {
    for _ in range(0u, 10) {
        spawn(proc() {
           for _ in range(0u, 1000) {
              update_count();
           }
        });
    }
    println!("Count: {:}", unsafe { count });
}

Assembly code produced by rustc -S unsafe2.rs: unsafe2.s

    .section    __TEXT,__text,regular,pure_instructions
    .align  4, 0x90
__ZN12update_count19h86817af0b0797e96al4v0.0E:
    .cfi_startproc
    cmpq    %gs:816, %rsp
    ja  LBB0_0
    movabsq $16, %r10
    movabsq $0, %r11
    callq   ___morestack
    ret
LBB0_0:
    pushq   %rbp
Ltmp2:
    .cfi_def_cfa_offset 16
Ltmp3:
    .cfi_offset %rbp, -16
    movq    %rsp, %rbp
Ltmp4:
    .cfi_def_cfa_register %rbp
    pushq   %rax
    movq    __ZN5count19hc6afed277fb1b6c3ah4v0.0E(%rip), %rax
    addq    $1, %rax
    movq    %rax, __ZN5count19hc6afed277fb1b6c3ah4v0.0E(%rip)
    movq    %rdi, -8(%rbp)
    addq    $8, %rsp
    popq    %rbp
    ret
    .cfi_endproc
...

Where is the data race?

RWArc - automatically reference-counter storage protected by a reader-writer lock

Why is it useful to have separate locks for reading and writing?

extern mod extra; 
use extra::arc::RWArc;

fn update_count(counter: RWArc<int>) {
    counter.write(|count: &mut int| { *count += 1; });
}

fn main() {
    let counter: RWArc<int> = RWArc::new(0);

    for _ in range(0, 10) {
        let ccounter = counter.clone(); // need the clone - this moves counter
        spawn(proc() {
           for _ in range(0, 1000) {
              update_count(ccounter.clone()); // shouldn't be necessary!?
           }
        });
    }

    counter.read(|count| {
       println!("Count: {:d}", *count);
    });

}

Why is the printed count still not 10000?

Scheduling

What are the two main decisions the supervisor needs to make on each kernel timer interrupt?

Max Ehrmann's "Desiderata":

Go placidly amid the noise and haste, and remember what peace there may be in silence. As far as possible without surrender be on good terms with all persons. Speak your truth quietly and clearly; and listen to others, even the dull and the ignorant; they too have their story. Avoid loud and aggressive persons, they are vexations to the spirit... Exercise caution in your business affairs; for the world is full of trickery... And whether or not it is clear to you, no doubt the universe is unfolding as it should... whatever your labors and aspirations, in the noisy confusion of life keep peace with your soul. With all its sham, drudgery, and broken dreams, it is still a beautiful world. Be cheerful. Strive to be happy.

Why is there a fundamental tradeoff between maximizing resource utilization and fairness in scheduling?

comments powered by Disqus


Class 11: Smarter Scheduling (Thu 27 February 2014)

Class 12: Scheduling in Linux and Web Servers (Tue 04 March 2014)

Class 13: The Internet (Thu 06 March 2014)

Class 14: Entering Ring Naught (Tue 18 March 2014)

Class 15: IronKernel Developers (Thu 20 March 2014)

Class 16: Storage (Thu 27 March 2014)

Class 17: Flash! (Tue 01 April 2014)

Class 18: System Calls (Thu 03 April 2014)

Class 19: Synchronization (Tue 08 April 2014)

Class 2: Getting Rustified (Thu 16 January 2014)

Class 20: Mutual Exclusion (Thu 10 April 2014)

Class 21: Bakers and Philosophers (Tue 15 April 2014)

Class 22: Microkernels and Beyond (Thu 17 April 2014)

Class 23: Invent the Future! (Fri 30 May 2014)

Class 24: Project Presentations (Tue 29 April 2014)

Class 3: Zero to a Billion in 4.86 Years (Thu 23 January 2014)

Class 4: Once Upon a Process (Tue 28 January 2014)

Class 5: Gash Has No Privileges (Thu 30 January 2014)

Class 6: Making a Process (Virtualizing Memory) (Tue 04 February 2014)

Class 7: Double Faults (Thu 06 February 2014)

Class 8: Managing Memory (Tue 11 February 2014)

Class 9: Pointers in Rust (Tue 18 February 2014)

Exam 1 Comments (Sun 16 March 2014)

Improving Rust's Error Messages (Wed 22 January 2014)

Preparation for Class 23 (Sun 20 April 2014)

Presentations (Tue 22 April 2014)

Problem Set 3 (Sun 16 February 2014)

Problem Set 3 Benchmarking (Fri 28 February 2014)

PS1 and Tutorial (Mon 20 January 2014)

PS1 Submission (Sun 26 January 2014)

PS2 Demos, Videos (Mon 03 February 2014)

PS2 Reference Solution (Fri 14 February 2014)

PS3 Demos and Submission (Sun 02 March 2014)

PS3 Reference Solution (Wed 02 April 2014)

Spring 2014 cs4414 Course (Sat 11 January 2014)

Submitting Projects (Sun 27 April 2014)

Submitting PS2 (Sat 08 February 2014)

Submitting PS4 (Sat 05 April 2014)

Survey Comments (Thu 23 January 2014)

Updates (Sun 09 February 2014)


Pages

  • Amazon EC2
  • Challenges
  • Classes
  • Forum
  • Getting Started with Github
  • IRC
  • Open Discussion Forum
  • Pages
  • Problem Set 3 - Zhtta Server - Benchmarking
  • Projects
  • Problem Set 0 - Tutorial and Course Registration
  • Problem Set 1 - zhttpto Web Server
  • Problem Set 2 - The Good Auld Shell
  • Problem Set 2 - Exploration 1
  • Problem Set 2 - Exploration 2
  • Problem Set 3 - Zhtta Web Server
  • Problem Set 4 - IronKernel
  • PS4 - Setup Commands
  • Open Enrollment
  • Survey Comments
  • Syllabus
  • Forum
  • Using Materials
  • VirtualBox
  • Working on Github in cs4414
  • Setting up your Zhtta Server on EC2