Systems Calls
Protecting the System
• How can OS prevent user applications from harming the system?
– What if an application accesses disk drive directly?
– What if an application overrides interrupt handlers for keyboard?
– What if an application executes the HLT instruction?

Systems Calls
Protecting the System
• How can OS prevent user applications from harming the system?
– What if an application accesses disk drive directly?
– What if an application overrides interrupt handlers for keyboard?
– What if an application executes the HLT instruction?
: Os가 시스템을 보호하는 방법에 대한 이야기
시스템에 해를 끼칠 수 있는 application 특: critical한 part 접근하려고 함
-> 막아야 하니까 cpu에서 제공하는 dual mode operation함
Protecting the System
• CPU operates in “user mode” or “kernel mode”
– Allows OS to protect itself and other system components
Separate critical things from general things
– Mode bit (provided by hardware) allows to distinguish on which mode the
system is running (0이면 kernel mode, 1이면 user mode)
– All privileged instructions (critical part를 접근하는 명령들, 권한이 굉장히 높음)
are only executable in the kernel mode
E.g., HLT in x86
• Modern CPUs support more than two
modes (i.e., multi-mode operations)
– i.e. virtual machine manager (VMM)
mode for guest VMs
– VMs should be limited to its space for
memory access

user mode에서는 user process만 실행 될 수 있음 -> Kernel, HW part에 직접적인 접근 X, privileged instructions 실행 X
kernel mode에서는 OS만 실행, OS에 의해 privileged instructions 실행, HW에도 접근 O
* OS Virtualization : HW를 가상화 (하나의 physical computer에서 여러개의 가상 머신(logical computer)을 돌리기 위해)
권한 ) virtual machine manager > 각 가상 머신의 kernel > 각 프로세스
Privileged Instructions
• A set of instructions that should be executed carefully
– Direct I/O access
E.g., IN/OUT instructions in IA-32
– Accessing/manipulating system registers
Control registers
Interrupt service routine table
– Memory state management
Page table updates, page table pointers, TLB loads, etc
– HLT instruction in IA-32
• Executable in the kernel mode
– May generate an exception if an application tries to run a privileged
instruction in user mode
Interrupt vs. Exception
: 좀전에 interrupt에 대해 다뤘었다. 그때 HW가 interrupt를 발생시킨다고 했었는데 끝에 SW interrupt도 있다고 하였다.
이것이 바로 exception이다. SW interrupt보단 통상적으로 Exception이라고 말한다.
그러므로 interrupt는 그냥 HW interrupt라고 생각하자.
먼저 Exception에 대해 알아보자. 좀전에 "명령어 실행에 의해 발생하는 interrupt이다. 예를 들면 소프트웨어 오류(ex. 0으로 나누기), 인증되지 않은 데이터 접근, 시스템 서비스 요청 등이 있다." 라고 했었다.
그러므로 interrupt처럼 처리한다. 그리고 CPU가 명령어를 실행할 때 발생하므로 동기적이다.
또한 Exception은 Trap, fault 두 가지로 나눌 수 있다.
- Trap: 응용 프로그램이 의도적으로 발생시키는 것이다. 그러므로 정상적인 동작이고 이것을 바로 시스템 콜이라고 한다.
- Fault: 의도하지 않은 Exception이다. 때문에 비장상적인 동작이다. 주로 에러나 잘못된 접근이다.
최신 OS의 사용자 모드에서 커널 모드로의 전환은 interrupt나 exception을 통해 수행됨.
• Exception (= Software interrupt)
– Generated by executing instructions
Software error (e.g., division by zero), unauthorized access of data, request for
operating system service, …
– Synchronous
Happens when CPU executes an instruction
– Trap(expected, intended) or fault(unexpected)
– Handled like interrupts
• C.f., interrupt (= Hardware interrupt)
– Generated by hardware devices
– Occurs asynchronously (at any time)
• Modern OSes are interrupt(including exception)-driven
– The transition from user mode to kernel mode is done via interrupt or
Exception
Transition from User to Kernel Mode
• By interrupt
– Asynchronous
– E.g., Timer
In the kernel mode, OS set a timer to generate an interrupt after some time period
(privileged instruction)
In the user mode, an application process keeps using the CPU
The timer generates a timer interrupt when the timer expires
» Switched to the kernel mode
The OS can make a decision on the process
-> Timer(I/O device의 하나)를 이용해 시간이 만료되면 interrupt를 발생시켜 주로 cpu scheduling을 위해 사용된다. Interrupt를 통해 user mode에서 kernel mode로 전환.
-> User mode에서 kernel mode로 cpu가 전환되면, OS가 cpu에 다음 프로세스를 지정해줄 수 있다?
-> Program: Storage에만 있어 동작하지 않는 상태로 있음 <-> Process: memory에 올라와서 실행될 수 있음
Transition from User to Kernel Mode
• By system call
– Synchronous

