Rob Turner, Qualcomm Technologies Almost three decades since the Morris worm and we're still plagued by memory corruption vulnerabilities in C and C++ software. Exploit mitigations aim to make the exploitation of these vulnerabilities impossible or prohibitively expensive. However, modern exploits demonstrate that currently deployed countermeasures are insufficient. In ARMv8.3, ARM introduces a new hardware security feature, pointer authentication. With ARM and ARM partners, including Microsoft, we helped to design this feature. Designing a processor extension is challenging. Among other requirements, changes should be transparent to developers (except compiler developers), support both system and application code, interoperate with legacy software, and provide binary backward compatibility. This talk discusses the processor extension and explores the design trade-offs, such as the decision to prefer authentication over encryption and the consequences of small tags. Also, this talk provides a security analysis, and examines how these new instructions can robustly and efficiently implement countermeasures.

1. Raising the Bar
New Hardware Primitives for Exploit Mitigations
Rob Turner
Qualcomm Technologies, Inc
2017/11/08

2. 2
Agenda
• Design
◦ ~8 Slides
• Cryptography
◦ 2 Slides
• Security Analysis
◦ 2 Slides
• Applications
◦ 3 Slides

3. Design

4. 4
6
3
03
1
5
5
71
5
2
3
3
9
4
7
What’s in an ARMv8 Pointer?

5. 5
6
3
03
1
5
5
71
5
2
3
3
9
4
7
What’s in an ARMv8 Pointer?

6. 6
6
3
03
1
5
5
71
5
2
3
3
9
4
7
What’s in an ARMv8 Pointer?

7. 7
6
3
03
1
5
5
71
5
2
3
3
9
4
7
What’s in an ARMv8 Pointer?

8. 8
6
3
03
1
5
5
71
5
2
3
3
9
4
7
What’s in an ARMv8 Pointer?

9. 9
6
3
03
1
5
5
71
5
2
3
3
9
4
7
What’s in an ARMv8 Pointer?

10. 10
6
3
03
1
5
5
71
5
2
3
3
9
4
7
What’s in an ARMv8 Pointer?

11. 11
0
6
3
03
1
5
5
71
5
2
3
3
9
4
7
What’s in an ARMv8 Pointer?

12. 12
0 0 0 0
6
3
03
1
5
5
71
5
2
3
3
9
4
7
0 0 0 0 0 0 0 0
What’s in an ARMv8 Pointer?

13. 13
1
6
3
03
1
5
5
71
5
2
3
3
9
4
7
What’s in an ARMv8 Pointer?

14. 14
1 1 1 1
6
3
03
1
5
5
71
5
2
3
3
9
4
7
1 1 1 1 1 1 1 1
What’s in an ARMv8 Pointer?

15. 15
6
3
03
1
5
5
71
5
2
3
3
9
4
7
What’s in an ARMv8 Pointer?

16. 16
6
3
03
1
5
5
71
5
2
3
3
9
4
7
What’s in an ARMv8 Pointer?

17. 17
6
3
03
1
5
5
71
5
2
3
3
9
4
7
What’s in an ARMv8 Pointer?

18. 18
The Key Idea
• Use the unused bits in pointers to store an authentication code. Verify the authentication code
before dereferencing the pointer.
• Two Operations:
◦ Compute an authentication code and tag a pointer.
◦ Verify a pointer by recomputing the authentication code and comparing it with the pointer’s
tag.

19. 19
6
3
03
1
5
5
71
5
2
3
3
9
4
7
Authentication Code Size
• 3 bits.

20. 20
6
3
03
1
5
5
71
5
2
3
3
9
4
7
Authentication Code Size
• 11 bits.

21. 21
6
3
03
1
5
5
71
5
2
3
3
9
4
7
Authentication Code Size
• Between 11 and 31 bits.

22. 22
Authentication Code Size
• 16 bits.
6
3
03
1
5
5
71
5
2
3
3
9
4
7

23. 23
Scope and Design Criteria
• AARCH64 Only
• Minimally Invasive
• Compatible and Interoperable

