CSE 451: Operating Systems Section 2 Interrupts, Syscalls, Virtual Machines, and Project 1.

Slides:



Advertisements
Similar presentations
More on Processes Chapter 3. Process image _the physical representation of a process in the OS _an address space consisting of code, data and stack segments.
Advertisements

Memory Protection: Kernel and User Address Spaces  Background  Address binding  How memory protection is achieved.
CSCC69: Operating Systems
The Kernel Abstraction. Challenge: Protection How do we execute code with restricted privileges? – Either because the code is buggy or if it might be.
Chapter 6 Limited Direct Execution
CSC 501 Lecture 2: Processes. Von Neumann Model Both program and data reside in memory Execution stages in CPU: Fetch instruction Decode instruction Execute.
CSE 451: Operating Systems Section 2 Shells and System Calls.
Processes CSCI 444/544 Operating Systems Fall 2008.
1 CSE 451 Section Autumn 2004 Alex Moshchuk Office hours: Tue 1-2, Thu 4:30-5:30 Allen 218 (or lab)
CSE 451 Section Autumn 2005 Richard Dunn Office hours: WTh 3:30-4:20 Allen 216 (or lab)
OS Spring’03 Introduction Operating Systems Spring 2003.
Advanced OS Chapter 3p2 Sections 3.4 / 3.5. Interrupts These enable software to respond to signals from hardware. The set of instructions to be executed.
1 Process Description and Control Chapter 3 = Why process? = What is a process? = How to represent processes? = How to control processes?
Threads CS 416: Operating Systems Design, Spring 2001 Department of Computer Science Rutgers University
Process Description and Control A process is sometimes called a task, it is a program in execution.
Virtual Machine Monitors CSE451 Andrew Whitaker. Hardware Virtualization Running multiple operating systems on a single physical machine Examples:  VMWare,
CSE 451: Operating Systems Autumn 2013 Module 6 Review of Processes, Kernel Threads, User-Level Threads Ed Lazowska 570 Allen.
Tanenbaum 8.3 See references
1 CS503: Operating Systems Part 1: OS Interface Dongyan Xu Department of Computer Science Purdue University.
System Calls 1.
CSC 501 Lecture 2: Processes. Process Process is a running program a program in execution an “instantiation” of a program Program is a bunch of instructions.
Architecture Support for OS CSCI 444/544 Operating Systems Fall 2008.
Operating Systems ECE344 Ashvin Goel ECE University of Toronto OS-Related Hardware.
Lecture 3 Process Concepts. What is a Process? A process is the dynamic execution context of an executing program. Several processes may run concurrently,
Tami Meredith, Ph.D. CSCI  Devices need CPU access  E.g., NIC has a full buffer it needs to empty  These device needs are often asynchronous.
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Operating Systems Overview Part 2: History (continued)
1 CSE 451 Section 2: Interrupts, Syscalls, Virtual Machines, and Project 1.
1 CSE451 Architectural Supports for Operating Systems Autumn 2002 Gary Kimura Lecture #2 October 2, 2002.
CSE 451: Operating Systems Section 3: Project 0 recap, Project 1.
Operating Systems Process Creation
1 Computer Systems II Introduction to Processes. 2 First Two Major Computer System Evolution Steps Led to the idea of multiprogramming (multiple concurrent.
4300 Lines Added 1800 Lines Removed 1500 Lines Modified PER DAY DURING SUSE Lab.
Lecture 26 Virtual Machine Monitors. Virtual Machines Goal: run an guest OS over an host OS Who has done this? Why might it be useful? Examples: Vmware,
Genesis: From Raw Hardware to Processes Andy Wang Operating Systems COP 4610 / CGS 5765.
Bootable Programs Building an O/S. Basic Requirements of any O/S Respond to interrupts (all kinds) Preserve user environment Protect users and self from.
CSE 451: Operating Systems Winter 2015 Module 25 Virtual Machine Monitors Mark Zbikowski Allen Center 476 © 2013 Gribble, Lazowska,
CSE451 Section 2: Spring 2006 Kurtis Heimerl, YongChul Kwon
Lecture 5 Rootkits Hoglund/Butler (Chapters 1-3).
1 CSE 451 Section 2: Processes, the shell, and system calls.
CSE 451 Section Autumn 2004 Alex Moshchuk Office hours: Tue 2-3, Thu 4:30-5:30 Allen 216 (or lab)
1 Intro to the Shell with Fork, Exec, Wait Sarah Diesburg Operating Systems CS 3430.
S ALVATORE DI G IROLAMO (TA) Networks and Operating Systems: Exercise Session 1.
Threads prepared and instructed by Shmuel Wimer Eng. Faculty, Bar-Ilan University 1July 2016Processes.
CSE 451 Section #3 Project 0 Recap Project 1 Overview
Virtual Machine Monitors
Introduction to Operating Systems
Introduction to Operating Systems
Processes and threads.
Operating Systems CMPSC 473
CSE 451 Section 2: Processes, the shell, and system calls
Protection and OS Structure
CS 6560: Operating Systems Design
Protection of System Resources
Lecture 24 Virtual Machine Monitors
CS 3305 System Calls Lecture 7.
Intro to Processes CSSE 332 Operating Systems
OS Virtualization.
CSE 451: Operating Systems Spring 2012 Module 6 Review of Processes, Kernel Threads, User-Level Threads Ed Lazowska 570 Allen.
CSE 451 Section 2 – Winter 2006.
Process Control B.Ramamurthy 2/22/2019 B.Ramamurthy.
CSE 451 Section 2 - Spring 2005.
CSE 451: Operating Systems Autumn 2003 Lecture 2 Architectural Support for Operating Systems Hank Levy 596 Allen Center 1.
CSE 451: Operating Systems Autumn 2001 Lecture 2 Architectural Support for Operating Systems Brian Bershad 310 Sieg Hall 1.
CSE 451: Operating Systems Autumn Module 24 Virtual Machine Monitors
Unix Process Control B.Ramamurthy 4/11/2019 B.Ramamurthy.
CSE 451: Operating Systems Winter 2003 Lecture 2 Architectural Support for Operating Systems Hank Levy 412 Sieg Hall 1.
Process Description and Control in Unix
CSE 451: Operating Systems Autumn Module 24 Virtual Machine Monitors
Chapter 2: OS Structures CSS503 Systems Programming
Lecture Topics: 11/20 HW 7 What happens on a memory reference Traps
Presentation transcript:

CSE 451: Operating Systems Section 2 Interrupts, Syscalls, Virtual Machines, and Project 1

Interrupts Interrupt Hardware or software Hardware interrupts caused by devices signaling CPU Software interrupts caused by code Exception Unintentional software interrupt E.g. errors, divide-by-zero, general protection fault Trap Intentional software interrupt Controlled method of entering kernel mode System calls 4/5/2012 2

Interrupts (continued) Execution halted CPU switched from user mode to kernel mode State saved Registers, stack pointer, PC Look up interrupt handler in table Run handler Handler is (mostly) just a function pointer Restore state CPU switched from kernel mode to user mode Resume execution 3 4/5/2012

Interrupts (continued) What happens if there is another interrupt during the handler? The kernel disables interrupts before entering a handler routine What happens if an interrupt fires while they are disabled? The kernel queues interrupts for later processing 4 4/5/2012

System calls Provide userspace applications with controlled access to OS services Requires special hardware support on the CPU to detect a certain system call instruction and trap to the kernel 5 4/5/2012

System call control flow User application calls a user-level library routine ( gettimeofday(), read(), exec(), etc.) Invokes system call through stub, which specifies the system call number. From unistd.h : #define __NR_getpid 172 __SYSCALL(__NR_getpid, sys_getpid) This generally causes an interrupt, trapping to kernel Kernel looks up system call number in syscall table, calls appropriate function Function executes and returns to interrupt handler, which returns the result to the userspace process 6 4/5/2012

System call control flow (continued) 7 4/5/2012 Specifics have changed since this diagram was made, but idea is still the same

How Linux does system calls The syscall handler is generally defined in arch/x86/kernel/entry_[32|64].S In the Ubuntu kernel I am running (2.6.38), entry_64.S contains ENTRY(system_call), which is where the syscall logic starts There used to be “ int ” and “ iret ” instructions, but those have been replaced by “ sysenter ” and “ sysexit ”, which provide similar functionality. 8 4/5/2012

Syscalls in a virtual machine For software VMMs (e.g. VMWare Player, VirtualBox, Microsoft Virtual PC), there are a couple options: Install hardware interrupt handler for each VM (requires CPU support, such as with Core 2 Duo and up) Use dynamic rewriting to avoid hardware trap entirely For paravirtualized VMMs (e.g. Xen) parts of the OS are actually rewritten to avoid hardware traps For hardware VMMs a.k.a embedded hypervisors (e.g. VMWare ESX), sandboxing requirements are smaller, as the only user-mode entities are VMs Is one approach “best”? 9 4/5/2012

Project 1 Three parts of varying difficulty: Write a simple shell in C Add a new system call and track state in kernel structures to make it work Write a library through which the system call can be invoked Due: April 18 at 11:59 PM. Turn in code plus a writeup related to what you learned/should have learned 10 4/5/2012

The CSE451 shell Print out prompt Accept input Parse input If built-in command Do it directly Else spawn new process Launch specified program Wait for it to finish Repeat 11 4/5/2012 CSE451Shell% /bin/date Sat Mar 31 21:58:55 PDT 2012 CSE451Shell% pwd /root CSE451Shell% cd / CSE451Shell% pwd / CSE451Shell% exit

CSE451 shell hints In your shell: Use fork to create a child process Use execvp to execute a specified program Use wait to wait until child process terminates Useful library functions (see man pages): Strings: strcmp, strncpy, strtok, atoi I/O: fgets Error report: perror Environment variables: getenv 12 4/5/2012

CSE451 shell hints (continued) Advice from a previous TA: Try running a few commands in your completed shell and then type exit. If it doesn’t exit the first time, you’re doing something wrong. echo $? prints the exit code, so you can check your exit code against what is expected. Check the return values of all library/system calls. They might not be working as you expect Don’t split the project along the three parts among group members. Each one should contribute some work to each part or you won’t end up understanding the big picture. 13 4/5/2012

Adding a system call Add execcounts system call to Linux: Purpose: collect statistics Count number of times you call fork, vfork, clone, and exec system calls. Steps: Modify kernel to keep track of this information Add execcounts to return the counts to the user Use execcounts in your shell to get this data from kernel and print it out. Simple, right? ;) 14 4/5/2012

