Securing RISC-V

Nick Kossifidis (Runtime Integrity SIG)

On behalf of Security HC
 Security and RISC-V
Standards Compliance, Security Incident Response, Best Practices,
Process
Security Model
RISC-V’s open and clean-slate
Security Ecosystem (OS, VMM, Runtimes, Tools, Apps) Firmware,
design presents a unique Software,
Tools and
opportunity to ingrain security for Secure Boot, Attestation, Confidential Workloads Protocols

the next generation of compute

infrastructure. Confidential Computing

Trusted Execution Environment

● Foundational Security and
Hardware
Cryptography Memory Isolation and Safety Security
Capabilities
● Application & System Cryptographic Isolation and Acceleration
Hardening against bugs/
exploits Runtime Integrity - Control Flow, Memory Tagging
● Trusted Execution &
Side Channel Leakage Protection
Confidential Computing
● Security Lifecycle HW Root-of-Trust

Processor
Embedded Application Server Cores
2
Quick overview
of the RISC-V
Privilege spec
RISC-V Privilege modes
Machine Mode User Mode Supervisor Mode
● Mandatory ● Optional (depends on ● Optional (depends on M-mode
● The most privileged / M-mode) and U-mode)
protected mode visible to the ● The least privileged / ● Sits between M-mode and
software (there is also Debug protected mode U-mode
mode but it’s only accessible / ● Physical/virtual memory ● Provides virtual memory
addressing / protection
visible to hw debuggers) addressing Physical/virtual
● Trap/interrupt handling through
● Physical memory addressing memory protection
delegation, managed by M-mode
● Physical memory protection ● No trap/interrupt handling
● May act as a hypervisor (aka
● Trap/Interrupt handling and
HS-mode) through the use of an
delegation
extra set of CSRs, also providing
a second stage of translation /
protection for guests (aka
VS-mode instances)
The RISC-V Privileged Spec
https://github.com/riscv/riscv-isa-manual/releases

4
RISC-V Trap and interrupt delegation / mode switching

5
TEE Scenarios
Trusted Services as part of the firmware
Trusted Services on S/U-mode
Trusted Services on VS/VU-mode
RISC-V CoVE Deployment Models (WiP)

● All deployment models require existing priv ISA w/ H extension, and

○ AP-TEE ABI (TH-ABI, TG-ABI)
○ Measurement and Attestation
○ Security Arch. implementation recommendations
● Some deployment models (2) require additional HW functionality e.g. AP-TEE mode, MTT
● Some deployment models (3) require additional HW functionality e.g. M-mode iso
● Implementation-specific aspects remain the same e.g. memory encryption

10
Trusted you said ?
What we can trust:
● The hardware (if we are running on an emulator or under a hw debugger it’s game over)
● Whatever runs on M-mode (our local trust anchor)
● A small trusted Hypervisor acting as a secure monitor (also allows for dynamic TEE management)
What we can’t trust:
● The OS
● The hypervisor
Current workarounds:
● Secure Boot at least guarantees OS/Hypervisor’s integrity
○ But we don’t have a Secure Boot / boot attestation protocol yet
● SMAP/SMEP makes it harder for attackers to tamper with the application and its data
○ But on a rooted device an attacker can load kernel modules and bypass it
● User-level DMA/MMIO to access trusted service / hw directly
○ But the memory mappings are still managed by the OS
● Secure channel between the application and the trusted service
○ But on a rooted device an attacker can debug the application and inspect the key exchange
Work in progress…
● Root of Trust establishment
● Secure boot and attestation of the boot process
● Initialization and attestation of TEE payloads
● Confidential Computing / Enclaves
● Security Incident Response Team (SIRT)
● Vector Crypto and support for more non-NIST crypto algorithms
Under the hood
Memory
Isolation
Physical Memory Protection (PMP)
● Basic isolation between M-mode and S/U-modes.
● Normal rules apply to S/U, Locked rules (impossible
to edit after adding them) apply to all modes. PMP
gives access to S/U (locked down by default) and
restricts M (full access by default).
● Up to 64 entries for defining physical memory
regions and their permissions.
● Support for three different addressing modes (TOR,
NA4, NAPOT).
● Priority matching from lower to higher indexed
entries.
Enhanced Physical Memory Protection (ePMP)

