当前位置:首页 > 报告详情

13-d3s2-6-RISCV_Debug_Security_China_Summit_Final.pdf

上传人: 张** 编号:155450 2024-02-15 34页 2.07MB

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(

word格式文档无特别注明外均可编辑修改,预览文件经过压缩,下载原文更清晰!
三个皮匠报告文库所有资源均是客户上传分享,仅供网友学习交流,未经上传用户书面授权,请勿作商用。
本文主要讨论了RISC-V架构中的外部调试安全问题。文章指出,现有的外部调试机制在多域安全模型中存在问题,例如,一旦启用外部调试器,无论目标权限如何,外部调试器都会获得最高优先级。这可能导致安全问题,例如,非安全域的开发者使用调试器调试非安全域的软件时,可能破坏高安全域的数据。 文章还比较了RISC-V和ARM架构在调试安全方面的差异。ARM架构提供了更丰富的机制来保护安全数据免受调试器的访问。 为了解决这些问题,文章提出了一种安全调试扩展方案。该方案建议根据权限级别监管调试访问,以确保较低权限级别的调试访问不能干扰较高权限级别的执行,同时,外部调试器的访问应根据权限级别进行调节。文章还提出,可以通过硬件熔断和粘性旋钮来管理调试控制,例如,在第一阶段,可以通过生命周期熔断来确定mdbgsec的默认值,在第二阶段,可以通过配置mdbgsec来启用调试,在第三阶段,可以通过编程粘性旋钮来禁用机器模式调试。 总的来说,文章呼吁RISC-V安全社区认可这些问题,并共同努力解决这些问题。
如何应对外部调试器威胁?" RISC-V如何改进外部调试安全?" 如何保护RISC-V处理器中的高安全域?"
客服
商务合作
小程序
服务号
折叠