System Calls
• Programming interface to the services provided by the OS
• Typically written in a high-level language (C/C++)
• Mostly accessed by programs via a high-level Application Programming
Interface (API) rather than direct system call use : 보통 API를 통해 system call을 호출
• Most common APIs
– Win32 API for Windows variants
– POSIX API for POSIX-based systems
Virtually include all versions of UNIX, Linux, and Mac OSX
– Java API for the Java virtual machine (JVM)
A View of Operating System Services
Types of System Calls


• Process control
– create process, terminate process
– end, abort
– load, execute
– get process attributes, set process attributes
– wait for time
– wait event, signal event
– allocate and free memory
– dump memory if error
– debugger for determining bugs, single step execution
– locks for managing access to shared data between processes
Types of System Calls
• File management
– create file, delete file
– open, close file
– read, write, reposition
– get and set file attributes
• Device management
– request device, release device
– read, write, reposition
– get device attributes, set device attributes
– logically attach or detach devices
Types of System Calls
• Information maintenance
– get time or date, set time or date
– get system data, set system data
– get and set process, file, or device attributes
• Communications
– create, delete communication connection
– send, receive messages (message passing model)
– create and gain access to memory regions (shared memory model)
– transfer status information
– attach and detach remote devices
Types of System Calls
• Protection
– Control access to resources
– Get and set permissions
– Allow and deny user access
Example of System Calls
• System call sequence to copy the contents of one to another file

Windows and UNIX System Calls

Standard C Library Example
직접 시스템 콜 사용 X, 보통 high-level의 API를 통해 접근함
• C program invoking printf() library call, which calls write() system call

Standard C library = System call Interface
System Call Implementation
• Typically, each system call is associated
with an unique number (system call
number)

– System-call interface maintains a table
indexed according to these numbers
- system call 구현에 대한 설명
: system call table이 존재하고, 이 테이블이 각 system call들의 루틴의 주소값을 가지고 있음
: 요구하는 시스템 콜의 위치를 반환받아 OS가 찾을 수 있음
• The system call interface invokes the
intended system call in OS kernel and
returns status of the system call and any
return values
• The caller need know nothing about how the system call is implemented
– Just needs to obey API and understand what OS will do for system call
– Most details of OS interface are hidden from programmer by API
: API가 디테일한 것을 다 커버쳐줘서, API 사용법만 알면 된다.
System Call Parameter Passing
• Often, more information (i.e., parameters) is required than simply the
identity of desired system call
– Exact type and amount of information vary according to OS and system call
• Three general methods used to pass parameters to the OS
(OS에 매개변수를 전달하는데 사용되는 세가지 일반적인 방법)
1) Simplest approach: pass the parameters in registers
: 레지스터로 parameter 값들을 넘겨주는 방법 (system call호출시, OS가 레지스터에 저장된 값을 꺼내 사용)
However, in some cases, there may be more parameters than registers
: 레지스터 개수는 한정적이므로, general하게 쓰기는 어려움
2) Parameters are stored in a block (or table) in memory, and the address of
the block is passed as a parameter in a register (메모리 공간 할당(블락)을 받고, 필요한 파라미터를 다 저장 후, 블락의 주소값을 register에 넘겨줌)
This approach is taken by Linux and Solaris
: 주로 linux에서 사용
3) Parameters are pushed onto the stack by the user program and popped
off the stack by the operating system
: 각 process마다의 stack area에 필요한 parameter들을 push해두면, system call 호출시 OS가 그 stack를 pop up해서 parameter 얻음.
※ Block and stack methods do not limit the number or length of parameters
being passed
Parameter Passing via Memory Block

'시스템프로그래밍' 카테고리의 다른 글
OS Structures & Linux Overview (0) | 2022.11.10 |
---|---|
OS Structures & Linux Overview (0) | 2022.11.07 |
Operating Systems: An Overview (0) | 2022.10.31 |
Linkers and Loaders (0) | 2022.10.27 |
Assemblers (4)_1 (0) | 2022.10.17 |