park ber Enforcing Verifiable Object Abstractions for Automated - - PowerPoint PPT Presentation

▶
park ber
SMART_READER_LITE
LIVE PREVIEW

park ber Enforcing Verifiable Object Abstractions for Automated - - PowerPoint PPT Presentation

Mar 22, 2024 271 likes •518 views

park ber Enforcing Verifiable Object Abstractions for Automated Compositional Security Analysis of a Hypervisor Amit Vasudevan (CyLab-CMU), Sagar Chaki (SEI-CMU), Petros Maniatis (Google Inc.), Limin Jia, Anupam Datta (ECE/CSD-CMU)

slide-1
SLIDE 1

Enforcing Verifiable Object Abstractions for Automated Compositional Security Analysis of a Hypervisor

Amit Vasudevan (CyLab-CMU), Sagar Chaki (SEI-CMU), Petros Maniatis (Google Inc.), Limin Jia, Anupam Datta (ECE/CSD-CMU)

ϋber park

http://uberspark.org

slide-2
SLIDE 2

Enforcing Verifiable Object Abstractions for Automated Compositional Security Analysis of a Hypervisor

/ 24

Vasudevan et. al.

ϋber

park

Problem

  • raise significant security concerns
  • Number of bugs goes up with code size
  • Number of bugs goes up with frequency of updates
  • Number of bugs goes up with logical complexity
  • Number of bugs goes up with control-flow complexity
  • Both complex VMMs and micro-hypervisors are prone to bugs
  • E.g., VMware [VMSA-2009-006,Cloudburst], Xen [CVE-2008-3687],

SecVisor [Franklin et. Al,2010]

  • Verified hypervisor is accompanied by proof of desirable

(security) properties

2

Extensible Hypervisors

  • Motivating. Ex.  Arch.  Impl.  Verif. Results  Perf.  Concl.
  • Introduction
slide-3
SLIDE 3

Enforcing Verifiable Object Abstractions for Automated Compositional Security Analysis of a Hypervisor

/ 24

Vasudevan et. al.

ϋber

park

Why aren’t we already doing this?

3

  • Cost of verification grows with
  • The size of the code-base
  • The number of separate components
  • The number of configurations
  • The rate of revisions
  • Benefit of verification shrinks with
  • Steep learning curve of developer-unwieldy programming
  • Lack of commodity hardware integration
  • Magnitude of the runtime overhead

Commodity Compatibility Performance Compositionality

  • Motivating. Ex.  Arch.  Impl.  Verif. Results  Perf.  Concl.
  • Introduction
slide-4
SLIDE 4

Enforcing Verifiable Object Abstractions for Automated Compositional Security Analysis of a Hypervisor

/ 24

Vasudevan et. al.

ϋber

park

Why do this now?

  • Formal C static analysis tools are very practical [Frama-C]
  • Certifiable compilation tools [Compcert] are practical for

moderate module sizes

  • It’s trendy! [seL4, IronClad, IronFleet, FSCQ, mCertiKOS]

4

  • Motivating. Ex.  Arch.  Impl.  Verif. Results  Perf.  Concl.
  • Introduction
slide-5
SLIDE 5

Enforcing Verifiable Object Abstractions for Automated Compositional Security Analysis of a Hypervisor

/ 24

Vasudevan et. al.

ϋber

park

An extensible hypervisor

5

Guest Hardware Hypervisor MMU Network VMX MSRs hyperdep sysclog aprvexec ropdet

C + Assembly

  • Intro.  Arch.  Impl.  Verif. Results  Perf.  Concl.
  • Motivating Example
slide-6
SLIDE 6

Enforcing Verifiable Object Abstractions for Automated Compositional Security Analysis of a Hypervisor

/ 24

Vasudevan et. al.

ϋber

park

Challenge-1: Code size vs. HW de-privileging

6

Guest Hardware Hypervisor MMU Network VMX MSRs hyperdep sysclog aprvexec ropdet Guest Hardware Hypervisor MMU Network VMX MSRs hyperdep sysclog aprvexec ropdet

Performance

  • Intro.  Arch.  Impl.  Verif. Results  Perf.  Concl.
  • Motivating Example
slide-7
SLIDE 7

Enforcing Verifiable Object Abstractions for Automated Compositional Security Analysis of a Hypervisor

/ 24

Vasudevan et. al.

ϋber

park

Challenge-2: Continuous Development

7

Guest Hardware Hypervisor MSRs sysclog hyperdep hyperdep hyperdep hyperdep aprvexec aprvexec ropdet ropdet ropdet MMU MMU MMU Network Network VMX VMX

  • Intro.  Arch.  Impl.  Verif. Results  Perf.  Concl.
  • Motivating Example