● Locked rules that apply only to M mode.

● Access/execution prevention from
M-mode to S/U-mode.
● Ability to switch policy from blacklist to
whitelist for M-mode.
● Ability to prevent adding new executable
regions on M-mode.
● Shared regions with reduced privileges
between M-mode and S/U-modes.
● Allow for greater flexibility to support
more use cases.
● Ratified
Supervisor PMP (sPMP)
● May be used instead of the MMU on
S/HS/VS-modes.
● Similar encodings to ePMP.
● Fast switching between sets of rules.
● Useful for:
○ Supporting small trusted hypervisors
on HS-mode (VS to VS and HS to VS
isolation)
○ TEEs on S/U/VS-mode
○ Small IoT devices without MMU
● Under development, goal was to freeze by
the end of 2024.
● Latest update: Resolved issues raised by
ARC
Virtual memory
● Isolation between S and U mode and between
tasks on U mode.
● Also used for isolation between guests (VS -
VS), and between the guests and the host (HS -
VS), using a 2nd translation stage.
● SMEP is always in place, there is no way for S
mode to execute pages marked with the U bit.
● SMAP is on by default but can be disabled
temporarily (through sstatus.SUM) so that
S-mode can read/write data from U-mode on
specific code paths (e.g. copy_to/from_user() on
Linux).
Pointer Masking
actual_address = (requested_address & ~mpmmask) | mpmbase

● Bits on the mask are ignored by the hardware and replaced by the contents of
mpmbase. Works for both physical and virtual addresses.
● Can be used for software-based memory tagging, by using the masked bits of
the address for tags and checking them on software.
● Can also be used as a simple memory protection mechanism, by allowing code
to restrict its allowed memory range (e.g. restrict a library to only access code /
data within an address range, without being able to access the rest of the
task’s memory).
● Each privilege mode has own copy of pointer masking CSR register. It appears
as the mpmmask, spmmask, vspmmask and upmmask registers in the M-mode,
HS/S-mode, VS-mode and (V)U-mode ISAs, respectively.
● Each privilege mode has its own copy of pointer base CSR register. It appears
as the mpmbase, spmbase, vspmbase and upmbase registers in the M-mode,
HS/S-mode, VS-mode and (V)U-mode ISAs, respectively.
● A simpler version is going for ratification.
Supervisor Domains
● A more flexible/extensible approach to Physical Memory Protection
● System is split in Supervisor Domains, managed by trusted M-mode software (Root Domain
Security Manager - RDSM)
● Each domain is associated with a series of physical memory regions, through a table called
Memory Tracking Table (MTT), held in memory.
● RDSM switches between Supervisor Domains by re-setting mtt pointer register (mttp)
● Better suited for systems with complex VMs/TEEs on S/VS-mode
● Required for confidential computing
Work in progress…
● Hardware Fault Injection (HFI)
○ https://cseweb.ucsd.edu/~dstefan/pubs/narayan:2023:hfi.pdf
○ Latest update: Charter for task group almost ready to go
● Memory Tagging
○ A dedicated task group (TG) has been created
■ Intention is security and debugging use cases
○ Depends on pointer masking
● Capability-based protections (CHERI/Capstone)
○ There is another SIG for that…
● M-mode isolation / lightweight TEE
○ Most of us prefer to just privilege things on S-mode
○ But there are some use cases where we need isolation on M-mode
Memory tagging
- Usage / deployment : Deployable in production
- Safety requirements
- Temporal (use after free) and Spatial (out of bounds) safety both
- ISA
- >= 64 bit only
- Virtual address accesses subject to tag checks (not applicable to physical addr accesses)
- Explicit tag rd/wr must happen via dedicated instructions
- Fault reporting: synchronous (min) and asynchronous both
- Granularity: 16 bytes (min)
- Tag size: >= 4bit
- Usable privilege: U, S, HS, VS
- Group asked for M-mode
- Implicit and explicit checks both
- Software control on tag checks : Use a PTE bit or an unused encoding
- Hardware assisted tag creation for portable binary (portable stack pointer creation) : Yes
- Tag storage : Virtual memory
- In case of M-mode or bare mode, virtual = physical
Isolation
between
devices
I/O PMP Overview
● Provides per-device memory protection based
on incoming Source ID.
● Assignment of Source IDs are out of scope.
● Number of Source IDs supported is
implementation-defined.
● Still work in progress
● We try to make it compatible with WorldGuard
 Multi-domain I/O Controller
