Untrusted Cloud Andrew Baumann Marcus Peinado and Galen Hunt OSDI 2014 Fall 2014 Presenter Kun Sun PhD Most slides are borrowed from httpswwwusenixorgsitesdefaultfilesconferenceprotectedfilesosdi14slidesbaumannpdf ID: 400667
Download Presentation The PPT/PDF document "Shielding Applications from an" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Shielding Applications from an Untrusted CloudAndrew Baumann, Marcus Peinado, and Galen Hunt. OSDI 2014.
Fall 2014
Presenter: Kun Sun, Ph.D.
Most slides are borrowed from
https://www.usenix.org/sites/default/files/conference/protected-files/osdi14_slides_baumann.pdfSlide2
OutlineProblem: can we trust the Cloud?Existing solutionsNew hardware solution Intel SGX
Future workSlide3
In the old days…Slide4Slide5Slide6
The Goal of HavenSecure, private execution of unmodified
applications (
bugs and all
)
in
an
untrusted
cloud on
commodity hardware (Intel SGX)Slide7
Can we trust the Cloud?Huge trusted computing base Privileged softwareHypervisor
, firmware, ...
Management
stack
Staff (physical access)
Sysadmins
, cleaners,
security
Law enforcement (e.g.,
S
nowdon) Security soncerns limits cloud adoptionHierarchical security model
Observe or modify any data
Even if encrypted on disk / netSlide8
Current ApproachesHardware Security ModulesTrusted Hypervisor
Remote AttestationSlide9
Hardware Security ModulesDedicated crypto hardwareTamper-proofExpensive
Limited
set of APIs
Key
storage
Crypto operations
Unprotected transient data
Protects
the “crown jewels”, not general-purposeSlide10
Trusted HypervisorUse a small, secure, hypervisorEnsures
basic security, such as strong
isolation
Problem #1: system
administrators
Problem #2: physical attacks (e.g. memory snooping)
Problem #3: tampering with
hypervisorSlide11
Remote AttestationTrusted hardware: TPM chipSpecific software has been
loaded
Basic
idea:
Signed
measurement (hash) of privileged software
Remote
user checks measurement
Incorrect
attestation → compromised
softwareProblem: what is the expected measurement?Cloud provider applies patches and updatesMust trust provider for current hash valueSlide12
What do we really want?Slide13
Shielded ExecutionProtection of specific program from rest of systemcf. protection, process isolation
,
sandboxing
, etc.
New
term (older concept
)
Program
unmodified, naïve to
threats
Confidentiality and integrity of:The programIts intermediate state, control flow, etc.
→ Input and output may be
encryptedHost may deny service, cannot alter behaviorSlide14
Threat ModelWe assume a malicious cloud providerConvenient proxy for real threatsAll
the provider’s software is malicious
Hypervisor
, firmware, management stack, etc.
All
hardware
except
the CPU is
untrusted
DMA
attacks, DRAM snooping, cold bootWe do not prevent:Denial-of-service (don’t pay to cloud!)Side-channel attacksSlide15
Intel SGXSoftware Guard Extension (SGX)Hardware isolation for an
enclave
New
instructions to establish, protect
Call
gate to enter
Remote
attestation
Processor manufacturer is the root of the trust
Slide16
SGX at Hardware LevelSlide17
SGX at Hardware LevelSlide18
SGX vs. HavenSGX was designed to enable new trustworthy applications to protect specific secrets by placing portions of their code and data inside
enclaves
Self-contained code sequence
V2.0 supports dynamic memory allocation
Haven aims
to shield entire unmodified legacy applications
written without
any knowledge of
SGX
Challenge 1
: execute legacy binary codeChallenge 2: interaction with untrusted OS and hardware Iago attackSlide19
Unmodified BinarySGX only supports a subset of application logicChallenging properties in Enclaveload code and data at runtime
dynamically
allocate and change protection
on
virtual memory
execute
arbitrary user-mode instructions
raise
and
handleSolution:emulating unsupported instructions,carefully validating and handling exceptionSlide20
Iago AttackSlide21
Iago Attacks A malicious OS attempts to subvert an isolated application that assumes correct
OS
behavior
malloc
() returns pointer to user’s
stack
Scheduler
allows two threads to race in a
mutex
System
has 379,283 cores and -42MB of RAMread() fails with EROFS…Our approach:Reduce the interface (attack surface) by including a simplified OS into trusted computing
baseCarefully checking the remaining interface with the
untrusted host, e.g., validation of untrusted inputSlide22
HavenSlide23
Shield ModuleMemory allocator, region manager
64GB virtual address space
Host
commits/protects specific pages
No
address allocation
Private
file system
Encrypted
, integrity-protected VHD
SchedulerDon’t trust host to schedule threadsException handlerEmulation of some instructions
Sanity-check of untrusted
inputsAnything wrong → panic! 23 KLoC (half in file system)Slide24
Untrusted InterfaceHost/guest mutual distrustPolicy
/mechanism with a twist
Virtual
resource policy in
guest
Virtual
address allocation, threads
Physical
resource policy in host
Physical pages,
VCPUs ~20 calls, restricted semanticsSlide25
Untrusted RuntimePrimarily bootstrap and glue code,It is not trusted
by
either
enclave
or
host kernel.
Main tasks
are
creating the enclave,
loading the shield, and forwarding calls between the enclave and host OS. Open question: Any potential attacks?Slide26
SGX LimitationsDynamic memory allocation and protectionNew instructions
needed
Exception
handling
SGX
doesn’t report page faults or
GPFs
to the
enclave
Permitted
instructionsRDTSC/RDTSCP needed, for practicality and performanceThread-local storageCan’t
reliably switch FS and GSSlide27
SGX LimitationsDynamic memory allocation and protectionNew instructions
needed
Exception
handling
SGX
doesn’t report page faults or
GPFs
to the
enclave
Permitted
instructionsRDTSC/RDTSCP needed, for practicality and performanceThread-local storageCan’t
reliably switch FS and GSSlide28
Performance EvaluationImplemented and tested using SGX emulatorThanks
, Intel!
Problem
: no SGX implementation yet
Solution
:
measure Haven’s
sensitivity to key SGX performance parameters
TLB
flush on Enclave
crossingsVariable spin-delay for critical SGX instructionsEnclave crossingsDynamic
memory allocation, protection
Penalty for access to encrypted memorySlow overall system DRAM clockSlide29
Performance SummaryDepends on model parameters, details in paper35% (Apache) – 65% (SQL Server) slowdown vs. VM
Assumes
10k+ cycles SGX instructions, 30% slower RAM
…
and you don’t have to trust the cloud!Slide30
TCBTCB is large; however, all the code is under the client’s control, instead of cloudSlide31
What’s next?Rollback of persistent storageRequires more hardware or communicationUntrusted
time
Network
time sync, RDTSC
Cloud
management
Suspend
/ resume / migrate applications
Encrypted
VLANsSlide32
ConclusionsCloser to a true “utility computing” modelUtility provides raw resourcesDoesn’t care what you do with them
Why
trust the cloud when you don’t have to?Slide33
Questions?