1、Joe Xie,Aote Jin nVidiaRISCV DEBUG SECURITY2 The issueThe(draft)proposalAgendaThe issue4 Multi-Domain Security ModelM-mode MonitorRTOSAppRich OSManagementFirmwareAppM-modeS-modeU-modePMPMMUAppAppNon-trusted DomainTrusted DomainManagement DomainRoot DomainRISC-V SECURITY MODEL5 RISC-V EXTERNAL DEBUG

2、OVERVIEW6 RISC-V DEBUG SECURITYAll-or-nothing,controlled via fuse or authdata and authenticatedOnce enabled,external debugger has highest priority regardless of target privilege7 WHATS THE ISSUE?M-mode FirmwareNon-SecureDomainHigh-SecureDomainM-modeS-modePMPDebugModuleDMI/DTMOnce enabled,external de

3、bugger has highest privilege regardless of target privilegeA non-secure FW developer who can use debugger to debug non-secure FW can compromise high-secure FW and M-mode monitorProgram bufferDebugmode8 WHY THIS IS A PROBLEM?Modern SOC software development consists of multiple actors,they all need ex

4、ternal debug One actor wants to protect its confidential data from another actor(Silicon creator considers Silicon owner as adversary)Silicon CreatorSilicon OwnerAppProviderSOCSystemSource-Project OpenTitanDisable debug for best security!I need to debug my software!9 WHY THIS IS A PROBLEM?M-mode Mon

5、itorRTOSAppRich OSManagementFirmwareAppM-modeS-modeU-modePMPMMUAppAppTheres strong requirement to protect high security domains data even within one actor,to reduce TCBIn this example we want to protect management domain or M-mode monitor from low security domain(RTOS)when using external debugger to

6、 debug RTOSDisable Debug!Enable Debug!10 EXAMPLEOEM attack SOC vendorM-mode monitorOEM Code/DataSOC VendorCode/DataM-modeS-modePMPDebugModuleDMI/DTMAdversary OEM(or SOC vendor)Asset SOC vendor(or OEM)code/dataThe attack SOC vendor code/data shall be confidential to OEM and vice versa.However,an OEM(

7、or SOC vendor)developer who has debug access to OEM code can break PMP protection and steal SOC vendor(or OEM)confidential code/data11 EXAMPLEROM DumpDebugModuleDMI/DTMHart#1M-modePMP.L=1Hart#2M-modeBRFW Code/DataPMP.L=1Debugmemory accessAdversary Firmware developerAsset ROM codeThe attack Boot ROM

8、code shall be confidential to firmware developer.A firmware developer who has external debug access can bypass PMP.L protection to read ROM content,assuming BR protection relies on PMP.LDebug modeDebug modebypass PMP.Lvia relaxedpriv12 EXAMPLEM-mode monitorCodec FWDRM Service FWM-modeS-modePMPDebugM

9、oduleDMI/DTMAdversary Non-secure code developerAsset Class keys(e.g.hdcp master key)The attack Class key shall be confidential to non-secure partition.However,an attacker who has debug access to the non-secure partition can steal class key via external debugger10k100k+LOC100+ppl1k LOC5 ppl500 LOC5 p

10、pl13 COMPETITOR ANALYSIS-ARMARMv8 provides rich mechanisms to protect secure data from debugger accessControls secure/non-secure/realm separatelyControls invasive/non-invasive debug separatelyControls external debug and self-hosted debug separatelyControls halting debug events speratelyConsists of b

11、oth hardware or softwareDebug access to memory/register honors target privilege level,hence no privilege escalation14 NVIDIA CONFIDENTIAL.DO NOT DISTRIBUTE.ARM TARGET STATEAn Armv8-A architecture processor or core can have two security states,Secure state and Non-secure state.If the Secure state is

12、implemented,privileged or secret information for the SoC is stored or handled through the Secure state.This means that,after a certain point in the development cycle of an SoC,the hardware or software will lock untrusted users out of the Secure state.This step is taken to prevent access to the prote

13、cted data in the Secure state.This diagram shows hardware or software locking a user out of the Secure state:If you try to connect a debugger to an SoC that uses this operational model,then the debugger will only allow you to connect to the Non-secure state.15 NVIDIA CONFIDENTIAL.DO NOT DISTRIBUTE.A

14、RM TARGET STATESoC designs can lock users out of certain Exception levels either through hardware or software.This locking usually occurs late in the development cycle of the SoC,so that unprivileged users cannot access aspects of the code or SoC design.This diagram shows an SoC in which EL3,which i

15、s usually where the secure monitor and firmware reside,is locked.If you connected a debugger to an SoC that uses this operational model,then you could debug EL2,EL1 and EL0,but not EL3.16 EXTERNAL DEBUG CONTROLDBGEN:Top-level invasive debug enableNIDEN:Non-secure invasive debug enableSPIDEN:Secure i

16、nvasive debug enable,controls external ability to debug in secure stateSPNIDEN:Secure non-invasive debug enable,controls external ability to non-invasive debug in secure stateRLPIDEN:Realm Invasive Debug Enable,controls external ability to debug in realm stateRTPIDEN:Root Invasive Debug Enable,contr