● Provides per-domain Register
Programming Interface based on
Domain 1 Domain 2 Domain 3 Domain n
incoming Domain ID.
● Number of domains is
RPI1 RPI2 RPI3 RPIn implementation-defined.
IO Controller ● Domain initialization may be fixed
D1 D2 D3 Dn
(e.g. during system design) or
Config Config Config Config
and
state
and
state
and
state
and
state
dynamic (programmable e.g.
through a root secure monitor / root
of trust)
● In early stages of development…
I/O Memory Management Unit (IOMMU)
● DMA Remapping service
○ Present a sparse physical region as a continuous
virtual
○ Allow devices that can only access 32bit
addressable memory to overcome that limitation
● Virtual memory protection like the MMU
○ Page tables have the same format as the MMU
○ Applications may share page tables with devices
● Other useful functionality
○ Interrupt remapping
○ Memory management service to peripherals
○ …
● Ratified
IO-MTT
● Smmtt extension
● Per security domain device isolation
● DMA accesses protection
○ As specified in each domain MTT
● Suited for trusted I/O
○ E.g. confidential computing I/O
CoVE-IO
● Assign physical devices to TVMs
○ GPUs, accelerators, etc
● CoVE extension
○ Confidential computing I/O
● Trusted I/O for RISCV
● ABIs and flows for supporting TEE-I/O
○ As per the PCI and SPDM specs
Other ideas…
● MTT Checker
○ Same as IOPMP but uses MTT instead + domain id from the bus
● Secure debugging
○ Proposal by Joe Xie, TG is up, ratification plan approved
■ Joint work with the DTPM SIG
■ https://github.com/riscv-non-isa/riscv-external-debug-security
Crypto & TRNG
Scalar Crypto extension
Extensions:
● Zbkb - Bitmanip instructions for Cryptography (for SHA3, ChaCha…)
● Zbkc - Carry-less multiply instructions (for GCM)
● Zbkx - Crossbar permutation instructions (constant time S-boxes)
● Zknd - NIST Suite: AES Decryption
● Zkne - NIST Suite: AES Encryption
● Zknh - NIST Suite: Hash Function Instructions (SHA2)
● Zksed - ShangMi Suite: SM4 Block Cipher Instructions
● Zkr - Entropy Source Extension (next slide)
● Zksh - ShangMi Suite: SM3 Hash Function Instructions
● Zkt - Data Independent Execution Latency
Aliases:
● Zkn - NIST Algorithm Suite: Zbkb, Zbkc, Zbkx, Zkne, Zknd, Zknh
● Zks - ShangMi Algorithm Suite: Zbkb, Zbkc, Zbkx, Zksed, Zksh
● Zk - Standard scalar cryptography extension: Zkn, Zkr, Zkt
For more infos:
https://iacr.org/submit/files/slides/2021/rwc/rwc2021/41/slides.pdf
https://github.com/riscv/riscv-crypto/releases
TRNG specification (Zkr)
It’s a Noise Source meant for seeding, not a DRBG (not repeating RDRAND mistakes)
Hardware:
● Sampling
● Health-checking (verify correct operation)
● Non-cryptographic conditioning (so that it can be tested / verified)
● Two instructions:
○ GetNoise -> returns raw noise for testing/verification - M-mode only
○ PollEntropy -> returns conditioned data + health status - S/M-mode
Software:
● Entropy Accumulator / Estimator
● Cryptographic conditioning (e.g. with a PRNG)

