1 of 35

A RISC-V Extension to Minimize Privileges of Enclave Runtimes

Neelu Kalani and Edouard Bugnion

1

Neelu Kalani and Edouard Bugnion

2 of 35

Sneak Peek

2

SM

OS

EApp

TRTS

App

Enclave

TRTS Utils

SB_OS

RISC-V Physical Memory Protection

Address Range	RWX

Our Proposal: �RISC-V PMP-extension to enforce

the least privilege principle for TRTS.�Keystone-LP.

Lack of enforcement of least privilege principle on the TRTS!

3 of 35

Outline

3

SM

OS

EApp

TRTS

App

Enclave

TRTS Utils

SB_OS

RISC-V Physical Memory Protection

Address Range	RWX

Our Proposal: �RISC-V PMP-extension to enforce

the least privilege principle for TRTS.�Keystone-LP.

Lack of enforcement of least privilege principle on the TRTS!

4 of 35

Trusted Execution Environments (TEEs)

4

SM

Host OS

EApp

TRTS

App

Enclave

TRTS Utils

SB_OS

EApp = Enclave Application

Requires confidentiality and �integrity guarantees

SM = Security Monitor

Provides security guarantees

TRTS = Trusted Runtime System/� Shielding Runtime

Mediate OS and EApp interactions

5 of 35

TRTS = Shield

5

Host OS

EApp

TRTS

TRTS Utils

The TRTS shields the EApp from the untrusted host �and is in the EApp’s TCB!

6 of 35

TRTS Software is Large

6

EApp

Keystone �Runtime Eyrie

5 kLoC

Graphene/�Overshadow Runtimes�13-22 kLoC

CURE Runtime�(Linux kernel)/Haven LibOS�Millions of LoC

SCONE�Shielding�Library�180 kLoC

Iago attacks!

Memory leaked or corrupted!

Impersonation attacks!

Linux kernel CVEs!

7 of 35

TRTS Mediated Interactions Between EApp and OS

The enclave address space contains memory shared with the untrusted OS!

7

EApp �Memory

Str[100]

Address X

SB_OS

Str[0-49]

“EApp secret”

Address X + 100

copy_from_user(Y, X, 50)

ret = ocall(write, Y)

//OS performed write syscall

bytes_written += ret

Address Y

While (bytes_written < len) {

X += ret //X + 50

}

Str[50-99]

TRTS Code

print(Str)

Now let’s take an example of an interaction between the EApp and the untrusted OS mediated by the TRT: �Here we have inside EApp memory a character array and other secret information. �Suppose the EApp wants to print this array. ��The TRTS will then copy the array into the SBhost. In this case, the array doesn’t fit, so the TRTS will copy it partially. �For example, the TRTS copies the first half of the array from address X in EApp memory to addr Y in the SB. ��And then it triggers the call to the untrusted OS requesting it to perform the write system call.�The OS does that and returns the number of bytes that were written. �Now the TRTS advances the array pointer by this return value and repeats until the entire array is printed. ��So here, the OS cannot access the eapp’s memory, �but the enclave address space contains the SB accessible by the OS using �which the TRTS securely exposes enclave application’s data to the OS.

8 of 35

TRTS = Confused Deputy

The untrusted OS abuses the TRTS into acting as a confused deputy�and leak secret EApp data through the shared communication channel.

8

Str[100]

Address X

SB_OS

Str[0-49]

“EApp secret”

Address X + 100

copy_from_user(Y, X, 50)

ret = ocall(write, Y)

//OS performed write syscall

X += ret // X + 100

Address Y

While (bytes_written < len) {

bytes_written += ret

}

Str[50-99]

//Malicious OS returns an unexpected value

TRTS Code

EApp �Memory

“EApp Secret”

9 of 35

The TRTS

Is a part of the TCB, hence is not malicious.

Can be large and buggy.

Has unrestricted access to EApp memory.

How do we protect the EApp from trusted software?

9

10 of 35

Our Goal: Rethink the Trust Model in TEEs

10

SM

Host OS

EApp

TRTS

App

Enclave

TRTS Utils

SB_OS

11 of 35

Our Goal: Rethink the Trust Model in TEEs

11

SM

Host OS

EApp

TRTS

App

Enclave

TRTS Utils

SB_OS

Strengthen the isolation provided to the EApp

Enforcing the least privilege principle on the privileged TRTS

Str[100]

Address X

SB_OS

“EApp secret”

Address X + 100

EApp �Memory

12 of 35

Key Takeaways

TRTS = Large + Buggy + Unrestricted Access to EApp Memory

Wide range of attacks from the untrusted world

Impose isolation between EApps and TRTS

Enforce the Least Privilege Principle on the TRTS

12

13 of 35

Outline

13

SM

OS

EApp

TRTS

App

Enclave

TRTS Utils

SB_OS

RISC-V Physical Memory Protection

Address Range	RWX

Our Proposal: �RISC-V PMP-extension to enforce

the least privilege principle for TRTS.�Keystone-LP.

Lack of enforcement of least privilege principle on the TRTS!

14 of 35

RISC-V Physical Memory Protection (PMP)

Protect contiguous physical memory address ranges

14

Address Range	RWX

PMP0

PMP1

PMP7

15 of 35

RISC-V Physical Memory Protection (PMP)

Priority based mechanism

15

Address Range	RWX

Decreasing

priority

PMP0

PMP1

PMP7

16 of 35

RISC-V PMP: Who Protects Physical Memory From Whom?

16

Firmware

OS

App

M-mode

RISC-V Privilege Modes

S-mode

U-mode

App

PMP rules are �configured by M-mode

PMP rules are applied to U-mode and S-mode

17 of 35

PMP Enforcement during Address Translation

17

TLB