Programming in kernel mode Your shell will operate in user mode Your system call code will be in the Linux kernel, which operates in kernel mode Be careful - different programming rules, conventions, etc. 15 4/5/2012

Userspace vs. kernel mode conventions Can’t use application libraries (e.g. libc) E.g. can’t use printf Use only functions defined by the kernel E.g. use printk instead Include files are different in the kernel Don’t forget you’re in kernel space You cannot trust user space For example, you should validate user buffers (look in kernel source for what other syscalls, e.g. gettimeofday() do) 16 4/5/2012

Kernel development hints Use grep as a starting point to find code For example: find. –name *.c | xargs grep –n gettimeofday This will search all c files below your current directory for gettimeofday and print out the line numbers where it occurs Pete has an awesome tutorial on the website about using ctags and cscope to cross-reference variable, struct, and function definitions: 12sp/tutorials/tutorial_ctags.html 12sp/tutorials/tutorial_ctags.html 17 4/5/2012

Kernel development hints (continued) Use git to collaborate with your project partners Pete has a guide to getting git set up for use with project 1 on the website: 12sp/tutorials/tutorial_git.html 12sp/tutorials/tutorial_git.html Overview of use: Create a shared repository in /projects/instr/12sp/cse451/X, where X is your group’s letter Check the project’s kernel source into the repository Have each group member check out the kernel source, make modifications to it as necessary, and check in their changes See the web page for more information 18 4/5/2012

Project 1 development Option 1: Use VMWare on a Windows lab machine Can use forkbomb for kernel compilation (fast) …or use the VM itself for kernel compilation (slow) The VM files are not preserved once you log out of the Windows machine, so copy your work to attu, your shared repository, or some other “safe” place Option 2: Use your own machine Can use VMWare, VirtualBox, or your VMM of choice See the “VM information” page on the website for getting this set up 12sp/vminfo.html 12sp/vminfo.html 19 4/5/2012

Project 1 development (continued) If you build the kernel on forkbomb, copy the resulting bzImage file to your VM and overwrite /boot/vmlinuz CSE451 If you build the kernel inside the VM, run sudo make install from inside the kernel directory to install it Reboot with shutdown –r now If your kernel fails to boot, pick a different kernel from the menu to get back into the VM While inside the running VM, use the dmesg command to print out the kernel log (your printk s will show up here—use grep to find the ones you care about) 20 4/5/2012