Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g....

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

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

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

ARMv7 Page Tables

1st level page table (per process/guest)

2nd level page tables (a set per process)

Physical memory

Base

Section

Page

ARMv7 Page Tables



Physical memory

Base

Section

Page

4GB total1MB pages4096 descriptorsEach descriptor 4 bytes

ARMv7 Page Tables



Physical memory

Base

Section

Page


Mapped to 1 MB memory section

Unmapped

Mapped to L2 page

table

ARMv7 Page Tables



Physical memory

Base

Section

Page


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

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)

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

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

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

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

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

A Direct Paging API

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

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

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 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


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.


What’s wrong here?

Exercise

Write pseudocode for hypercalls L2map and L1map

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 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

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

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

Ideal state:– : SPM1 machine state– : Abstract hypervisor state– maps 4KB physical blocks to

page types– maps blocks to reference counters

Ideal States

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

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.


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.


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.


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


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

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

Writing page table descriptor again…

In ideal model:–

In real model:–

Accessing Page Table Data

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

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

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

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

Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g....

Documents

Transcript of Provably Secure Execution Platforms Lecture Five: Memory ... · Guest 1: –Application OS, e.g....