24. 24
Instructions
• PAC*
◦ PACIA, PACIB, PACDA, PACDB, …
◦ Compute an authentication code and tag a pointer.
• AUTH*
◦ AUTHIA, AUTHIB, AUTHDA, AUTHDB, …
◦ Verify a pointer by recomputing the authentication code and comparing it with the pointer’s
tag.

25. 25
Some Details
• The authentication code is computed based on only the virtual address bits.

26. 26
Some Details
6
3
03
1
5
5
71
5
2
3
3
9
4
7

27. 27
Some Details
6
3
03
1
5
5
71
5
2
3
3
9
4
7

28. 28
Some Details
6
3
03
1
5
5
71
5
2
3
3
9
4
7

29. 29
Tagging a Valid Pointer
Some Details
? ? ? ? ? ? ?
6
3
03
1
5
5
71
5
2
3
3
9
4
7

30. 30
Authentication Succeeds
Some Details
0
6
3
03
1
5
5
71
5
2
3
3
9
4
7

31. 31
Authentication Succeeds
Some Details
0 0 0 0 0 0 0 0
6
3
03
1
5
5
71
5
2
3
3
9
4
7

32. 32
Authentication Succeeds
Some Details
1
6
3
03
1
5
5
71
5
2
3
3
9
4
7

33. 33
Authentication Succeeds
Some Details
1 1 1 1 1 1 1 1
6
3
03
1
5
5
71
5
2
3
3
9
4
7

34. 34
Authentication Fails
Some Details
1 1 0 1 1 1 1 1
6
3
03
1
5
5
71
5
2
3
3
9
4
7

35. 35
Authentication Fails
Some Details
1 1 1 0 1 1 1 1
6
3
03
1
5
5
71
5
2
3
3
9
4
7

36. 36
Tagging an Invalid Pointer
Some Details
? ? ? ? ? ? ?
6
3
03
1
5
5
71
5
2
3
3
9
4
7

37. 37
Tagging an Invalid Pointer
Some Details
? ? ? ? ? ? ?
6
3
03
1
5
5
71
5
2
3
3
9
4
7

38. 38
Instructions
• PAC*
◦ PACIA, PACIB, PACDA, PACDB, …
◦ Compute an authentication code and tag a pointer.
• AUTH*
◦ AUTHIA, AUTHIB, AUTHDA, AUTHDB, …
◦ Verify a pointer by recomputing the authentication code and comparing it with the pointer’s
tag.
• PACGA
◦ Compute an authentication code.
• XPACI, XPACD
◦ Strip an authentication code from a pointer without verification.

39. 39
Authentication Versus Encryption
• Resistance to Guessing
• Error Detection
• Debugging
• Branch Prediction and Speculative Execution

40. 40
Context
• Contexts are an additional, public input to the authentication algorithm, specified explicitly as
an input register or implicitly by the instruction variant.
• Contexts mitigate pointer substitution attacks: maliciously overwriting a tagged pointer with a
different tagged pointer.
• Contexts can “emulate” the granularity of other control-flow integrity schemes.
◦ Microsoft’s Control-Flow Guard
◦ LLVM’s Cross-DSO Control-Flow Integrity
◦ Abadi Control-Flow Integrity
◦ Cryptographically-Enforced Control-Flow Integrity

41. Cryptography

42. 42
QARMA
• We need a fast, lightweight algorithm.
◦ Cryptographically strong when truncated for short authentication codes.
◦ Two 64-bit inputs, a 128-bit key, and a 64-bit output.
• Enter QARMA.
◦ A new family of lightweight, tweakable ciphers.
• Block Cipher:
◦ f(secret key, plaintext) -> ciphertext
• Tweakable Block Cipher:
◦ f(secret key, plaintext, tweak) -> ciphertext

43. 43
Key Management
• Five 128-Bit Keys
◦ Two keys for pointers to instructions
◦ Two keys for pointers to data
◦ One key for the generic MAC instruction
◦ One key to rule them all and in the darkness bind them
• Keys are not banked per Exception Level.
• System register controls for keys and instructions:
◦ Trap key use to Exception Level 2 or Exception Level 3.
◦ Trap instruction use to Exception Level 2 or Exception Level 3.
◦ Disable instructions for individual keys for backwards compatibility.

44. Security Analysis

