CS 550 Operating Systems Spring System Call

Transcription

1 CS 550 Operating Systems Spring 2018 System Call 1

2 Recap: The need for protection When running user processes, the OS needs to protect itself and other system components For reliability: buggy programs For security: malicious user programs 2

3 Recap: The need for protection How can we provide this protection? Treat those operations trying to access/modify critical system resources as privileged operations Allow only the OS kernel to perform the privileged operations How? 3

4 Recap: Dual-mode operation Allows OS to protect itself and other system components User mode and kernel mode Mode bit provided by hardware Provides ability to distinguish when system is running user code or kernel code Some instructions designated as privileged (e.g., those accessed/changed system states or critical resources), only executable in kernel mode If executed in user mode, exception To perform privileged operations, must transit into OS through well defined interfaces Interrupt handlers System calls 4

5 CPU s fetch-execute cycle How can external devices notify the CPU about certain events? Interrupts IP: Instruction Pointer (or Program Counter, PC) 5

6 CPU s fetch-execute cycle with interrupt User Program ld add Fetch instruction at IP IP st mul ld sub bne Decode the fetched instruction Execute the decoded instruction Save context Get INTR # add jmp Advance IP to next instruction Lookup ISR Execute ISR IRQ? no yes IRET 6

7 Interrupt hardware (legacy systems) I/O devices have (unique or shared) Interrupt Request Lines (IRQs) IRQs are mapped by special hardware to interrupt numbers, and passed to the CPU This hardware is called a Programmable Interrupt Controller (PIC) 7

8 The Programmable Interrupt Controller (PIC) Responsible for telling the CPU when a specific external device wishes to interrupt Needs to tell the CPU which one among several devices is the one needing service PIC translates IRQ to interrupt number Raises interrupt to CPU Interrupt # available in register Interrupts can have varying priorities PIC also needs to prioritize multiple requests Possible to mask (disable) interrupts at PIC or CPU 8

9 CPU s fetch-execute cycle with interrupt User Program ld add Fetch instruction at IP IP st mul ld sub bne Decode the fetched instruction Execute the decoded instruction Save context Get INTR ID add jmp Advance IP to next instruction Lookup ISR Execute ISR IRQ? no yes IRET 9

10 Interrupt Descriptor Table The entry-point to the interrupt-handler is located via the Interrupt Descriptor Table (IDT) Interrupt Service Routine = IDT[Interrupt number] Also called interrupt handler IDT is in memory, initialized by OS at boot How to locate base of IDT? CPU has a register, idtr, pointing to IDT, initialized by OS via the LIDT (x86) instruction at boot 10

11 CPU s fetch-execute cycle with interrupt User Program ld add Fetch instruction at IP IP st mul ld sub bne Decode the fetched instruction Execute the decoded instruction Save context Get INTR # add jmp Advance IP to next instruction Lookup ISR Execute ISR IRQ? no yes IRET 11

12 Same interrupt mechanism used for other control transfers We ve seen Interrupts: raised externally by device Traps (or exceptions): raised internally by CPU 0: divide-overflow fault 3: breakpoint 6: Undefined Opcode 13: General Protection Exception System call can be implemented this way too Linux system call: int 80h int instruction generates a software interrupt or trap, causing the transition from user mode to kernel mode. 80h is the interrupt ID. 12

13 Dual-mode operation Allows OS to protect itself and other system components User mode and kernel mode Mode bit provided by hardware Provides ability to distinguish when system is running user code or kernel code Some instructions designated as privileged (e.g., those accessed/changed system states or critical resources), only executable in kernel mode If executed in user mode, exception To perform privileged operations, must transit into OS through well defined interfaces Interrupt handlers System calls 13

14 System calls A type of special protected procedure calls allowing user-level processes request services from the kernel. System calls provide: An abstraction layer between processes and hardware, allowing the kernel to provide access control, arbitration A virtualization of the underlying system A well-defined interface for system services 14

15 System calls vs. Library functions What are the similarities and differences between system calls and library functions (e.g., libc functions)? Similarity Both appear to be APIs that can be called by programs to obtain a given service E.g., open, E.g., strlen 15

16 System calls vs. Library functions System calls make explicit requests to the kernel, and can only be initiated by special software interrupt instructions Each system call has a corresponding standard C library wrapper routines, which hide the details of system call entry/exit. strlen() (<string.h>)? open() (<fcntl.h)? printf() (<stdio.h>)? sprintf() (<stdio.h>)? all in user space sys_open() write() sys_write() all in user space 16

17 Invoking system calls user-mode (restricted privileges) kernel-mode (unrestricted privileges) app making system call call xyz() ret sys_xyz() { } call ret system call service routine wrapper routine in std C library xyz { int 80h; } int 0x80 iret system_call: sys_xyz(); system call handler 17