17、ols external ability to debug in root state17 USER MODE DEBUGIndividual components can offer greater control over the permitted level of debugging.For example,some processors implementing Arm Security Extensions can grant permission to debug-specific Secure processes by permitting debugging of Secur

18、e User mode without permitting debugging of Secure privileged modes.Controlled via SDER(Secure Debug Enable Register)18 ACCESSING REGISTER IN DEBUG STATEARM DDI 0487J.a ID042523 a-profile_architecture_reference_manual H2-11113 19 ACCESSING MEMORY IN DEBUG STATEARM DDI 0487J.a ID042523 a-profile_arch

19、itecture_reference_manual H2-11115 20 EXCEPTION IN DEBUG STATEARM DDI 0487J.a ID042523 a-profile_architecture_reference_manual H2-11110The Proposal22 Secure Debug Extension ProposalThe debug accesses shall be regulated according to the its privilege level(assigning a privilege level to debug access)

20、.Less privileged debug accesses cannot peep/interrupt the hart when it runs in higher privilege level(e.g.,S mode debug privilege cannot read/halt the trap handler or context switch in M mode).Less privileged debug accesses cannot tamper resources of higher privileged level(e.g.,S mode debug privile

21、ge level to access M mode CSR or memory granted to M mode by PMP).The debug access can be conditionally enabled.(e.g.,both ROM and Non-ROM can live in M mode,but the debuggability should be granted differently).Memory accesses from System Bus Block shall be regulated by IOPMP or something equivalent

22、.Requirements23Secure Debug ExtensionOverviewDebug policy defines whether external debugger is enabled or disabled for each domain A piece of manifest as input for M-mode firmware Specifies mdbgsec configuration for domains M-mode firmware to enable/disable external debuggeraccess for each domain vi

23、a mdbgsec External Debugger(debug module)access regulated by privilege levels Implementations can extend the control to permanently disable external debug for high secure domains24Secure Debug ExtensionMDBGSEC CSR(fields for debug access control)Add Machine Debug Security Control Register(mdbgsec)Gl

24、obal debug enable knob Controls the maximum privilege levelH ext.supporteddbgen(bit3)dbgv(bit2)dbgprv(bit0-1)Max debug prv modeNo00dont-careExternal debug disabledNo100U mode external debug enabledNo101U/S mode external debug enabledNo103U/S/M mode external debug enabledYes0dont caredont careExterna

25、l debug disabledYes100U mode external debug enabledYes101U/VU/VS/HS mode external debug enabledYes103U/VU/VS/HS/M mode external debug enabledYes110VU mode external debug enabledYes111VS/VU mode external debug enabled25Secure Debug ExtensionDebug module is regulated by privilege level Query the allse

26、cure/anysecure to discover whether the hart is debug-able Halt request behavior changes as the following if debug is enabled in any mode,halt request will be pending till the hart can eventually be halted Dropped silently if not debug-able26Secure Debug ExtensionDebug module access regulated by priv

27、ilege level Abstract commands memory and registers access will be checked as if they are at privilege level specified in dcsr.prv/dcsr.v.Program buffer Instructions will work as if the hart is running at privilege level specified in dcsr.prv/dcsr.v(except ecall/ebreak/xret).Writing dcsr.prv/dcsr.v w

28、ith a value whose corresponding privilege level is disabled for debug will get security fault error27Secure Debug ExtensionExtending the debug control management with hardware fusing and sticky knob Phase 1:Debug ROM A life-cycle fuse to determine default value of mdbgsec All privilege levels are al

29、lowed to debug if the fuse is not burnt Phase 2:Lockdown ROM and debug FMC Burn the fuse to disable debug by default FMC is responsible to enable debug by configuring mdbgsec.FMC waits the external debugger to hook up after enabling debug.28Secure Debug ExtensionManage the debug with hardware fusing

30、 and sticky knob Phase 3:Disable machine mode debug Program the sticky knob in mdbgsec to disable machine mode debug The debug could only be granted to non-machine mode The knob is sticky and cannot be cleared until reset.29Exceptions and InterruptsA case study of stepping over traps The hart will e

31、xit debug mode during step If exception or interrupt occurs and it lands at higher privilege level The step cannot be completed Hart continues execution in high privilege level Re-enter debug mode immediately after returning to debug-able privilege level.30TriggersDebug module is regulated by privil

32、ege level Triggers match/fire to enter debug mode if debug is allowed in mdbgsec Triggers cannot be enabled for unallowed privilege by external debugger.External debugger cannot modify hart owner triggers.31Reset And Power/clock gating Per hart operation:hartreset/resethaltreq will be served only if

33、 the external debugger has M-mode debug privilege,otherwise they will be dropped silently Systemwide operation.:It is recommended that SOC vendors do not implement ndmreset,or use a life-cycle fuse to disable ndmreset.32 ConclusionWe believed the use case and security requirements are general,all RI

34、SC-V SOC vendors will face the same problem sooner or laterIt turns out that the security issues are addressed by competitor(ARM)NVidia team has a draft proposal(here),the proposal is in its early phase and actively discussed in multiple groups(RTI,Debug)We call for RISC-V security community to acknowledge the issues and work together on an extension to fix the issues35 REFERENCEARM Architecture Reference Manual Security Extensions Supplementhttps:/ https:/