45. 45
Security Analysis
• Security Boundary
• Threat Model
• Assumptions

46. 46
Attacks and Considerations
• Guessing and Forging Tagged Pointer Values
• Arbitrary Memory Read
• Arbitrary Memory Write
• Pointer Substitution Attacks
• Key Management Concerns and Key Re-use Attacks
• Interpreters and Just-in-Time (JIT) Compilation

47. Applications

48. 48
Expected Usage
• TrustZone / Secure Execution Environments
◦ Address Space can be reduced to allow longer authentication codes.
• Compiler Instrumentation
◦ Stack-Smashing Protection (SSP)
◦ Control-Flow Integrity (CFI)
• Compiler Built-ins
• Type and Variable Attributes

49. 49
Stack-Smashing Protection (SSP)
• Without SSP • With Software SSP • With PA SSP
ldr x1, [x3, #SSP]
ldr x2, [sp, #0x38]
cmp x1, x2
b.ne __stack_chk_fail
ldp x29, x30, [sp, #0x40]
add sp, sp, #0x50
ret
ldp x29, x30, [sp, #0x30]
add sp, sp, #0x40
retaa
ldp x29,x30,[sp,#0x30]
add sp,sp,#0x40
ret
sub sp, sp, #0x50
stp x29, x30, [sp, #0x40]
add x29, sp, #0x40
adrp x3, {pc}
ldr x4, [x3, #SSP]
str x4, [sp, #0x38]
paciasp
sub sp,sp,#0x40
stp x29, x30, [sp, #0x30]
add x29, sp, #0x30
sub sp, sp, #0x40
stp x29, x30, [sp,#0x30]
add x29, sp, #0x30
• Tag the saved return address. The context is the stack pointer.
insert canary into the stack
increased
frame size
the global canary
verify lr with sp as context
tag lr using
sp as context

50. 50
C Runtime Protections
• Linker and loader data structures
◦ Import Address Table (IAT) addresses
• C Standard Library (msvcrt.dll)
◦ struct jmp_buf pointers
◦ atexit() callback
• APIs
◦ Microsoft’s Encode*Pointer and Decode*Pointer and glibc’s PTR_MANGLE
• Tag all the things! (CFI)

51. 51
Coming Soon to a Processor Near You!
Conclusion
• Pointer authentication
◦ provides a new software security primitive, with good code size properties.
◦ can implement generic countermeasures.
• Stack-Smashing Protection (SSP) and Control-Flow Integrity (CFI)
◦ complements and improves existing mitigations.
• Best results will come from domain-specific hardening.
◦ Identifying and protecting sensitive pointers and data structures.
• Socialize ideas as widely as possible.

52. pointers

53. Follow us on:
For more information, visit us at:
www.qualcomm.com & www.qualcomm.com/blog
Thank you
Nothing in these materials is an offer to sell any of the components or devices referenced herein.
©2017 Qualcomm Technologies, Inc. and/or its affiliated companies. All Rights Reserved.
Qualcomm is a trademark of Qualcomm Incorporated, registered in the United States and other countries. Other products and brand names
may be trademarks or registered trademarks of their respective owners.
References in this presentation to “Qualcomm” may mean Qualcomm Incorporated, Qualcomm Technologies, Inc., and/or other subsidiaries
or business units within the Qualcomm corporate structure, as applicable. Qualcomm Incorporated includes Qualcomm’s licensing business,
QTL, and the vast majority of its patent portfolio. Qualcomm Technologies, Inc., a wholly-owned subsidiary of Qualcomm Incorporated,
operates, along with its subsidiaries, substantially all of Qualcomm’s engineering, research and development functions, and substantially all
of its product and services businesses, including its semiconductor business, QCT.

54. 54
References
• pointer authentication whitepaper
• QARMA whitepaper
• GCC7 stack-smashing protection release notes
• GCC7 stack-smashing protection patch
• LLVM stack-smashing protection patch
• Mark Rutland’s Linux kernel patch series
• Mark Rutland’s Linux kernel patch series Linux Weekly News article
• Mark Rutland’s Linux Security Summit 2017 talk slides
• Mark Rutland’s Linux Security Summit 2017 talk summary