seL4: Formal Verification of an OS Kernel . - - PowerPoint PPT Presentation

sel4 formal verification of an os kernel
SMART_READER_LITE
LIVE PREVIEW

seL4: Formal Verification of an OS Kernel . - - PowerPoint PPT Presentation

seL4: Formal Verification of an OS Kernel . seL4: Formal Verification of an OS Kernel . Marek.Sapota@students.mimuw.edu.pl December 15, 2010 . . . . . . seL4: Formal Verification of an OS Kernel About seL4 What is seL4? Secure


slide-1
SLIDE 1

. . . . . .

seL4: Formal Verification of an OS Kernel

. .

seL4: Formal Verification of an OS Kernel

Marek.Sapota@students.mimuw.edu.pl December 15, 2010

slide-2
SLIDE 2

. . . . . .

seL4: Formal Verification of an OS Kernel About seL4

What is seL4?

Secure Embedded L4 Formally verified kernel from the L4 family Runs on ARMv6 and x86 architectures (there is no proof for x86) “Complete, general-purpose operating-system kernel” 8‘700 lines of C and 600 lines of assembler Microkernel that provides address spaces, threads, IPC and authorisation capabilities

slide-3
SLIDE 3

. . . . . .

seL4: Formal Verification of an OS Kernel About seL4

What is proved?

Behaviour precisely specified at abstract level Implementation is proved to follow abstract level specification and do nothing more Proof of termination and execution safety

slide-4
SLIDE 4

. . . . . .

seL4: Formal Verification of an OS Kernel About seL4

What is not proved?

Abstract specification making any sense Device drivers (not being part of the kernel) Memory allocation Several low level parts implemented in assembler Boot code Compiler correctness Hardware correctness eorem prover correctness

slide-5
SLIDE 5

. . . . . .

seL4: Formal Verification of an OS Kernel About seL4

What does it give us?

It’s impossible to make a buffer overflow aack No NULL pointer dereferencing No accidental uses of pointers to wrong type of data No memory leaks No arithmetic overflows and exceptions in kernel code (eg. no division by zero errors)

slide-6
SLIDE 6

. . . . . .

seL4: Formal Verification of an OS Kernel Proof overview

About proof

Proof is done using Isabelle/HOL theorem prover. ere are several proof assumptions: Valid compiler (GCC) Hardware correctness eorem prover is correct Proof was only done for ARMv6 architecture with one CPU.

slide-7
SLIDE 7

. . . . . .

seL4: Formal Verification of an OS Kernel Proof overview

About proof

e proof and implementation is split into three phases: Abstract specification — system interface Executable specification — Haskell prototype C implementation

slide-8
SLIDE 8

. . . . . .

seL4: Formal Verification of an OS Kernel Abstract specification

Abstract specification

Defines the system interface, describes what the system does, but not

  • how. Every implementation refining this specification will be binary

compatible with seL4. Properties: 4‘900 lines of Isabelle proof Enough detail to specify outer interface of the kernel No implementation details, data structures are high level (sets, lists, trees, etc.)

slide-9
SLIDE 9

. . . . . .

seL4: Formal Verification of an OS Kernel Executable specification

Haskell prototype

Executable specification fills in details le by abstract specification and describes how the system works. Prototype properties: 5‘700 lines of code, 13‘000 lines of Isabelle proof Runnable with modified QEMU Deterministic (only le non-determinism is hardware) Proved to implement abstract specification Automatically translated to Isabelle script

slide-10
SLIDE 10

. . . . . .

seL4: Formal Verification of an OS Kernel Executable specification

Haskell prototype

ere are some restrictions that make automatic translation to Isabelle possible: No substantial use of laziness Restricted use of type classes All functions are proved to terminate

slide-11
SLIDE 11

. . . . . .

seL4: Formal Verification of an OS Kernel C implementation

C implementation

C implementation is a manual reimplementation of Haskell code. Haskell runtime is much bigger than the kernel itself and would be hard to be proved correct Garbage collection is not suitable for real-time environments C allows low level optimisations Automatic translation would be easier to prove, but it wouldn’t allow any low level optimisations Properties: 8‘700 lines of code, 15‘000 lines of Isabelle proof

slide-12
SLIDE 12

. . . . . .

seL4: Formal Verification of an OS Kernel C implementation

Assembler parts

For some direct interaction with hardware assembler is used. For example cache and TLB flushes require direct instructions to

  • hardware. is low level parts of code are not proved correct, but

they are traditionally tested.

slide-13
SLIDE 13

. . . . . .

seL4: Formal Verification of an OS Kernel Verification effort

Lines of code

5‘700 lines of Haskell 8‘700 lines of C 600 lines of assembler Total of 200‘000 lines of Isabelle script (including generated proofs)

slide-14
SLIDE 14

. . . . . .

seL4: Formal Verification of an OS Kernel Verification effort

Time

Abstract specification - 4 person months Haskell prototype - 2 person years C implementation - 3 person months Total of 2.2 person years SLOCCount estimates cost of seL4 implementation at 4 person years, in comparison it took 6 person years to implement Pistachio kernel Cost of proof - 20 person years ( 9 person years for tools, frameworks and automation, 11 person years for seL4 specific proo) All together — design, documentation, implementation and verification — about 25 – 30 person years, to do this again it would be about 10 person years

slide-15
SLIDE 15

. . . . . .

seL4: Formal Verification of an OS Kernel Conclusions

Conclusions

Formal verification is achievable for microkernels Performance does not need to be sacrificed for verification Detour via Haskell improved productivity

slide-16
SLIDE 16

. . . . . .

seL4: Formal Verification of an OS Kernel Future

What next?

Verification of assembly parts Version of kernel for multi-CPU machines