Andes building a secure platform with the enhanced iopmp
0 likes326 views
The document provides an overview of building a secure platform using the enhanced IOPMP (Input/Output Physical Memory Protection). It discusses why IOPMP is needed to check accesses from non-RISC-V bus masters, describes the enhancements made to IOPMP including supporting multiple bus masters and flexible response options. It then provides an example of how IOPMP, PMP, and secure boot can establish a root of trust for the platform and describes AndeSentry, an open security framework from Andes Technology.
![Taking RISC-V® Mainstream 17
MID[3:0]
MID Encoding in IOPMP Entry
• An MID uses up to 14 bits, or 16,384 MIDs.
• An IOPMP entry contains up to 16 MIDs, by “MID.h” and “MID.l”.
MID[13:0]
MID.h[9:0] MID.l[15:0]
==
&&
Does the entry contain the MID?
MID[13:4]
Lower 4 bits uses
bitmap encoding
Upper 10 bits uses
binary encoding](https://image.slidesharecdn.com/andesbuildingasecureplatformwiththeenhancediopmp-210315173210/85/Andes-building-a-secure-platform-with-the-enhanced-iopmp-17-320.jpg)
Ad
More Related Content
What's hot (20)
Similar to Andes building a secure platform with the enhanced iopmp (20)
Ad
More from RISC-V International (20)
Ad
Recently uploaded (20)
Andes building a secure platform with the enhanced iopmp
- 1. Building a Secure Platform with the Enhanced IOPMP Shan-Chyun Ku, Deputy Technical Director Andes Technology December 9, 2020
- 2. Taking RISC-V® Mainstream 2 Biography of Shan-Chyun Ku Technical Areas • SoC Architect, SoC Security • Parallel Algorithms, System-level Performance Analysis Industry Experience Andes, 2019 Deputy Technical Director of Architecture Realtek, 2009 Manager of SoC, VoIP, and BSP Cadence, 2006 Member of Consulting Staff Faraday, 2001 Deputy Manager of Core Technology Education • PhD, CS, National Tsing-Hua University (Taiwan) • BS, CS, National Tsing-Hua University (Taiwan)
- 3. Why Have IOPMP? Enhanced IOPMP Example: Root-of-Trust AndeSentry™ Brief Agenda 1 2 3 4
- 4. Taking RISC-V® Mainstream 4 Why Have IOPMP?
- 5. Taking RISC-V® Mainstream 5 Why Have IOPMP? • Vulnerabilities of platforms give hackers the chance to access or tamper with sensitive data or devices. • PMP: checks the accesses issued from RISC-V harts. • IOPMP: checks the accesses issued from other bus masters.
- 6. Taking RISC-V® Mainstream 6 A Platform without an IOPMP mem controller RV hart PMP SRAM/ ROM eFuse General DMA non-RV core off-chip storage high-speed bus MMIO bus (arrow: bus cmd direction) trans. transactions issued from RV hart: checked by PMP
- 7. Taking RISC-V® Mainstream 7 A Platform without an IOPMP transactions issued from DMA: Never check Malicious SW can utilize DMA to access any data. mem controller RV hart PMP SRAM/ ROM eFuse General DMA non-RV core off-chip storage trans.
- 8. Taking RISC-V® Mainstream 8 A Platform with an IOPMP transactions issued from other masters: checked IOPMP mem controller RV hart PMP SRAM/ ROM eFuse General DMA non-RV core off-chip storage trans. IOPMP IOPMP
- 9. Taking RISC-V® Mainstream 9 What is an IOPMP?
- 10. Taking RISC-V® Mainstream 10 PMP and IOPMP • PMP: check the transactions issued from RISC-V harts • IOPMP: check the transactions issued by other bus maters or by another subsystem • Similarity: both are ordered rule-based checkers • Status: PMP is ratified while IOPMP is still ongoing
- 11. Taking RISC-V® Mainstream 11 Our Enhancement and Modification • What we modify to the current IOPMP proposals: – Skip checked transactions (especially checked by PMP) – Provide flexible methods to respond to an illegal access, e.g. forged data, a bus error, or an interrupt. – Optionally support speculative accesses. – Support up to 65,536 entries by using page and page index. – Support up to 16,384 bus masters, by modifying the encoding scheme. – Support “all bus masters” option, easer to block out all accesses. – Suggest methods to integrate with existing subsystems or nested subsystems. • IOPMP: refers to the proposed enhancement for the rest talk
- 12. Taking RISC-V® Mainstream 12 MID of Bus Masters • Master ID (MID): uniquely identify – a bus master, or – a group of masters with the same permission. • Be fixed before entering REE, if it is configurable. • Multi-channel DMA: one permission an MID • Multi-privilege DMA: one privilege an MID • MID=0 implies a trusted master. – A RISC-V core with a well-configured PMP. (more detail later)
- 13. Taking RISC-V® Mainstream 13 MID of a Transaction • Every transaction carries an MID, initialized to the MID of the master issuing the transaction. • The MID is changed to zero or even omitted after the transaction passes a checker. • Such a transaction bypasses subsequent IOPMPs’ checking.
- 14. Taking RISC-V® Mainstream 14 MID Examples mem controller Regulated RISC-V core SRAM/ ROM peripherals 2-ch DMA Other bus master (unregulated core or device w/ DMA) off-chip storage PMP MID=0 MID!=0 channel no ch0.MID (!=0) ch1.MID (!=0) IOPMP IOPMP
- 15. Taking RISC-V® Mainstream 15 MID Modification Rules • While a transaction passes a regulated checker, depicted later, its MID can be changed to zero or even be omitted: – Rule-1: MID 0 if the transaction passes 1+ regulated checker. – Rule-2: MID omitted on a bus if every slave port of it is a leaf device, not a bridge connecting to another bus as a master, or another Rule-2 bus, and all possible transactions sent to the bus are legal (e.g. MID=0 or no MID).
- 16. Taking RISC-V® Mainstream 16 Example of MID Modification Rules a bus WITHOUT MID a bus with MID RISC-V PMP MID=0 Bus Master MID!=0 IOPMP device device device device IOPMP RISC-V PMP IOPMP Bus Master MID!=0 no MID by R1 by R2 by R2 no MID no MID no MID
- 17. Taking RISC-V® Mainstream 17 MID[3:0] MID Encoding in IOPMP Entry • An MID uses up to 14 bits, or 16,384 MIDs. • An IOPMP entry contains up to 16 MIDs, by “MID.h” and “MID.l”. MID[13:0] MID.h[9:0] MID.l[15:0] == && Does the entry contain the MID? MID[13:4] Lower 4 bits uses bitmap encoding Upper 10 bits uses binary encoding
- 18. Taking RISC-V® Mainstream 18 Secure Boot • Secure boot plays an important role in a secure platform. • Basically initialize and lock: PMP, IOPMP, and MID – MIDs (if applicable) – Private regions for each master and each mode • e.g. keys, random seed, device id, private data, Monitor space, anti- rollback counter, IOPMP control registers and other peripherals’ control registers... – NX and prohibited regions for each master and mode • prevent Security Monitor from unintentionally executing malicious code • Bring up the Security Monitor that makes the runtime environment secured.
- 19. Taking RISC-V® Mainstream 19 Regulated Checkers • Initialized to provide Security Monitor and sensitive data a baseline protection. It should – prevent U/S-mode from accessing, – prevent Monitor from unintentionally executing unwanted codes, – prevent DMA from accessing unwanted space, – prevent non-Monitor from controlling IOPMPs, and – protect sensitive data even when Monitor is compromised.
- 20. Taking RISC-V® Mainstream 20 Regulated Checker • A PMP is a regulated checker if – It is initialized according to the previous requirements (P19), and – The initialization is performed during the secure boot. • A IOPMP is a regulated checker if – It is initialized according to the previous requirements, – All possible transactions to control the IOPMP are regulated. A transaction passing all regulated checkers on its way is regulated.
- 21. Taking RISC-V® Mainstream 21 Secure Platforms and IOPMPs • All possible transactions are regulated. • IOPMP can be placed close to masters or close to devices. IOPMP-1 mem controller RV-core PMP SRAM/ ROM IOPMP-2 eFuse Crypto engine NIC w/ DMA off-chip storage IOPMP-1 mem controller RV-core PMP SRAM/ ROM IOPMP-2 eFuse Crypto engine NIC w/ DMA off-chip storage close to devices close to masters
- 22. Taking RISC-V® Mainstream 22 An Example of Root-of-Trust
- 23. Taking RISC-V® Mainstream 23 An Example Root-of-Trust Utilizing PMP, IOPMP, and Secure Boot high-speed bus MMIO bus (arrow: bus cmd direction) mem controller RV hart PMP SRAM/ ROM eFuse Crypto Engine NIC w/ DMA off-chip storage K.B. Key ARcnt eFuse: store sensitive data • Keys: to encrypt and decrypt for networks or off-chip storages • ARcnt: an anti-rollback counter for updatable firmware Crypto engine: encryption & decryption • Direct memory access: cipher and plain text • Key buffer (K.B.): store cipher keys IOPMP-2 IOPMP-1
- 24. Taking RISC-V® Mainstream 24 A Root-of-Trust: ZSBL • Boot ROM: ZSBL (Zero Stage Boot Loader) • Any access from ZSBL is allowed. – Set some MIDs if they are configurable. – Copy Keys from eFuse into the Key buffer. – Perform keys update if applicable. – Verify and/or select an FSBL (First Stage Boot Loader) from off-chip storage, and update ARcnt if necessary. mem controller RV hart PMP SRAM/ ROM eFuse Crypto Engine non-RV core off-chip storage K.B. Key ARcnt IOPMP-2 IOPMP-1
- 25. Taking RISC-V® Mainstream 25 A Root-of-Trust: ZSBL to FSBL • Set and lock these rules in highest priority – eFuse: no access (PMP+IOPMP2) – Key buffer: no access (PMP+IOPMP2) – Control registers of Crypto engine: • PMP: M-mode only • IOPMP2: no one else but MID=0 • Jump to selected FSBL • Do system initialization. • Set more MIDs if necessary. • Verify and/or select one Security Monitor. • Load the Security Monitor into protected memory. mem controller RV hart PMP SRAM/ ROM eFuse Crypto Engine non-RV core off-chip storage K.B. Key ARcnt IOPMP-2 IOPMP-1
- 26. Taking RISC-V® Mainstream 26 A Root-of-Trust: FSBL • Set and lock more rules. Example: • Monitor region: – PMP for code and data: M-mode only – IOPMP-1 for code: no one else but MID=0 – IOPMP-1 for crypto buffer: Crypto engine only • DMA buffers: used by S/U-mode – PMP: NX for M-mode – IOPMP-1: the only place DMAs can access • Non-Monitor region: – PMP: NX M-mode – MID control registers: non-writable – IOPMP control registers: • PMP: M-mode only • IOPMP-2: no one else but MID=0 mem controller RV hart PMP SRAM/ ROM eFuse Crypto Engine non-RV core off-chip storage K.B. Key ARcnt IOPMP-2 IOPMP-1
- 27. Taking RISC-V® Mainstream 27 A Root-of-Trust: FSBL to Monitor • Finally, jump to Security Monitor! mem controller RV hart PMP SRAM/ ROM eFuse Crypto Engine non-RV core off-chip storage K.B. Key ARcnt IOPMP-2 IOPMP-1
- 28. Taking RISC-V® Mainstream 28 A Brief of AndeSentry™
- 29. Taking RISC-V® Mainstream 29 AndeSentry™ • An Open Framework: Threat mitigation: from cyber attacks to physical attacks – Flexible • Selectable components for different kind of requirements • Robustness driven, power driven, cost driven, and so on – Scalable • Systems built by single MCU, multi-core, or even sub-systems. – Trustable • Andes with over 15-year experience in the processor industry • Partners: strong domain know-how, and rich experience in the certification
- 30. Taking RISC-V® Mainstream 30 AndeSentry™ Security Framework AndeSentry™ Security Solution Trusted Execution Environment: Secure boot Security monitor Root-of-Trust Secure Interruption Physical Attack Mitigation: Side-channel mitigation Fault-injection protection Secure debugger Secure storage Security element Runtime Protection: Stack under/overflow protection ROP protection Code modification protection Control flow hijack protection Crypto Acceleration: Hardware crypto engine Crypto-efficiency ISA Security element
- 31. Taking RISC-V® Mainstream 31 AndeSentry™ Components PMP TRNG Root-of-Trust Security element Crypto-efficiency ISA Crypto engine Secure debug IOPMP Secure Storages off-chip on-chip Crypto Library Security Monitor REE OS TEE OS REE Apps TEE Apps M-mode U-mode and/or S-mode HW SW • • • • • • • • • • • • CRTL flow hijack protection Code protection ROT protection Fault injection protection Stack protection and many more...
- 32. Taking RISC-V® Mainstream 32 Andes Security Partners and Ecosystem
- 33. THANK YOU Insert the Subtitle of Your Presentation