More infos:
https://mjos.fi/doc/20201113ashes.pdf
https://eprint.iacr.org/2020/866.pdf
 Other
mechanisms
Control Flow Integrity (CFI)
● New CFI execution mode
● Shadow stack to protect from ROP
attacks, architecturally protected.
● Forward-edge protection using labeled
landing points.
● Frozen/Ratification within 2024
Other proposals in progress...
● FENCE.T / SEC.FLUSH: Instructions to
flush microarchitectural state, to
mitigate spectre-like side channels.
● Secure function calling: Enter/Exit an
isolated environment on S/U, without
going through the secure monitor on M
mode.
 Security HC - Organization
RVI TSC Charter in
process
(acting chairs)
Security HC
Andy Dellow, Ravi Sahita
Operational
SIG
Formal Crypto TG Runtime Integrity Control Flow Trusted Blockchain uSC SIG
Security CHERI SIG
Security (Scalar, SIG Integrity SIG Computing SIG SIG
Model TG
Proofs Vector) Ronan
Alex Operational
Paul Elliott, Nick Kossifidis, George Ravi Sahita, Patty Tu, Lashermes, HC/SIG/TG
Debug Richard Deepak Gupta Christou, Ved Open Richardson, Gary Xu Allison Randal
Nicholas Simon
Access Newell, Ken Shanbhogue
Wood Moore
Controls Dockser

AP-TEE (CoVE) TG CHERI TG Completed

Software/ SPMP TG - SS & LP TG uSCR-IS TG (Closed)
PQC TG Ravi Sahita, Alex
Platform Dong Du (George
Markku Guerney Hunt Richardson,
Security SIRT SIG Christou, Ved Ronan
Saarinen, Simon Moore
SIG IOPMP TG - Shanbhogue) Lashermes,
Nicolas Brunie Nils Wistoff
Don Bailey Paul Ku, Channing CoVE-IO TG -
(TBC) Tan Samuel Ortiz,
Jiewen Yao Dotted Line

Lightweight
GOST-R HA Crypto TG isolation TG Smmtt TG
Richard Ravi Sahita,
Crypto TG Newell, Krste Asanovic Further
(on hold) Markku ePMP Discussion
Saarinen Nick Kossifidis needed

Secure Debug
Jo Xie, Gokhan Kaplayan
Requires Setup
 Security HC - Active Items & Roadmap
Strategy & Gaps analysis → SIG, TG formation
Security
Security Model (non-ISA) TG . . Ecosystem, Ref. implementations, etc.
HC Server Platform Security Svcs.
Security Incident Response Team
Scalar Crypto

Crypto Vector Crypto Vector Crypto (High Assurance Crypto)

PQC Crypto

CoVE TG (non-ISA)
CoVE-IO (non-ISA)
Trusted (Conf)
Computing SIG Smmtt (ISA, non-ISA) w/ Priv IC
IOMMU

CFI Shadow Stack and Landing Pads (Zsslpcfi) TG

Runtime S-PMP Memory Tagging w/ IC

Integrity SIG
IOPMP Compartmentalization w/ IC
Memory Pointer Masking (J ext) Lightweight Isolation w/ IC
uSC SIG
Microarchitecture Side-Channel Resistant Instruction Spans TG

CHERI SIG CHERI TG

2023 2024

