JuluOSDev 2012-05-08

Original sync.in url : http://sync.in/rSEwspQuhs

COSCUP 2012 Workshop

40~50 people

-- fill hook function game

-- 4 topic with 4 speakers

- Ben --> network and network driver practice

- Dennis

- Hawx --> memory management

- Wayling

* Ben's Problem sol:

Comment qemu --monitor null... or upgrade qemu (try version 13 or 14 suggested by Jserv).


#comment gdb -batch line to save your time

#Ben: it will take long time about 13.5s in my working environment.

#gdb -batch -nx -x jos.in > /dev/null 2>&1

Diagram for lab3 Syscall flow





call trap # call trap(tf)

# reference env_run() Step 2 Hint

# env_pop_tf() done by iret and drop into user mode, so never run following code

# try to comment out following line, make grade ok.

# for reference xv6 code, we should refine code from env_pop_tf to here.

Question: When should we use ENV_NOT_RUUNNABLE at env_run() in env.c ?

* Hawx's Problem



Privilege changed






No Privilege changed




How cpu know p number of data from stack?

xv6 browsing

-- tvinit()

set_gate( idt[T_SYSCALL], 1, ....)

-- switchuvm()

-- syscall()

allow multiple re-entry, possible stack overflow.

Lec5 System call, Interrupt, and Exception Handling:


What it meas?

XXX Turns out our kernel had a subtle security bug in the way it handled traps... vb 0x1b:0x11, run movdsgs, step over breakpoints that aren't mov ax, ds, dump_cpu and single-step. dump_cpu after mov gs, then vb 0x1b:0x21 to break after sbrk returns, dump_cpu again.

Which One?

In Unix, traps often get translated into signals to the process. Some traps, though, are (partially) handled internally by the kernel -- which ones?

Error Code Push or not push by HW? (Pop, too)

INT is the software int.

Some traps push an extra error code onto the stack (typically containing the segment descriptor that caused a fault). But this error code isn't pushed by the INT instruction. Can the user confuse the kernel by invoking INT 0xc (or any other vector that usually pushes an error code)? Why not?

Stack is FULL?

What prevents lots of interrupts from coming in all at once and overflowing the kernel stack? Print the registers; IF=0x200, p idt[64].