slide-8
SLIDE 8

Enforcing Verifiable Object Abstractions for Automated Compositional Security Analysis of a Hypervisor

/ 24

Vasudevan et. al.

ϋber

park

Challenge-3: Shared Resources

8

Guest Hardware Hypervisor MMU Network VMX MSRs hyperdep sysclog aprvexec ropdet

  • Intro.  Arch.  Impl.  Verif. Results  Perf.  Concl.
  • Motivating Example
slide-9
SLIDE 9

Enforcing Verifiable Object Abstractions for Automated Compositional Security Analysis of a Hypervisor

/ 24

Vasudevan et. al.

ϋber

park

Challenge-4: Different Configurations

9

Guest Hardware Hypervisor MMU Network VMX MSRs hyperdep sysclog aprvexec ropdet Guest Hardware Hypervisor MMU Network VMX MSRs hyperdep sysclog aprvexec ropdet Guest Hardware Hypervisor MMU Network VMX MSRs hyperdep sysclog aprvexec ropdet

  • Intro.  Arch.  Impl.  Verif. Results  Perf.  Concl.
  • Motivating Example
slide-10
SLIDE 10

Enforcing Verifiable Object Abstractions for Automated Compositional Security Analysis of a Hypervisor

/ 24

Vasudevan et. al.

ϋber

park

Challenge-5: Verification vs. Programming Paradigm

10

  • Programming Paradigm
  • C + Assembly is de-facto
  • C + Assembly can clobber stuff! [stack,

registers, MSRs etc.]

  • HW access and ops. with multi-core
  • State-of-the-art Verification Tools
  • Often impose use of “developer-unwieldy”

high-level languages with steep learning curve [Coq, Haskell, Dafny]

  • Largely lack support for Assembly
  • Mainly target sequential code
  • Largely lack support for HW integration

Guest Hardware Hypervisor MMU Network VMX MSRs hyperdep sysclog aprvexec ropdet

  • Intro.  Arch.  Impl.  Verif. Results  Perf.  Concl.
  • Motivating Example
slide-11
SLIDE 11

Enforcing Verifiable Object Abstractions for Automated Compositional Security Analysis of a Hypervisor

/ 24

Vasudevan et. al.

ϋber

park

from above

  • Goals
  • Compositionality
  • Commodity Compatibility
  • Performance
  • Verifiable Object

Abstraction (uberObject)

  • Security invariants
  • Commodity HW + Software

Verification

11

ϋber park ϋBlueprint Proofs

+

System Resources

[CPU (Privileged) Instructions, Memory, Device Interfaces]

ϋberObjects

[C + Assembly + ACSL]

SW-Verif HW HW + SW-Verif

  • Intro.  Motivating. Ex.  Impl.  Verif. Results  Perf.  Concl.
  • Architecture
slide-12
SLIDE 12

Enforcing Verifiable Object Abstractions for Automated Compositional Security Analysis of a Hypervisor

/ 24

Vasudevan et. al.

ϋber

park

The ϋberObject

12

Use Manifest + Behavior Specifications in C-like language

Contract

System Resources

[CPU (Privileged) Instructions, Memory, Device Interfaces]

Performance

  • Intro.  Motivating. Ex.  Impl.  Verif. Results  Perf.  Concl.
  • Architecture
slide-13
SLIDE 13

Enforcing Verifiable Object Abstractions for Automated Compositional Security Analysis of a Hypervisor

/ 24

Vasudevan et. al.

ϋber

park

ϋberObject: Sentinel

  • Sentinel
  • Establishes “call-ret”

semantics

  • Object to object control-

flow enforcer

  • ϋberObjects verified not to

write on other stack frames

  • Enables sound application
  • f sequential source code

verification to verify invariants over sequential ϋberobject invocations

13

call ret

Shadow Stacks

ret, ret-async call, call-async

ϋObject Contracts

  • Intro.  Motivating. Ex.  Impl.  Verif. Results  Perf.  Concl.
  • Architecture
slide-14
SLIDE 14

Enforcing Verifiable Object Abstractions for Automated Compositional Security Analysis of a Hypervisor

/ 24

Vasudevan et. al.

ϋber

park

ϋberBlueprint & Concurrency

Abstract hypervisor as a non- deterministic sequential program  prove invariant properties of individual ϋobjects and compose them

14

Phase1 Startup Phase2 Intercept Phase3 Exception Proofs

HW initiated concurrent execution Concurrent execution HW initiated sequential execution Sequential execution

  • Intro.  Motivating. Ex.  Impl.  Verif. Results  Perf.  Concl.
  • Architecture
slide-15
SLIDE 15

