Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g....
Transcript of Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g....
![Page 1: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/1.jpg)
Provably Secure Execution Platforms-
Lecture Five:Memory Virtualisation
Mads DamKTH Royal Institute of Technology
Roberto Guanciale produced earlier version of this presentation
BISS spring school, Bertinoro 2018
![Page 2: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/2.jpg)
Memory Virtualisation
The v0 kernel allows to virtualise only simple applications– Bare metal code– Simple kernels like FreeRTOS
For real COTS (Commercial-off-the-shelf) OSs virtual memory is a mustThis lecture: How do we do that in a provably secure manner?Treatment based on the ARMv7-A architecture
![Page 3: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/3.jpg)
Scenario
Three isolated guestsGuest 1:– Application OS, e.g. Android– No direct network access
Guest 2:– Crypto service– Invoked by OS and network guests– Collaboratively scheduled– No outside communication
Guest 3:– Network stack– E.g. based on slim Linux kernel
Hypervisor
Hardware
![Page 4: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/4.jpg)
ARMv7 Page Tables
1st level page table (per process/guest)
2nd level page tables (a set per process)
Physical memory
Base
Section
Page
![Page 5: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/5.jpg)
ARMv7 Page Tables
1st level page table (per process/guest)
2nd level page tables (a set per process)
Physical memory
Base
Section
Page
4GB total1MB pages4096 descriptorsEach descriptor 4 bytes
![Page 6: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/6.jpg)
ARMv7 Page Tables
1st level page table (per process/guest)
2nd level page tables (a set per process)
Physical memory
Base
Section
Page
4GB total1MB pages4096 descriptorsEach descriptor 4 bytes
Mapped to 1 MB memory section
Unmapped
Mapped to L2 page
table
![Page 7: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/7.jpg)
ARMv7 Page Tables
1st level page table (per process/guest)
2nd level page tables (a set per process)
Physical memory
Base
Section
Page
4GB total1MB pages4096 descriptorsEach descriptor 4 bytes
Mapped to 1 MB memory section
Unmapped
Mapped to L2 page
table
L2: 4KB pages, 256 descriptors à 4/table, 4 KB virtual mapped to 4 KB physical, or unmapped
![Page 8: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/8.jpg)
Memory Virtualisation
Application OSs need to manage their own memory– Controlling memory layout– Access control– Memory attributes, e.g. cacheability, shareability– Memory types• DRAM, flash, etc.• Memory-mapped devices
Design choices, either:– Make memory management fully transparent• How could we do that with the current architecture?• Would we want to?
– Else accept some minimal OS revision (paravirtualisation)
![Page 9: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/9.jpg)
Option 1: Ignore
Just give the OS full access to the page tables
But then the OS guest can grant itself access to entire memory
No very safe
Mandatory security property:– Full mediation of the MMU settings
![Page 10: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/10.jpg)
Option 2: Static Allocation
Use only static page tables
OK for simple separation kernels
Unable to support realistic application OS like Linux– No process creation– No control over memory allocation
![Page 11: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/11.jpg)
Option 3: Shadow PagingAllocate page tables in hypervisor memoryEvery update mediatedGuest keeps ”shadow copies” in own memoryTo create new L1:– Limux prepares 16 KB data in own memory (the shadow)
and invokes the hypervisor– Hypervisor check the content and copies the data into the
real page tablesSimple policyMost hypervisors that don’t use HW extensions do this– Some efficiency concerns: memory -> memory copy– Hypervisor must allocate extra memory for page tables
See work of Wolfgang Paul’s group on this topic
![Page 12: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/12.jpg)
Option 4: Direct Paging
Keep page tables in guest memoryGuests can manipulate them when not in useHypervisor mediates access to the active page tablesGuest in charge of explicitly requesting:– Allocation– Deallocation– Update
![Page 13: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/13.jpg)
Option 4: Direct Paging
Physical memory partitioned into blocks of 4KB, typed as– L1 page table / L2 page table / Writable
Hypervisor prevents unsound requests:– No access outside guest memory– No writable access to a block L1/L2
Reference counter:– L2: Number of L1s using this L2– Writable: Number of writable virtual aliases
Why should we even be bothered with all this at this point?– We are manipulating the innermost secrets of the processor– Direct paging makes the construction of a good ideal model
much more subtle – cannot just rip memory in two
![Page 14: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/14.jpg)
A Direct Paging API
![Page 15: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/15.jpg)
Using the API
Example: Allocating a new L1
1. Guest allocates space for an L1 physical block
2. Guest writes contents into the block
3. Guest removes – using the API – all mappings that enable it to write into the block
– The reference counter is now 0
4. The guest can now invoke hypercall L1create, which
– Validates the entries
– Updates the reference counters of other PTs
– Changes type of the block from D to L1
5. The block can now be used by the guest as parameter of the switch hypercall to active the newly allocated L1
![Page 16: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/16.jpg)
Virtualising Page TablesHypervisor table:• Ordered consecutively• pt: Page type• gm: Guest writable?• rc: Reference count Page 1:
Page 2:
. . .
Page n:
. . .
So: Page number n is contains L2 page tables,the page sits in guest memory, and it has no L1 pointing to it
![Page 17: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/17.jpg)
Virtualising Page Tables
Page 1:Page 2:
. . .
L2 page table:• Adr: Address of page• AP: Access
permission• 1,W: Write and
read access in privileged mode
• 0,R: Read access, no write access in user mode
Requirements:• If guest has read
access then page must be in guestmemory
Page n:
. . .
![Page 18: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/18.jpg)
Virtualising Page Tables
Page 1:Page 2:
. . .
Page n:
. . .
Four L2 page tables of 1 KB each to a page
New entry grants writeaccess in user mode
Requirements:• Reference counter is
increased• Referenced page
must be typed D
![Page 19: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/19.jpg)
Virtualising Page Tables
Each L1 is 16KB so 4 pagesPage descriptors:• Section or page table?• Access permissions
Requirements: Section descriptors w. guest access: All pages in guest. Guest write access: All pages typed D. PT descriptor: Page typed L2.
![Page 20: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/20.jpg)
Virtualising Page Tables
![Page 21: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/21.jpg)
Virtualising Page Tables
What’s wrong here?
![Page 22: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/22.jpg)
Exercise
Write pseudocode for hypercalls L2map and L1map
![Page 23: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/23.jpg)
Using the MMU
Modify SPM1 to account for MMUs
Required modifications:
– Each memory access requires virtual address -> physical
address lookup
• (Not efficient: Translation Lookaside Buffers* are
caches for page table walks – not covered here)
– Accesses relative to master page table
• Add new system register MMU_master
• MMU_master contains the L1 base (physical) address
– Access permissions resolved in MMU
• min_a/max_a registers deprecated
*: Alkassar, Cohen, Kovalev, Paul: Verification of TLB Virtualization Implemented in C. VSTTE’12
![Page 24: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/24.jpg)
Page Table Walks
Resolving the physical address for virtual address in mode IIII , with access permission :
• Look up MMU_master• Use to compute the L1 base table offset and retrieve the
descriptor• Unmapped? Raise exception with appropriate arguments• Section? Retrieve section base address– Access allowed? Compute offset, perform access– Access not allowed? Raise exception
• PT? Lookup L2 descriptor, check permission, compute offset, perform access
Exercise: Fill in the dots
![Page 25: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/25.jpg)
Ideal Model
Abstract CPU with only user/switch behaviour– As before
Abstract states– User level states augmented with abstract hypervisor data
structures, ”the trusted world”Only one guest– The virtualised OS
Handlers atomic, non-preemptivePage tables stored explicitly in memory– Accessed using physical addresses– Careful, no longer correct by construction– Separate ”consistency” proof needed– This is new
![Page 26: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/26.jpg)
Ideal Model Consistency
• Complete mediation: – No access to page tables that does not invoke the paging
API• Integrity: – Guests cannot directly affect the trusted world: No direct
guest writes to hypervisor memory– There are plenty of indirect flows
• Confidentiality: – No indirect flows from hypervisor to guest– Only effects of hypervisor to create/free/map/unmap
pages– Not visible to guest
![Page 27: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/27.jpg)
Ideal state:– : SPM1 machine state– : Abstract hypervisor state– maps 4KB physical blocks to
page types– maps blocks to reference counters
Ideal States
![Page 28: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/28.jpg)
Instructions executed in non-privileged mode do not affect the abstract hypervisor state
: Abstract handler from unprivileged abstract states to unprivileged abstract states
Cutting out switch resolution and vector handling from lecture 4=> record privilege level in transition arrow
Ideal Transitions
![Page 29: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/29.jpg)
Invariant : – Expresses well-typedness of page tables and correctness of
the reference counters
Exercise: Try to flesh out (in English) what the invariant should say
We should get:
Theorem 1 (Invariance): If and then IIIIIIIII
Exercise: Sketch a proof of (some representative cases of ) theorem 1.
Ideal Model Consistency
![Page 30: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/30.jpg)
Complete mediation:– We show that guest transitions cannot affect MMU
behaviour– Define if, and only if, for all :
Theorem 1 (Complete Mediation): If and then .
That is, for well-typed page tables, a user mode transition does not affect the virtual memory map
Thus, all non-trivial page table updates must be mediated by the hypervisor.
Ideal Model Consistency
![Page 31: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/31.jpg)
Integrity – non-exfiltration:– Let be the content of registers and memory
locations readable only in privileged mode.
Theorem 2: If and then IIIIII
This is just a mild generalisation of complete mediation
Exercise: A different approach to theorems 1 and 2 might be to prove absence of information flow from low (= guest) to hypervisor. Would this work? Explain.
Ideal Model Consistency
![Page 32: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/32.jpg)
Confidentiality - noninfiltration:– NI-like property: The user observable effects of hypercalls
do not depend on information not accessible to the guest.
Theorem 3: Suppose , and thatIIII If and IIIIII then IIIII
This completes the description of the ideal model
Ideal Model Consistency
![Page 33: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/33.jpg)
As in lecture 4 we prove correctness/security of the ”real model” by establishing a bisimulation/unwinding relation between the ideal and real model.
Main challenges:– In real model, program resides in memory and is accessed
using virtual addresses, as these addresses are affected by MMU updates.
– This makes use of languages like C problematic– Also: In real model, resources are explicit in memory and
accessed using virtual addresses.– Hypervisor uses same memory map as guest. This saves
page table switching overhead– (Note: This makes our hypervisor susceptible to
Meltdown/Spectre type attacks – we ignore this for now)
Real Model
![Page 34: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/34.jpg)
Ideal model - writing a page table descriptor:–
Real model – same thing:– Updates performed at physical level, but access check at
virtual.– converts virtual addresses to
physical – need also the converse– Require the hypervisor memory map to be injective – then
it has an inverse• Linux and freeBSD does the same
– Invertibility to be enforced by hypervisor, and proved as part of the invariant
Accessing Page Table Data
![Page 35: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/35.jpg)
Writing page table descriptor again…
In ideal model:–
In real model:–
Accessing Page Table Data
![Page 36: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/36.jpg)
As before, establish a bisimulation correspondence between ideal and real model
Build refinement relation whenever:– Registers and guest memory contain same values– Memory map in matches MMU behaviour in– Guest observations as defined are identical
Lemma 4 (Unwinding).The diagrams on right bothcommute.
Proving Real Model Correctness
![Page 37: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/37.jpg)
As before, establish a bisimulation correspondence between ideal and real model
Build refinement relation whenever:– Registers and guest memory contain same values– Memory map in matches MMU behaviour in– Guest observations as defined are identical
Lemma 4 (Unwinding).The diagrams on right bothcommute.
Proving Real Model Correctness
![Page 38: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/38.jpg)
Lemma 4 is only a helper, of course
Say is consistent, if for some
Corollary 5 (Real Model Correctness). Let be consistentreal model states such that . Then:1. If then is consistent2. If then (complete mediation)3. If then (integrity)4. If and then
Proving Real Model Correctness
![Page 39: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/39.jpg)
The entire development has been formalised for ARMv7-A withcomplete proofs including 3 of 9 API handlers at binary level– Binary level – that’s another story
Able to boot Linux 2.6.34 and 3.10 on BeagleBone, Beagleboard, RPi2 (using four cores for separate guests)
Linux modifications (2.6.34):– Execution modes– Exception handlers– Page table management
About 1Klines modified
Practical Matters
![Page 40: Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g. Android –No direct network access Guest 2: –Crypto service –Invoked by OS and](https://reader036.fdocuments.in/reader036/viewer/2022081617/6085432dc2c7053e433a7b72/html5/thumbnails/40.jpg)
Our numbers: LMBench on Linux 2.6.34 on BeagleBoard-xM (ARM Cortex-A8). L4Linux and Xen numbers from publications, using other cores/boards/Linux kernel versions.
Performance