1) Address translation request

(virtual address, request.RWX)

2) TLB Miss

PTW

PMP

3) Translation successful�(physical address, PTE.RWX)

Check PMP

4) Match with pmpaddr, �TLB.RWX = PTE.RWX & pmpcfg.RWX

5) TLB fill with �TLB.RWX

2) TLB Hit,�No need for a PMP check

5) PMP.RWX & request.RWX = 0, �PMP check fail,�access fault

V	Tag	PA	RWX	U

Addr.	RWX

18 of 35

Can PMP be Leveraged by the SM in TEEs?

18

19 of 35

Can PMP be Leveraged by the SM in TEEs?

19

Decreasing

priority

PMP0

RWX = 000


RWX = 111

PMP1

PMP7

SM

Executing�OS

Physical �Memory

20 of 35

Can PMP be Leveraged by the SM in TEEs?

20

Decreasing

priority

PMP0

RWX = 000

PMP1

PMP7

TRTS + EApp

RWX = 000

SM

Executing�Enclave

Executing�OS

Physical �Memory

RWX = 111

RWX = 000

This is how open source TEE framework Keystone also uses PMP!

21 of 35

Can we use RISC-V PMP to achieve our goal?

PMP doesn’t distinguish between U-mode and S-mode.

Trap into M-mode at every transition.

Reconfigure PMP - TLB flush!

As expensive as transitions between host and enclave!

Inefficient choice.

21

22 of 35

RISC-V SSTATUS.SUM Bit

SUM (permit Supervisor User Memory access) bit.

S-mode cannot access user pages if SUM = 0.

Configured by S-mode!

Aim is to protect S-mode software from accidentally accessing untrusted U-mode data!

Does not prevent TRTS from leaking EApp secrets!

22

23 of 35

Key Takeaways

RISC-V PMP is a promising security primitive for TEEs

But it doesn’t distinguish between privilege modes
Hence, lacks least privilege enforcement

RISC-V SUM bit prevents accesses to user pages from S-mode - but is controlled by S-mode

23

24 of 35

Outline

24

SM

OS

EApp

TRTS

App

Enclave

TRTS Utils

SB_OS

RISC-V Physical Memory Protection

Address Range	RWX

Our Proposal: �RISC-V PMP-extension to enforce

the least privilege principle for TRTS.�Keystone-LP.

Lack of enforcement of least privilege principle on the TRTS!

25 of 35

RISC-V PMP Extension

AS bit: Allow Supervisor access to User Pages.

M-mode governed equivalent of SUM bit in the PMP.

25

Address Range	RWX + AS bit

PMP0

PMP1

PMP7

26 of 35

AS bit in the TLB

1 additional bit per TLB entry.

26

TLB

1) Address translation request

(virtual address, request.RWX)

2) TLB Miss

PTW

PMP

3) Translation successful�(physical address, PTE.RWX)

Check PMP

4) Match with pmpaddr, �TLB.RWX = PTE.RWX & pmpcfg.RWX�TLB.AS = pmpcfg.AS

5) TLB fill with �TLB.RWX and TLB.AS bit

2) TLB Hit,�No need for a PMP check

5) PMP check fail,�access fault

V	Tag	PA	RWX	U	AS

Addr.	RWX	AS

27 of 35

Keystone-LP: How can the SM use PMP extension?

27

Decreasing

priority

PMP0

RWX = 000

PMP1

PMP7

TRTS + EApp

RWX = 000

SM

Executing�Enclave

Executing�OS

Physical �Memory

RWX = 111

RWX = 000

RECAP:

28 of 35

Keystone-LP: How can the SM use PMP extension?

2 PMP entries per enclave.�Number of simultaneous enclaves = (Number of PMP entries - 2)/2

28

Decreasing

priority

PMP0

PMP1

PMP7

RWX = 000, AS = 0

Executing�Enclave

Executing�OS

RWX = 000, AS = 0

TRTS

SM

Physical �Memory

EApp

SB_TRTS

PMP2

RWX = 111, AS = 0

RWX = 111, AS = 1

RWX = 000, AS = 0

RWX = 111, AS = 1

RWX = 000, AS = 0

SB_TRTS = Shared buffer between TRTS and EApp

29 of 35

TRTS = Confused deputy

29

Str[100]

Address X

SB_OS

Str[0-49]

“EApp secret”

Address X + 100

Address Y

Str[50-99]

EApp �Memory

“EApp Secret”

30 of 35

Yet again, TRTS = Confused deputy

The SB_TRTS allows the EApp to expose selected data to the TRTS.

Even if the TRTS has vulnerabilities, it doesn’t have direct access to EApp data anymore!

30

Str[100]

Address X

SB_TRTS

“EApp secret”

Address X + 100

Address Y

EApp �Memory

SB_OS

Address Z

Str[100]

31 of 35

Is the risk eliminated completely?

TRTS software is still in the TCB

Controlled-channel attacks, etc.

The EApp can leak its own secrets to the SB_TRTS

Our mechanism raises the bar to exploit TRTS vulnerabilities to leak sensitive EApp data!

31

32 of 35

Key Takeaways

We introduce AS-bit in PMP viz. M-mode governed SUM-bit equivalent
This prevents a class of confused-deputy attacks and raises the bar to exploit TRTS vulnerabilities

32

33 of 35

Summary

TRTS - No Least Privilege Principle Enforcement

Large and buggy software leaks secrets

RISC-V PMP is promising, but has limitations

Cannot enforce least privilege principle

Our proposal: AS-bit in the PMP

M-mode governed equivalent of SUM bit

Raises the bar to exploit TRTS vulnerabilities to leak EApp secrets

Still a long gap between existing TRTS and ideal trusted runtime

33

34 of 35

34

35 of 35

35