1. MULTIVIE W Checking System Rules Using System-Specific, Program-Written Compiler Extensions Paper: Dawson Engler, Benjamin Chelf, Andy Chou, and Seth Hallem Presentation: Emerson Murphy-Hill

2. MULTIVIE W You might remember me from such news articles as…

3. MULTIVIE W Program Validation is Hard Theorem Proving / Model Checking –Difficult and costly; an abstraction Testing –Limited coverage and you can’t test all execution paths Manual Inspection –Very expensive per-line, erratic results

4. MULTIVIE W An Alternative Approach to Program Validation Static Analysis –No need for a separate model; verified object is code –Can build into the compiler, which traverses source anyway Authors present “Metalevel Compilation” –Compiler extensions for checking domain- specific knowledge

5. MULTIVIE W Previous Work Other static checkers – find specific problems, we find general problems Validation – finds a few errors with a lot of work, we find many errors without much work Extensible Compilation – a bit different… Aspect Oriented Programming

6. MULTIVIE W An Example

7. MULTIVIE W The Kind of Bug Caught…

8. MULTIVIE W Essential Bits Relating to RCU We have properties we want to enforce –Read lock/unlocks should be paired –No blocking in a read side critical section –Don’t hold global references outside of critical sections –Don’t dereference a global variable directly in a read- side critical section – always use rcu_dereference() –Free memory after unlinked AND RCU synchronize –(Is that all?)

9. MULTIVIE W Current State of Enforcing Properties Paul McKinney checks uses of RCU by hand, but: –There are > 1000 RCU uses in Linux now –The checks are done informally –The rules aren’t formalized –So this quickly gets unmanageable… How do we automate this?

10. MULTIVIE W Generic vs. Domain Specific Rules Generic Compiler Rules –Type Checking –Syntax Checking –Modularity Enforcement Domain Specific Rules –Rules for locking, interrupts –Functional rules (Herlihy) Can we code domain specific rules into the compiler?

11. MULTIVIE W The Process Specify an MC-Extension Compile it with their “metal” extension Code linked into xg++ Run xg++ over desired source code

12. MULTIVIE W Increasing Efficiency Analysis can be flow sensitive or flow insensitive Code traversal is made more efficient by caching redundant paths (loops)

13. MULTIVIE W Limitations A Checker, not a Verifier (e.g., aliases) Problems in results may not actually be problems (they didn’t build the code themselves) Had to modify g++ front-end to allow for more relaxed type system in GNU C

14. MULTIVIE W Another Example

15. MULTIVIE W …Detects:

16. MULTIVIE W Another Example An Extension (not shown) checks for possibly false assertions, statically Importance: –Assertions are normally done dynamically –Failed assertions will crash system –Inspection wouldn’t find some of these errors Detected 5 system-crashing errors

17. MULTIVIE W More Examples One detects floating point use, in kernel (this is a prob?) – exposed one bug Another checks for stack overflow – found 10 large stack allocations. Led to patches

18. MULTIVIE W Checking copyin/copyout An extension looks for unchecked pointer uses Found 18 errors in Xok (w/15 false positives)

19. MULTIVIE W Memory Allocation Checks One 60-line extension checks that memory is: –Checked before Use –Not used after it has been freed –Not double freed –Always freed on error paths

20. MULTIVIE W … Catches:

21. MULTIVIE W Enforcing Rules Globally So far, we have seen local checks There are global rules, though For example, transitive blocking calls can be calculated, then used…

22. MULTIVIE W Deadlock Avoidance One Extension checks: –No blocking when interrupts are disabled –No blocking when holding spin lock 123 Violations in Linux

23. MULTIVIE W Module Mis-Usage Modules can be loaded/unloaded dynamically, so each module must keep track of it’s reference count to protect against being unloaded inappropriately Found 75 violations in Linux

24. MULTIVIE W Lock Checking Rules for Locking: –Locks acquired in f must be released in f –Locks can’t be locked or unlocked twice –Upon exit, enable or restore interrupts –“Bottom halves” of interrupt handlers not disabled on exit –Interrupts flags saved before restored

25. MULTIVIE W Lock Checking False Positives… –Intentional violation for modularity or efficiency – Checker does local analysis only (not transitive) –Checker not sophisticated enough to prune impossible paths

26. MULTIVIE W Optimization Applied rules to the FLASH machine’s cache coherence protocol, where optimizations can increase performance significantly

27. MULTIVIE W Summary

28. MULTIVIE W Conclusion Metalevel Compilation: –Finds serious errors in real code (about 500 in three kernels) –Finds errors in a systematic, system wide manner –Enables easy writing of checkers

29. MULTIVIE W Questions If we can validate properties automatically, can we weave them in automatically? How might you enforce properties between languages? (recall that MC extensions are written in an extension of the source language) Are there disadvantages to writing extensions in the source language (e.g., things you might want to express, but can’t easily?) What sorts of RCU rules do we want to encode with extensions, but can’t? How many code passes are needed? Can there be one pass per extension?

30. MULTIVIE W More Questions If read lock/unlock instructions must be paired, why not enforce this using a callback? The extensions themselves can be difficult to reason about, especially after a few lines. How can we make this easier? Can extensions be modularized? What typical compiler rules might better be pushed into the “extension” layer? What do you suppose the effort required to find these errors were, in terms of person-hours to implement checks and in terms of computation time to find errors?