Enforcing Verifiable Object Abstractions for Automated Compositional Security Analysis of a Hypervisor

/ 24

Vasudevan et. al.

ϋber

park

ϋberObject: CASM Functions & HW Model

  • CASM Functions
  • C functions composed

solely of Assembly

  • (Any) Assembly

instruction as macro

  • HW model specifies

semantics

  • Custom Frama-C

verification plugins

  • Inline C99 semantics to

verify

  • Inline Assembly to

compile down

15

void gp_setup_vhmempgtbl(void){ u32 i, spatype, slabid=XMHF_SLAB_PRIME; u64 flags; ... ... for(i=0; I < (SZ_PDPT*SZ_PDT*SZ_PT); ++i){ spatype=_gp_getspatype(slabid, (u32)(i*SZB_4K)); flags=_gp_getptflags(slabid, (u32)(i*SZB_4K),spatype); vhpgtbl1t[i] = pae_make_pte((i*SZB_4K),flags); } ... casm_writecr3(vhsmpgtbl4t[0]); }

CASM Function

void casm_writecr3(u32 value){ ci_movl_mesp_eax(0x4); ci_movl_eax_cr3(); ci_ret(); }

CASM Instructions

  • Intro.  Motivating. Ex.  Impl.  Verif. Results  Perf.  Concl.
  • Architecture
slide-16
SLIDE 16

Enforcing Verifiable Object Abstractions for Automated Compositional Security Analysis of a Hypervisor

/ 24

Vasudevan et. al.

ϋber

park

ϋberObject: Coding and Behavior Specification

  • C99 + CASM (principled

Assembly)

  • ANSI C Specification

Language (ACSL)

  • requires/assigns/ensures
  • Hoare triple proven

automatically via Frama-C

  • deductive verification

plugins

  • ensemble of SMT solvers

16 //@ghost u64 gflags[SZ_PDPT*SZ_PDT*SZ_PT]; /*@ ... requires \valid(vhpgtbl1t[0..(SZ_PDPT*SZ_PDT*SZ_PT)-1]); ... assigns vhpgtbl1t[0..(SZ_PDPT*SZ_PDT*SZ_PT)-1]; ... ensures (\forall u32 x; 0 <= x < SZ_PDPT*SZ_PDT*SZ_PT ==> ((u64)vhpgtbl1t[x] == (((u64)(x*SZB_4K) & 0x7FFFFFFFFFFFF000ULL) | (u64)(gflags[x])))); @*/ void gp_setup_vhmempgtbl(void){ u32 i, spatype, slabid=XMHF_SLAB_PRIME; u64 flags; ... /*@ loop invariant 0 <= i <= (SZ_PDPT*SZ_PDT*SZ_PT); ... @*/ for(i=0; I < (SZ_PDPT*SZ_PDT*SZ_PT); ++i){ spatype=_gp_getspatype(slabid, (u32)(i*SZB_4K)); flags=_gp_getptflags(slabid, (u32)(i*SZB_4K),spatype); //@ghost gflags[i] = flags; vhpgtbl1t[i] = pae_make_pte((i*SZB_4K),flags); /*@assert vhpgtbl1t[i] == (((u64)(i*SZB_4K) & 0x7FFFFFFFFFFFF000ULL) | (u64)(gflags[i])))); @*/ } ... casm_writecr3(vhsmpgtbl4t[0]); }

CASM function

  • Intro.  Motivating. Ex.  Impl.  Verif. Results  Perf.  Concl.
  • Architecture
slide-17
SLIDE 17

Enforcing Verifiable Object Abstractions for Automated Compositional Security Analysis of a Hypervisor

/ 24

Vasudevan et. al.

ϋber

park

ϋberObject: Resource Interface Confinement

  • ϋberAPI ϋberobjects
  • Wrap a reference monitor around (shared) resource
  • MMU, IOMMU, CRs, MSRs, Devices
  • Client object manifests how it will use a (shared) resource
  • Verified on client via assertions
  • During integration
  • Use manifests combined into one formula
  • SMT solvers check composability

17

  • Intro.  Motivating. Ex.  Impl.  Verif. Results  Perf.  Concl.
  • Architecture
slide-18
SLIDE 18

Enforcing Verifiable Object Abstractions for Automated Compositional Security Analysis of a Hypervisor

/ 24

Vasudevan et. al.

ϋber

park

  • C99 + CASM + ACSL behavior specifications and behavior

restrictions

  • Object invariants including basic memory safety and control-

flow integrity and other properties that can be formulated as invariants

  • Architecture ensures invariant composition
  • Mind-Blow #1: Only need to worry about object behavior now –

not implementation

  • Mind-Blow #2: A compositionally verifiable C + Assembly

