XS Boston 2008 Security

  • 398 views
Uploaded on

John McDermott: Progress in...Higher Security Xen

John McDermott: Progress in...Higher Security Xen

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
398
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
11
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Xenon Assurance Modifications to Xen Code John McDermott, Naval Research Lab
  • 2. Xenon high-assurance Prologue: Security Xen Strength of mechanism - any conceptual flaws? Assurance - any construction flaws?
  • 3. Xenon high-assurance Prologue: Security Xen Security is always defined with respect to a threat model. A threat model has threat threat actor capability initial access initial knowledge
  • 4. Xenon high-assurance The Xenon Project Xen Project Goals: What happens when you try to develop high assurance open source? Can you build a “separation kernel” that supports unmodified uninterpreted off-the-shelf soft ware, on commodity hardware (e.g. x86_64 with APIC)?
  • 5. Xenon high-assurance Xenon Xen A “separation hyper visor” Not a separation kernel Not a “secure” replacement for Xen A new security-oriented product for specialized use See the Apr. ’07 slides at www.xen.org/xensummit
  • 6. Xenon high-assurance The Xenon Prototype Xen Based on 3.1 Some features removed Only supports x86_64 Refactored code Evidence package
  • 7. Xenon high-assurance Simplicity Xen McCabe cyclomatic complexity Halstead effort (sanity check) Size (sanity check) Xen 3.1 has approx. 3810 C functions Approx. 200 will have to be re- factored x86_emulate.c ?
  • 8. Xenon high-assurance Simplicity: _evtchn_close Xen _evtchn_close - 3 _finish - 5 _chk_state - 3 _state_INTERDOMAIN - 17 _evtchn_close - 34 _state_VIRQ - 3 _state_PIRQ - 2 _get_port - 6 _try_again - 3 _init_state - 1
  • 9. Xenon high-assurance Xen Modularity (cohesion) PageAlloc Xen Xenon PageAlloc Map BootTime RunTime XenHeap DomHeap Scrub Config Trigger
  • 10. Xenon high-assurance Encapsulating Global Data Xen No global data allowed, e.g. v->vcpu_id Information hiding instead, e.g. loose: #define vcpu_id(v) strict: static inline int vcpu_id
  • 11. Xenon Strict encapsulation of vcpu: high-assurance Xen schedule.c get/set_vcpu_id larger but just as fast object size: 158744b vs. 157240b sort test: 0.121s vs. 0.122s search test: 0.836s vs. 0.854s
  • 12. Xenon high-assurance Xenon Construction Guidelines Xen comments PDL files readme files tool-based formatting complexity, modularity, abstraction limits logical completeness coding practices
  • 13. Xenon high-assurance Guidelines: Comments Xen minimal don’t comment anything that could be understood in a first reading of the source assume the reader has a modern, program-slicing based source code browser, e.g. CodeSurfer
  • 14. Xenon high-assurance Guidelines: PDL Xen each source or header file has a companion Pseudocode Design Language file, e.g. dom_event_channel_c.pdl explains the intent of each line of code does not explain coding, algorithms or data structures see McConnel’s Code Complete, 2nd ed.
  • 15. Xenon high-assurance Guidelines: readme file Xen each source, header, and assembler file has a companion “readme” file. everything not covered by the .pdl file todo’s, data structures (e.g. event channel buckets) and algorithms, coding techniques (e.g. container_of) workarounds, etc...
  • 16. Xenon high-assurance Guidelines: formatting Xen all files formatted by a tool public Xenon format is defined as GNU indent indent -kr -nut -i8 - l128 file.c everyone can re-format to their preferred style for local work
  • 17. Xenon high-assurance Guidelines: structural limits Xen complexity, modularity, and abstraction limits examples shown in earlier slides departures from these limits explained in the .readme file, i.e. the code is more complex, less modular on purpose
  • 18. Xenon high-assurance Guidelines: logical completeness Xen suppose code has conditions (x < y) and (v->task) what about (x >= y) and (v->task == NULL)? should be dealt with in the code, covered by an assertion, or explained in the .readme file
  • 19. Xenon high-assurance Guidelines: coding practices Xen how to avoid high-risk or low- assurance C coding techniques? could have used a safe subset of C, e.g. MISRA C, subsets can be “noisy” and irritating instead, adopt 18 high-assurance coding rules, mostly from Les Hatton
  • 20. Xenon high-assurance More Information Xen email: john.mcdermott@nrl.navy.mil (Xenon) http://www.grammatech.com (CodeSurfer) Steve McConnel, Code Complete, 2d ed. ISBN 0-7356-1967-0 (PDL) http://www.leshatton.org/ ISOC_subset1103.html (Coding Practices)