copyright © 2015 miao yu, virgil d. gligor, and zongwei zhou cylab and ece department carnegie...

Copyright © 2015

Miao Yu, Virgil D. Gligor, and Zongwei Zhou

CyLab and ECE DepartmentCarnegie Mellon University

{miaoy1, virgil}@andrew.cmu.edu, [email protected]

ACM CCS Denver, ColoradoOctober 14, 2015

Trusted Display on Untrusted Commodity Platforms

1

mailto:%[email protected]





Copyright © 2015 2

Picture: GEEK.COM. http://www.geek.com/wp-content/uploads/2010/04/qubesOS_many-appvms.jpg

InsensitiveApplication

(App)

InsensitiveApplication

(App)

SensitiveApplication(SecApp)




SensitiveApplication(SecApp) Sensitive

Application(SecApp)

Security: no malicious scrapping/painting of SecApps output on Shared Displays

Secure Display Sharing

Copyright © 2015 3

Security

while maintaining:

Sec-App 1

OperatingSystem

(unmodified)

App

Graphics Processing Unit (GPU)

… Sec-App 2

App

AppSecAppSecApp

SecApp

SecApp

SecApp

SecApp

User Perception

Ideal Trusted Display

Compatibility

Trusted Computing Base

Assurance


Copyright © 2015

Security

while maintaining:

Compatibility

Assurance

User PerceptionApp

AppSecAppSecApp

SecApp

SecApp

SecApp

SecApp

Sec-App 1

OperatingSystem

(unmodified)

App


… Sec-App 2

Commodity OS

X

GPU Managed by:

Related Work

Full Virtualization Hypervisor

FullVirtualization Hypervisor

X

X

✓

✓ Graphics Processing Unit (GPU)

TCB

X

X

Trusted Computing Base (TCB)


Copyright © 2015 5

GPU

Instructions

Local Page Tables

CPUPrograms (e.g., drivers, Apps)

Data (e.g., frame buffers)

GPU Address Spaces

Objects

Global Page Table (GGTT)

Config. Registers

Commands

Background: GPU

Copyright © 2015 6

GPU

Config. Registers

Commands Instructions

Local Page Tables

Display Engine

Processing Engine

CPUPrograms (e.g., drivers, Apps)

Other Engines

GPU Address Spaces

Objects

Engines


Data (e.g., frame buffers)

Background: GPU

Copyright © 2015 7

Multiplexes GPU among VMs => Access mediation & emulation for GPU objects, e.g. GPU configuration registers

Reduces complexity => “address space ballooning”

* Derived from Figure 7 of Tian et al. “A Full GPU Virtualization Solution with Mediated Pass-Through”

Background: Full GPU Virtualization

VM 2VM 1

GPU Global Page Table (GGTT)

BalloonedBallooned

Copyright © 2015 8

VM 2VM 1

GPU Global Page Table (GGTT)

* Derived from Figure 7 of Tian et al. “A Full GPU Virtualization Solution with Mediated Pass-Through”

BalloonedBallooned

Multiplexes GPU among VMs => Access mediation & emulation for GPU objects, e.g. GPU configuration registers

Reduces complexity => “address space ballooning” => non-contiguous GPU address space

Background: Full GPU Virtualization

Copyright © 2015 9

GPU instructions could be malicious => base & bound registers

High

Base

Bound

VM2

VM1

Low Low

Base

Bound

High

GGTT GGTT

VM1

VM2

VM1

VM2

Inadequate GPU HW - single register pair for non-contiguous address spaces

Insecurity of Full GPU Virtualization

Copyright © 2015 10

Insecure: Inadequate GPU HW - malicious GPU instructions break GPU address space separation

Lacks assurance: unverifiable code base - multiplexing GPU among VMs is complex

• e.g., emulating accesses to all GPU configurationregisters

Full GPU Virtualization

In Summary

Trusted Computing Base

Incompatible with commodity OS/Apps - require OS/Apps redesign

TCB loses its assurance - code becomes large and complex


Step 1: Separate

Step 2: Mediate

Step 3: Emulate

GPU Separation Kernel (GSK)


Separate security-sensitive from insensitive GPU objects=> security model (informal)

GSK: Separation

App 1

OS(unmodified)

AppsApps

GPU

Copyright © 2015

Insensitive(vast majority)

13

GSK: Separation

Sensitive Object