system without hardware de-privileging

ϋberObject: Summary

18

  • Intro.  Motivating. Ex.  Impl.  Verif. Results  Perf.  Concl.
  • Architecture
slide-19
SLIDE 19

Enforcing Verifiable Object Abstractions for Automated Compositional Security Analysis of a Hypervisor

/ 24

Vasudevan et. al.

ϋber

park

An ϋber Micro-Hypervisor (ϋXMHF)

  • XMHF micro-hypervisor (http://xmhf.org)
  • Core hypervisor + single extension (hypapp)
  • Ubuntu 12.04 32-bit SMP on Intel VT-x/AMD
  • Various hypapps
  • tracing, attestation, app-level integrity, trusted path etc.
  • ϋXMHF
  • Multiple extensions
  • Ubuntu 12.04 32-bit SMP on Intel VT-x
  • 11 ϋberobjects, 7001 SLoC including prime and sentinel
  • Took ~3 person months for refactoring

19

  • Intro.  Motiv. Ex.  Arch.
  • Verif. Results  Perf.  Concl.
  • Implementation
slide-20
SLIDE 20

Enforcing Verifiable Object Abstractions for Automated Compositional Security Analysis of a Hypervisor

/ 24

Vasudevan et. al.

ϋber

park

ϋXMHF Verification Results

  • Verification Tools TCB
  • Frama-C, uberSpark Plugins (1021 SLoC), SMT Solvers (Z3, CVC3,

Alt-ergo), HW Model (2079 SLoC)

  • Security Invariants in core Hypervisor and Extensions
  • memory-safety, control-flow integrity, no direct writes to

hypervisor memory by guest, DEP, guest syscalls n/w logging etc.

  • Verification Metrics
  • 11 ϋberobjects, 5544 SLoC total ACSL annotations
  • Annotation to code ratio 0.2:1 to 1.6:1
  • ϋberobject verification times from 48s to 23 min; cumulative ~1hr
  • Took ~9 person months

20

  • Intro.  Motiv. Ex.  Arch.  Impl.  Perf.  Concl.
  • Verification Results
slide-21
SLIDE 21

Enforcing Verifiable Object Abstractions for Automated Compositional Security Analysis of a Hypervisor

/ 24

Vasudevan et. al.

ϋber

park

ϋXMHF: Micro & Application Benchmarks

  • Sentinel transfer cost
  • ϋXMHF vs. vanilla XMHF
  • Verified hypapps (2% avg. overhead)
  • Unverified hypapps (10% avg. overhead)
  • I/O and normal Guest performance unaffected!

21

Verified- Verified Verified-Unverified / Uverified-Verified SEG CR3 TSK HVM

2x 37x 48x 70x 278x

  • Intro.  Motivating Ex.  Arch.  Impl.  Verif. Results  Concl.
  • Performance
slide-22
SLIDE 22

Enforcing Verifiable Object Abstractions for Automated Compositional Security Analysis of a Hypervisor

/ 24

Vasudevan et. al.

ϋber

park

  • Can prove behavior one object at a time (trace properties)
  • Can compose modules and behaviors cheaply
  • Can write system code in “basically” C and Assembly and

behavior specifications in C-like specification language

  • Can integrate HW accesses and states into verification
  • Can execute with good runtime performance

So, what do we have here?

22

Goals  Compositionality  Commodity Compatibility  Performance

  • Intro.  Motivating Ex.  Arch.  Impl.  Verification Results  Perf. Conclusion
slide-23
SLIDE 23

Enforcing Verifiable Object Abstractions for Automated Compositional Security Analysis of a Hypervisor

/ 24

Vasudevan et. al.

ϋber

park

So, what don’t we have, yet?

  • Not “exactly” C99 + Assembly; no cowboy control flow craziness
  • God forbid no C++
  • Compcert + CASM proofs
  • Semantic compatibility between Frama-C, Compcert and CASM
  • HW Model to Assembly instructions refinement
  • Full functional correctness
  • Concurrent verification
  • Broader applicability
  • Other hypervisors (Xen, KVM), BIOS, Device firmware, OS Kernel and

Drivers, User-space Applications and Browser Extensions

23

  • Intro.  Motivating Ex.  Arch.  Impl.  Verification Results  Perf. Conclusion
slide-24
SLIDE 24

Enforcing Verifiable Object Abstractions for Automated Compositional Security Analysis of a Hypervisor

/ 24

Vasudevan et. al.

ϋber

park

Questions?

24

http://uberspark.org

Amit Vasudevan (amitvasudevan@acm.org)

ϋber park

  • Intro.  Motivating Ex.  Arch.  Impl.  Verification Results  Perf. Conclusion