Sponsored SIG Sponsored TG Sponsored TG (not under Security HC Potential TG 38

Security HC
In completion (2023) In progress (2024) Starting Now
ISA/non-ISA - HW
ISA (HW) - SmMTT – Supervisor ● CHERI TG
- Vector Crypto Domains Isolation ● Memory Tagging TG
- SSLP- Shadow stacks and - IO-PMP – Bus level PMP ● SW: Reference crypto
landing pads for ROP/JOP (subsumes WG non-ISA) library (Needs setup)
protection - HA Crypto – Side channel ● Compartmentalization
- Pointer Masking resistance key management (in SIG)
- SPMP – Supervisor PMP - PQC – Post Quantum Crypto ● Lightweight Isolation ?
(ARC review) - Uarch Side Channel
Resistant - Fence
Non-ISA (SW) - Secure Debug (Dotted-line)
Fast Track
- CoVE ABI (in ARC review) non-ISA - SW / Informative
● World Guard ISA (CSR)
- Security Model
- CoVE-IO ABI– Device
assignment to CoVE
workloads

https://wiki.riscv.org/display/HOME/Specification+Status Bold = priorities

 Active Security (TG) Specifications –
Specification Q4’23 Q1’24 Q2’24 Q3’24 Q4’24

Security
HC Security Model: Server Platform
HC Develop Freeze Rat-Ready
Sec. Svcs. (non-ISA: spec)

Crypto
Crypto Vector crypto (ISA) Done

E
TC SIG CoVE (non-ISA: SW) Freeze Rat-Ready
Trusted
A T
D
Computing SIG CoVE-IO (non-ISA: SW) Develop Freeze Rat-Ready

U P
S
Smmtt TG (ISA, non-ISA:HW) Develop Freeze Rat-Ready

ED
NE
CFI Freeze Rat-Ready
RI SIG SSLP (ISA)

Freeze Rat-Ready
RI SIG
Runtime S-PMP (ISA)
Integrity SIG
RI SIG IOPMP (non-ISA: HW) Develop Freeze Rat-Ready

uSC
USCSIG
SIG uSCR-IS (ISA) Develop Freeze Rat-Ready

IOMMU IOMMU (non-ISA: HW) Done

Other related
SIGs
J MPM (ISA) Freeze Rat-Ready

https://wiki.riscv.org/display/HOME/Specification+Status
Comparison with other architectures…
Feature arm intel AMD

Arbitrary Code Execution NX/SMAP/SMEP (Priv. Spec) Privilege Access Never NX/SMAP/SMEP XD/SMAP/SMEP

Control Flow Integrity Zisslpcfi (Shadow Stack Landing Pads TG) Branch Target Identifier Indirect Branch Tracking Shadow Stack
Pointer Authentication Code Shadow Stack
Guarded control stack

Cryptography AES, SHA2, SM3, SM4, entropy, Data Independent AES, SHA2, SHA3, SM3, SM4, RNG, Vector AES, SHA, RNG, AVX-512 AES, SHA, RNG, AVX2
Execution Latency, High assurance, vector, PQC

Confidential Compute (A-class TEE) RISC-V CoVE ABI (AP-TEE TG) ARM v9A Realms - Confidential Compute Intel SGX – Confidential app arch. AMD SEV (-ES, -SNP) - Confidential VM Arch.
Smtt TG Architecture Intel TDX – Confidential VM arch.
CoVE-IO Intel TDX-IO

Intra-address space isolation ePMP, SPMP, IOPMP Trustzone A/M System Mgmt. Mode (SMM) Supervisor System Mgmt. Mode (SMM) Supervisor
(M-class) Lightweight isolation TG (WiP) S/NS support

Intra-address space isolation Compartmelization, HFI (WiP) Domain Access Control Intel Memory Protection Keys ?
Permission indirection and overlays

Virtualization-based Security Hypervisor extension (Priv. Spec) ARM virtualization extension Intel VT-x, VT-d, TXT AMD SVM, IOMMU, SKINIT
IOMMU SMMU Mode-based exec, HLAT GMET
? Guest translation protection ? Translation hardening Nested virt acceleration Translation Hardening

Memory Safety Pointer masking (HW-ASAN) Memory Tagging Extension Memory tagging? Memory tagging?
Memory Tagging (WiP)
CHERI (WiP

Microarch. Side Channels uSC SIG (IS TG) Speculation Barriers Speculation Barriers Speculation Barriers

Reference crypto library N/A AArch64cryptolib Intel IPP Cryptography AMD Optimizing CPU Libraries

Ecosystem (APIs, reference Security Model (TG) Standard Security APIs Standard Security APIs Standard Security APIs
implementations, profiles, SBI definition (Open SBI) Open FW Reference Implementations Reference Implementations
certification, protocols) Standard Security ABIs Reference Implementations
Reference Implementations? Security Model
Questions ?
Thank you !