MINIX 3 Process Analysis

Transcription

1 Xander Damen Albert Gerritsen Eelis van der Weegen

2 Introduction Our project: process analysis of MINIX 3. Outline: 1 methodology 2 subsystem & tool selection 3 the MINIX 3 scheduler 4 the model 5 properties & results 6 conclusions & reflection

3 Methodology Basic methodology: 1 study MINIX; identify subsystems 2 identify appropriate tools 3 select subsystem and tool 4 perform the analysis construct the model (intelligently) formulate & verify properties 5 report (you are here)

4 Subsystem selection Modeling the whole thing is infeasible. Best we can do: analyze important subsystem. Criteria: interesting parallellism clearly definable correctness properties managable size relatively independent

5 Subsystem selection (2) Candidates: message infrastructure scheduling process table synchronization system initialization We chose the scheduler.

6 Tool selection Tool selection: we chose Spin. mature well documented efficient in-house expertise specification language close to implementation language

7 Spin in a nutshell Spin in a nutshell: model system in Promela specify assertions and properties compile with Spin run resulting executable

8 The MINIX 3 scheduler Scheduler: processes are prioritized (16 levels) MultiLevel Feedback Queue Scheduler round-robin within queues priority degraded when full quantum consumed priorities periodically reset located in kernel/proc.c ( 1 KLOC) Runs on: hardware interrupts (clock, disk,...) certain system calls (e.g. fork, IPC)

9 The MINIX 3 scheduler (2)

10 The MINIX 3 scheduler (3)

11 The model Model construction: 1 start small (i.e. specific routine & property) 2 add dependencies but abstract away details 3 repeat for additional properties

12 The Model (2) Scheduler code itself copied almost verbatim from MINIX 3. Main difficulty: simulated processes & context switches: every MINIX 3 task has a Spin process invariant: all processes blocked on proc_ptr

13 Context switches proctype sender ( ) { do : : n o t i f y (USER0, USER1 ) ; od } proctype user_proc ( ) { do : : skip ; / / work hard! context_switch ( ) ; / / yield the " cpu " od } i n l i n e context_switch ( ) { maybe_simulate_hardware_interrupt ( ) ; atomic { i f : : next_ptr!= NO_PROC > proc_ptr = next_ptr ; n e x t _ p t r = NO_PROC; : : else > skip f i ; } } proc_ptr == PID ;

14 Properties & Results We verified 4 properties: 1 absence of deadlock 2 integrity of scheduling queues: CHECK_RUNQUEUES proc.(proc.priority proc.maxpriority) 3 regular balancing of the queues: clock_task@balance_queues 4 liveness: proc.( proc.pid = proc_ptr) Alas, we did not find any bugs. :-(

15 Statistics Verification (numbers shown for liveness): unique states: 1.4e+07 state size: 424 bytes memory usage: 3850 MiB search depth: states run-time: 5:40

16 Conclusions & Reflections Conclusion: It worked ; we were able to verify a few properties in a tiny fragment of MINIX 3. Reflection: Spin proved to be a useful tool. Most of the scheduling parts very close to MINIX 3 C code. Lower-level parts caused the most headache. Spin s support for LTL formulas is limited.

17