Insensitive Object

App 1

OS(unmodified)

AppsApps

Separate security-sensitive from insensitive GPU objects=> security model (informal)

GSK Sensitive (very few)

GPU Addressed:

Large and complex (unverifiable) code base


ALL accesses to security-sensitive objects by ALL GPU instructions • inadequate GPU HW for mediation and complex instruction behavior

Interfaces fortrusted display

GSK: Mediation

GPU

App 1

OS(unmodified)

AppsApps

Access Mediation

SecApp 1

GSK


cannot be intercepted by GPU during execution

can access global memory via global page table (GGTT)

• can access all frame buffers

have complex behaviors when accessing sensitive objects

Assign GPU instructions to separate address spaces Prevent GPU instruction access to sensitive objects while maintaining compatibility.

Map GPU instruction behaviors to Read/Write & Config. Change accesses. Enforce access invariants.

Inadequate GPU HW & complex behaviors

Solutions Instructions

GSK: Mediation


GPU Address Space Separation

GPU Instructions


PhysicalMemory

Sensitive Object

Insensitive Object



GPU Instructions


PhysicalMemory

Sensitive Object

Insensitive Object



GPU Instructions


PhysicalMemory

Shadow GGTT (GGTT’)

Sensitive Object

Insensitive Object

Addressed: Inadequate GPU HW and access mapping


Preserves compatibility of access to shared objects• e.g., both OS/Apps and GSK access the frame buffer base register

GSK: Emulation

Interfaces fortrusted display

GPU

App 1AppsApps SecApp 1

GSK

Access Mediation

Emulation

OS(unmodified)

Addressed: Incompatibility with commodity platforms


Relies on existing primitives of formally verified μHV - access control to CPU physical memory

GSK: Design

GPU

App 1

OS(unmodified)

AppsApps

Access Mediation

SecApp 1

Emulation GSK

Addressed: Maintain assurance of underlying code

micro-Hypervisor


GSK: Design

OS/Appsframe buffer

SecApps’frame buffer

Screen

Addressed: Maintain Users’ Perception

Screen Overlay: displays SecApps over OS/Apps

Copyright © 2015

GPU Object All Objects

Mediation in

Full GPU Virtualization

GSK

Data (e.g., frame buffer, input/output for processing)

2 GB data “out-of-the-VM”

~6 MB

Configuration Registers 625 711 39

Page Table All

Commands 269 43 21

Instructions 66 14 (Ignored) 0

22

Only few GPU objects require mediation

Much smaller trusted code size• GSK + μHV << Full GPU Virtualization

~36K SLoC >10M SLoC

Evaluation: Size & Complexity


μHV-only

μHV + trusted display

Un-optimized μHV causes most overhead

Evaluation: Performance (Throughput)


Evaluation: Performance (Latency)

Native

μHV +trusted display

(ms)

(ms)

μHV only

(ms)

Un-optimized μHV causes most frame jitters

(frame)

(frame)

(frame)


Take-Away Points

Trusted display:• Secure• Compatible with commodity software/hardware• Preserve assurance of underlying trusted code• Maintain a typical user's perception

Approach: • Separate Mediate Emulate GPU accesses• Screen overlay


Backup


Security Protection

SensitiveApp (SecApp)

OperatingSystem (OS)

App

KeyboardGraphic

Controller

…

Network (w/ crypto)

Server

!

Sec-App


Discussion

SecApps require GPU acceleration• Need to extend the scope of sensitive GPU objects• Still simpler than full GPU virtualization

GPU hardware enhancement• Separate sensitive and insensitive GPU registers and

memory into different aligned pages• Support R/W access control in all GPU page tables


OS/Appframe buffer1

Screen

SecAppframe buffer2

Challenge: Ideal Trusted Display

when Screen & GPU are Shared at Any Time (not exclusively)

SecAppframe buffer3

…

Screen Sharing


Evaluation: Performance (Latency)

Native

μHV +trusted display

(ms)

(ms)

μHV only

maxacceptable latency

(ms)

Un-optimized μHV further degrades user experience

(frame)

(frame)

(frame)

copyright © 2015 miao yu, virgil d. gligor, and zongwei zhou cylab and ece department carnegie...

Documents

secapps display integrity

secapps display secrecy

gpu memory

gpu virtualization approaches

security kernels

different security components

gpu hardware lacks support

commodity osapps code