CS 111
Scribe Notes for 4/8/10 Lecture 4
by Yiqi Meng(403569704), Jiho Kim(503707253)
Hard Modularity
Motivation : do not trust other modules because they can be buggy or adversary (eg, breaking the system)
Two techniques to implement Hard Modularity
1. Client-Service
Example case: calculating the factorial of a number
Client:
send(fact_port, { ※!§ ; 6});
receive(fact_port, response);
If(response.opcode == ※ok§)
print (response.val);
else
print(※error %d§, response.errorcode);
Sever:
for(;;){
receive (fact_server,request);
if(request.opcode == ※!※){
n = request.val;
for(int I = 2, I < n, i++)
n *= I;
response == {※ok§,n}};
else
response == {※no§,29};
send (fact_sever,response);
}
Pro:
.No shared state:
A.if client loops -> server is still running fine
B.if sever loops -> client can recover
.limited error propagation
.caller and callee cannot mess with each other (except exchanging wrong information like answer)
Con:
.more resources (two virtual machine) especially time consuming
.extra operations -> performance problem
.harder to deploy
2. Virtualization
Key Idea: OS gives a ※pretend machine§ to the app.
An example of such machine is X86 emulator, which lets OS to run applications inside it.
Pro:
.no direct access to I/P devices or to anything else that cause trouble
.can even catch infinite loops in applications!
Con:
.Slower because more instructions are needed for single virtual instruction (traditionally slower by factor of 10)
In order to have better performance, virtual processor with a privileged bit was invented. A virtual processor is a representation of a physical processor core to the operating system of a logical partition that uses shared processors.
It divides x86 instruction set into two sets:
non-privileged instructions - which can be directly accessed by virtual machines
privileged instructions 每 which can only be accessed via the kernel of OS.
Two ways to call the kernel
A.Ordinary function call: fast, supported, but unsafe due to insufficient modularity. Popular in embedded applications.
B.Protected transfer of control: when an unsafe instruction is executed, hardware traps, and kernel takes control.
A hardware trap can possibly caused by:
a.Hardware device interrupt
b.Cpu timer
c.Invalid instructions
When hardware traps, the kernel
1.Turn on the priviledge bit
2.consults its interrupt vector for handling different traps.
Interrupt Vector (inside of kernel)
| | ---> X86 privileged codes
| |
| |
| |
3.The following things are push onto the kernel stack:
ss 每 stack segment
esp 每 stack pointer
eflags
cs 每 code segment
eip 每 instruction pointer (return address)
To return from the kernel, use RETI ins;
System calls:
System call allows access to kernel code. They are implemented by the use of interrupts that can be done in several ways.
for(;;)
continue;
This is one way to force a system call, but it is too slow.
*(char *)0 = 'x';
This immediately forces a system call, but such a command is a common mistake in apps and is too likely to be accidental.
The instruction "int 0x80" is what invokes the system call.
System call is like a function call except:
- Crosses protection domains
- Privileged spaces that user programs cannot normally access can be accessed and their code run through the system calls.
- Slower
- More information must be saved and restored when using system calls.
- Hard modularity
OS organization with virtualization:
Components of the machine that may need virtualization.
- Arithmatic Logic Unit (ALU): Full access is granted, but we must be careful about saving/restoring ALU overflow, carry flag, negative, and zero states.
- Registers: Most registers are not privileged.
- Primary Memory (RAM): This memory is accessible at full speed to the user. However, accessing the "forbidden zone" will cause the system to trap.
- Cache: Cache is not a protection issue.
- I/O (devices): Devices are typically always privileged. An exception is a graphical display output (on occasion).
Problems & Solutions
Bad memory is accessed - Memory protection handles this problem with various methods such as segmentation. Segmentation divides the memory so that processes are restricted to certain segments of memory. If the process tries to access memory outside that segment,
Application loops infinitely- The 10ms clock interruption transfers control over to the kernel. The kernel can then resume any app it wants.
Kernel loops infinitely- It is the end of the world and nothing can be done.
Kernel accesses bad memory - Apocalyptic situation #2, no way out.
2 application uses the same registers -
Context switch: When one process is suspended and another is resumed.
The kernel performs context switch using its process descriptor table. The process descriptor table holds information of the process' state. The kernel can therefore save and restore states of processes and use the same registers.
Devices:
Robustness is a real issue. We want a clean interface to devices for abstraction and modularity.
Classes of devices:
A) Network/mouse/keyboard/serial
B) Disk/storage
C) Display
Devices A and B can be accessed by the system call "read" while B can be accessed by system call "lseek."
|