18 Invoking system calls: more details In user program call the library function that includes a system call In library function Preparation work Save the syscall number in %eax (x86) Call int 80h (Linux) Hardware: locate the system call trap handler using the interrupt ID 80h In trap handler: Save user process context Look up the intended system call in the system call table In system call: Perform the requested service Return to user mode by iret instruction, which restores the user process context 18

19 Next: Syscall Wrapper Macros { } printf( hello world!\n ); User mode printf ( ) { %eax = sys_write #; int 0x80 libc kernel mode 0x80 IDT system_call() { fn = syscalls[%eax] } syscalls table sys_write( ) { // do real work } 19

20 Designing the syscall interface Important to keep interface small, stable (for binary and backward compatibility) Early UNIXes had about 60 system calls, Linux 2.6 has about 300; Solaris more, Window more still Aside: Windows does not publicly document syscalls and only documents library wrapper routines (unlike UNIX/Linux) Syscall numbers cannot be reused (!) Why? Deprecated syscalls are implemented by a special not implemented syscall (sys_ni) 20

21 The system-call jump-table (system call table) There are approximately 300 system-calls in Linux 2.6. Any specific system-call is selected by its ID-number (i.e., the system call number, which is placed into register %eax) An array of function-pointers is directly accessed (using the ID-number) This array is named sys_call_table[] in Linux 21

22 The system-call jump-table assembly language (.data) 0 common read sys_read 1 common write sys_write 2 common open sys_open 3 common close sys_close 4 common stat sys_newstat 5 common fstat sys_newfstat 6 common lstat sys_newlstat // etc (arch/x86/entry/syscalls/syscall_64.tbl) 22

23 The jump-table idea sys_call_table sys_restart_syscall sys_exit sys_fork sys_read sys_write sys_open sys_close etc.section.text 8 23

24 Discussion Instead of using the approach of system table, can we use if-else tests or switch statement to transfer to the service routine s entry point? Functionality wise, yes. But it would be extremely inefficient. System call invocations are synchronous, long system call execution cause performance degradation for the calling program. 24

25 Syscall Naming Convention Usually a library function foo() will do some work and then call a system call ( sys_foo() ) In Linux, all system calls begin with sys_ Often sys_foo() just does some simple error checking and then calls a worker function named do_foo() 25

26 Syscall return values Recall that library calls return -1 on error, and place a specific error code in the global variable errno System calls return specific negative values to indicate an error On x86, the return value is put into %eax, so that the library wrapper function can access. The library wrapper functioin is responsible for conforming the return values to the errno convention 26

27 System call argument passing Three general methods used to pass arguments to the OS: Method 1: pass the arguments in registers (simplest) Any drawbacks? Method 2: arguments are placed, or pushed, onto the stack by the program and popped off the stack by the OS kernel code (i.e., the syscall implementation) Method 3: arguments are stored in a block, or table, in memory, and address of block passed as a parameter in a register This approach taken by Linux and Solaris Which method does xv6 use? 27

28 Discussion To a programmer, a system call looks like any other call to a library functions. Is it important that a programmer knows which library procedures result in system calls? Under what circumstances and why? As far as program logic is concerned, it does not matter whether a call to a library procedure results in a system call. But if performance is an issue, if a task can be accomplished without a system call the program will run faster. Every system call involves overhead time in switching from the user context to the kernel context. Furthermore, on a multiuser system the operating system may schedule another process to run when a system call completes, further slowing the progress in real time of a calling process. Library calls are much faster than system calls. If you can do it in user space, you should. 28

29 Discussion Consider a hypothetical system call, zerofill, which fills a user buffer with zeroes: zerofill(char* buffer, int buffersize); The following kernel implementation of zerofill contains a security vulnerability. What is the vulnerability, and how would you fix it? void sys_zerofill(char* buffer, int buffersize) { for (int i=0; i < buffersize; i++) { buffer[i] = 0; } } 29

30 Discussion The user buffer pointer is untrusted, and could point anywhere. In particular, it could point inside the kernel address space. This could lead to a system crash or security breakdown. Fix: verify the pointer is a valid user address 30

31 Discussion Is it a security risk to execute the zerofill function in user-mode? void zerofill(char* buffer, int buffersize) { for (int i=0; i < buffersize; i++) { buffer[i] = 0; } } 31

32 Discussion No. User-mode code does not have permission to access the kernel s address space. If it tries, the hardware raises an exception, which is safely handled by the OS More generally, no user mode code should ever be a security vulnerability. Unless the OS has a bug 32

33 Assignment Read the xv6 code/books about system call implementation In the Assignment1, you will be implementing your own system calls. It s already late if you have not started! 33

34 Midterm1 2/26, in class Coverage: Processes, IPC, and system calls. 34