1. Hardware Memory Safety
Challenges and Opportunities
Manuel Costa
Microsoft Research Cambridge

2. Memory safety is the root cause of most
vulnerabilities
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
Memory Corruption
CVEs-2017 by Microsoft
We need solutions to memory safety

3. Memory safety is the root cause of most
vulnerabilities
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
[CELLRANGE]
Memory Corruption
CVEs-2027 by Microsoft
We need solutions to memory safety

4. Existing deployed mitigations
Control Flow Guard (CFG)
Enforce control flow integrity
on indirect calls
Shipped
Prevent
control-flow
hijacking
Arbitrary Code Guard (ACG)
Prevent dynamic code generation,
modification, and execution
Code Integrity Guard (CIG)
Images must be signed and arbitrary
images cannot be loaded
Shipped Shipped
Prevent
arbitrary code
generation

5. Examples of recent progress
This bug class accounted for 49 vulnerabilities reported to MSRC in 2017-2018 (~4%)
We’ve been adopting span in key code bases (e.g. Hyper-V) and it has already helped
eliminate vulnerabilities that were later identified

6. Towards getting to done with vulnerabilities
increasing cost & difficulty getting to done
Focus more on making it durably hard for developers to make mistakes while retaining good perf & dev efficiency

7. Challenges with breaking exploitation techniques
Place array base
or length at
predictable
location
Modify array base or
length
discover DLL base
address
discover DLL base
address & stack
address
Construct ROP
payload
Corrupt state of
security policy
Read sensitive content
Corrupt function
pointer
Corrupt return
address
Corrupt C++ virtual
table pointer
Execute
ROP
payload
Execute
arbitrary
native
code
Morello/CHERI breaks key points
in common exploit chains

8. Bounds checks in software can be expensive
get:
ldr w0, [x0, w1, sxtw #2]
ret
get:
sxtw x8, w2
cmp x0, x8
b.ls .LBB0_2
ldr w0, [x1, x8, lsl #2]
ret
.LBB0_2:
bl gsl::details::terminate()
No bounds checks Span bounds checks
Load the bounds
Check the bounds
Abort
int get(gsl::span<int> a, int b) { return a[b]; }

9. Bounds checks in hardware are cheaper
get:
ldr w0, [x0, w1, sxtw #2]
ret
get:
ldr w0, [c0, w1, lsl #2]
ret
No bounds checks Span bounds checks with Morello
int get(gsl::span<int> a, int b) { return a[b]; }

10. Safe languages depend on systems languages
for security
0
1,000,000,000
2,000,000,000
3,000,000,000
4,000,000,000
5,000,000,000
6,000,000,000
7,000,000,000
8,000,000,000
9,000,000,000
C C++ Rust JavaScript Java C#
Data from OpenHub.NET
Safe Languages
Systems Languages
Linesofpubliccode

11. Safe languages need a secure migration path
SANDBOXED LEGACY
LIBRARIES
HARDWARE MEMORY
SAFETY FOR CLOSELY
COUPLED C++ CODE
ACCELERATION FOR
COMMON SAFETY CHECKS

12. Securing the cloud with new hardware

13. 54
REGIONS WORLDWIDE
100K+
MILES OF FIBER AND SUBSEA CABLE
130+EDGE SITES
200+ExpressRoute Partners

14. Azure Confidential Computing
Code
Data
Goal: Provide the highest levels of privacy
and security for Azure workloads
New architecture based on hardware-based
Trusted Execution Environments (TEEs)
New instructions to set aside private regions
(“protected containers”) of code and data
Data is only ever in the clear within the
hardware-protected containers
Minimizes attack surface

15. SQL Always Encrypted
Secure computations
inside SQL Enclave
Rich queries In-place encryption
Protects sensitive data
in use while preserving rich
queries and providing in-
place encryption ciphertext
C:
Enhanced
Client Driver
TEE
plaintext

16. User
User
User
User Current State
key-value store
Bring your
own code
replication between trusted
execution environments
Primary
Member
User
User
User
Member
User
consortium
Backup
Verifiable
Ledger
Verifiable
Ledger
authenticated
encryption &
signatures
untrusted storage
secure channel (TLS)
untrusted network
untrusted hosts
security spec
distributed implementation
clients secure service
Member
Member Governance
consortium
Confidential Consortium Framework

17. Research and
development
opportunities
Performance analysis and optimizations
Language and hardware co-design
Making existing mitigations more efficient
Compartmentalizing applications
Reasoning about guarantees of compartmentalized applications
Efficient temporal safety
Supporting legacy codebases

18. Summary
Mitigating/eliminating memory safety
exploits is crucial
Microsoft is eager to adopt hardware
innovations
Many interesting avenues for research
and development
Looking forward to partnering on this
journey together