RISC-V处理器的安全挑战——浅析体系结构漏洞与攻击风险

背景

2010年夏,加州伯克利大学诞生了一种全新的开源指令集——RISC-V,为芯片领域点燃了星星之火。

而后十年间,RISC-V架构设计以星火燎原之势在学界业界遍地开花。

例如各种基于RISC-V架构的CPU、DSA芯片设计:阿里平头哥的Xuantie 系列处理器、伯克利的SonicBoom/Rocket-chip处理器、MIT的riscy-OOO系列处理器等等。

可以说RISC-V架构打破了x86、Arm、Power等架构的垄断,以更加先进的理念需求孕育着下一代的信息技术发展机遇。在最近的嵌入式世界展览会上,RISC-V基金会的首席执行官Calista Redmond表示:“估计市场上有100亿个RISC-V核”。

树欲静而风不止,RISC-V在大数据、5G、物联网、VR、边缘计算等一众前沿技术领域落地生根的时候,指令集的完备性、虚拟化设计、RAS扩展、安全架构等问题在不同应用实现中初露端倪。特别是安全领域的发展,如何确保一个基于RISC-V架构的SoC安全,成为RISC-V架构开发者们关注的焦点。

本文章针对RISC-V处理器的安全结构进行简析,从缓存侧信道攻击、内存攻击等几个方向介绍目前的系统结构漏洞,在RISC-V核SonicBoom上进行POC的板载测试,验证RISC-V处理器的安全特性。

缓存侧信道攻击

侧信道是被广泛使用的一种信息窃取手段,攻击者并不直接攻击算法可能存在的理论缺陷,而是通过时间测量、功耗测量甚至是侦听声电信号从系统的物理渠道获得机密数据,人们对传统侧信道攻击的软硬件防御方案研究已有逾20年的历史。

然而,随着多核超标量处理器的快速发展,针对处理器系统的侧信道攻击不断诞生新的变体

2017年以来,多个研究团队独立报道了“幽灵(Spectre)”和“熔断(Meltdown)”漏洞及它们的衍生变体,它们各自利用处理器微架构级的分支预测、乱序执行等高性能技术,以瞬态指令流的执行绕过软硬件安全检查、窃取用户信息或越级访问高权限数据,引起了学界和业界的广泛关注。这些攻击展现了现代处理器微架构设计思路的缺陷,进而暴露出一些核心的安全隐患。

基于瞬态指令流的缓存侧信道攻击安全分析

瞬态指令流(Transient Instrcution),指处于推测执行状态下尚不确定最后能否退休的指令。例如分支预测技术使得处理器可以在分支解析前选择某个代码段进行推测执行,则推测执行状态下的指令可被称为一段瞬态指令流。

如果后来的分支解析结果表明预测正确,则瞬态指令流最终可以正常退休。但如果发现预测错误,则流水线应当回滚到这些瞬态指令执行前的状态。理论上,被回滚的瞬态指令不应当对微架构造成任何可被观测的影响,否则这些本不应该被执行的指令在处理器中留下的痕迹就可能造成信息泄露。

但遗憾的是,处理器很难彻底消除瞬态指令流的执行痕迹,一个典型的例子是:在瞬态指令流中被执行的内存加载指令如果将一个数据带入了缓存,则即使流水线回滚期间处理器丢弃了该指令返回的访存结果,已经被修改的缓存状态却无法撤销。由此,攻击者可以通过监测缓存的变化来推断受害者程序的访存地址,如果该地址本身包含敏感信息,就会引发信息泄露。上述过程即构成了一类基于瞬态指令流的缓存侧信道攻击。

与传统的侧信道攻击不同,基于瞬态指令流的侧信道攻击利用硬件微架构级普遍存在的安全缺陷完成敏感信息窃取,这种攻击是无法彻底通过软件手段进行防御。该类攻击一般具有如下三方面的特点:

  • 影响广泛:绝大多数现代处理器都拥有缓存结构且支持乱序超标量等高性能技术,因此主流厂商的架构设计都受此攻击影响。
  • 防御成本高:该类攻击目前学界业界引入的保护手段都会对整体系统性能等造成较大的影响
  • 硬件依赖:这类攻击的实施依赖于程序的执行环境以及特定的硬件设计,针对不同的微架构可以衍生出不同的攻击方案。

缓存侧信道攻击防御方法

“幽灵”和“熔断”攻击已经引起了学界和业界的广泛关注和研究,此处简要的介绍一些目前学界用于缓存侧信道攻击的防御思路,供参考:

1、在流水线中阻止推测值的传播

基于瞬态指令流的侧信道攻击本质上是处理器内位于错误推测路径上的值被用于后续指令的执行,并最终通过侧信道手段被攻击者获取。

因此,一种直接的解决方案是阻止包含隐私数据的推测值在流水线上传播。实际上业界早期使用lfence类屏障指令的方案也是基于该思路,但单纯地用屏障指令阻断所有后续指令的推测执行性能损失较大。

因此在硬件中更加细粒度地划分和动态标记不安全指令,从而缩小被限制执行的指令范围并降低方案性能损失成为一个重要研究方向,代表性工作包括STT(MICRO’19)、NDA(MICRO’19)、SpectreGuard(DAC‘19)等论文的设计方法。

2、推迟推测性访存指令对缓存状态的修改

该类方案是在缓存架构中引入额外的缓冲区,尚未脱离推测执行的访存指令仅能进入缓冲区而非缓存。如果推测正确,则缓冲区的值进入缓存;反之推测错误,则缓冲区的值被丢弃,从而避免错误推测路径上的访存结果修改缓存状态。代表性工作如InvisiSpec(MICRO’18)、SafeSpec(DAC’19)中的设计方法。

3、在缓存级提供不同安全域间的数据隔离

该方向亦是修改缓存架构以妨碍攻击者对缓存信息的有效测量,但本质是提供攻击者与被攻击者之间的数据隔离。基本方向包括缓存分区(cache partitioning)和缓存地址映射随机化

其中,Intel的CAT(Cache Allocation Technology)技术也在LLC提供了缓存分区的机制(CAT最初是为了解决多核系统noisy neighbor问题引入的),部分研究借鉴或利用了该结构。

4、动态识别侧信道攻击者

缓存侧信道攻击者通常与被攻击者竞争访问某块相同的缓存物理位置,因此会表现出特定的访存模式(pattern),如果硬件可以识别潜在的侧信道攻击访存模式并及时做出警告,则被攻击者就可以采取措施避免数据泄露。例如Cyclone(MICRO ’19)中的设计方法。

缓存侧信道攻击复现

此处以一段Spectre-v1(Bounds Check Bypass)的攻击程序片段为例:

if (idx < array1_sz){
        secret = array1[idx]
        dummy = array2[secret * L1_BLOCK_SZ_BYTES];
}

该攻击针对条件分支指令(例如RISC-V中的bge等指令),攻击流程由以下几个阶段构成:

  • 训练阶段,反复以未越界的数据索引idx执行上述代码段,使得PHT(Pattern History Table)记录分支跳转的方向为执行if内的代码段。由于该阶段idx值始终没有超出数组array1的索引范围,因此不会引发安全问题。

  • 攻击阶段,以一个越界的数组索引idx执行上述代码段。从软件编写者的视角看,由于if条件判断规定了idx值不能超出array1索引范围,此时代码段内的数据访问不应当执行,程序应当是安全的。然而,由于分支预测器已经被训练,硬件仍会推测性地进入代码段执行,并以越界的数组索引idx访问得到内存地址空间某个其他位置的隐私数据secret。在推测执行窗口内,攻击者进而在瞬态指令流中通过secret值构造一个访存地址访问某个辅助数组array2。

  • 处理器恢复阶段,分支预测错误被发现,处理器回滚流水线并丢弃上述指令的访存结果。但是,辅助数组array2中的某个数据已经在攻击阶段被带入了缓存,且该缓存地址与隐私数据secret相关。已经被带入缓存中的内容不会因为流水线回滚而被撤销。

  • 数据重建阶段,攻击者只需要测量数组array2中不同位置数据在缓存中的命中情况,就可以推断上述代码段在攻击阶段访问了array2的什么位置,进而推断secret的具体值,从而完成数据窃取。

可见,上述攻击流程绕过了软件设置的边界检查,在不会抛出任何程序异常的情况下获得了内存地址空间其他位置的隐私数据。

下面在真实处理器上复现该攻击。使用的SoC环境为Chipyard,处理器核为SonicBoom,FPGA使用VCU118或VC707。攻击源码可参考SonicBOOM提供的POC代码https://github.com/riscv-boom/boom-attacks。

被攻击地址存放着:!"ThisIsTheBabyBoomerTest

实际攻击者获得了:!"ThisIsTheBabyBoomerTest

可见,在SonicBoom上成功完成了Spectre-v1的攻击程序复现。

内存数据安全

据MITRE最新统计,2022年TOP25最危险软件漏洞(2022 CWE Top 25 Most Dangerous Software Weaknesses)中有40%的漏洞都是与内存修改/控制相关。近些年C/C++语言已被广泛采用在现代系统编程中,由于C/C++这类语言能对内存系统进行操作的特性,极大的提高程序的运行速度与效率,但也因此引入了许多内存安全问题。目前主流的编译器以及runtime对C/C++程序指针不会做静态或者动态的安全检查,最终的结果是使用C/C++编程的程序很容易受到攻击者的攻击。

根据非法指针访问的类型,内存安全主要分为两大类:空间内存安全和时间内存安全(spatial safety & temporal safety)。

  • 空间安全违例:当指针访问对象是该程序范围外的内容,内存空间安全就会受到侵犯。最常见的例子就是利用堆栈上的缓冲区溢出,使用攻击者设计好的值覆盖函数的返回地址,引导程序的执行流方向;或者直接利用溢出改写重要变量或重要信息。

  • 时间安全违例:当对对象的引用在规定时间范围外使用,内存时间安全就会受到侵犯,通常是在实例化对象的内存被重新分配之后,未进行严格的内存初始化例如,由于对指向无效(通常是未分配或释放的)内存的指针进行解引用而导致的时间安全违规(Use After Free)。

内存安全进一步可细分为

  • 缓冲区溢出(Buffer overflow)、
  • 重复释放(Double free)、
  • 解引用空指针(Null pointer dereferencing)、
  • 错误释放(Invalid free)、
  • 访问未初始化内存(Reading uninitialized memory)、
  • 释放后使用(Use after free)等几个小类。

内存漏洞攻击主要分为三个阶段

  • 代码植入:将攻击代码(shellcode)植入到目标程序中;

  • 溢出攻击:通过输入特殊的字符串作为参数来达到缓冲区溢出,而且溢出后的返回地址指向攻击代码的起始地址;

  • 系统劫持:通过运行攻击代码劫持并且控制系统;

内存安全软件保护技术

在了解内存漏洞攻击以及各种内存漏洞后,我们来介绍一下现有的软件保护技术:

较为典型的就是数据执行保护(DEP)机制其基本原理就是将数据所在内存页标识为不可执行,当程序溢出成功转入shellcode时,程序会尝试在数据页面上执行指令,此时CPU就会抛出异常,而不是去执行恶意指令。通过启用DEP,可以有效阻止数据页(如默认的堆页、各种堆栈页以及内存池页)执行代码。

ASLR(Address Space Layout Randomization)技术就是通过加载程序的时候不再使用固定的基址加载,从而干扰shellcode定位的一种保护机制。包括映像随机化、堆栈随机化以及PEB(Process Environment Block,进程环境块))和TEB(Thread Environment Block,线程环境块)的随机化

另一种有效的防御机制是Stack Canary机制,其原理为在函数执行时向栈底插入cookie信息,当函数返回时会验证cookie信息是否合法,若不合法就会停止程序运行。

通过虚拟内存系统实现的ASLR机制、DEP(NX/XD)或者Stack Canary机制都使得攻击者不再能够随意的注入和执行任意的攻击代码,因此这些预防机制在一定程度上保护了程序的安全运行。

但是面对更加复杂的攻击代码以及手段,这些保护机制就会面临着失效的结果。例如在面向返回的编程(ROP)中,通过破坏代码指针(如返回地址)和将多个gadget的执行链接在一起来实现任意代码执行。这些原始二进制代码中的序列被组合起来实现攻击者设想的恶意攻击代码。

除了在原有的编程语言上添加一些软件保护技术之外,近几年还有许多针对安全的编程语言涌现。例如Rust语言,以在保证高安全性的同时,获得不输C/C++的性能的特点获得了大量的关注,为此本文简单介绍一下安全语言Rust。

安全

Rust推崇安全与速度至上,它没有垃圾回收机制,却成功实现了内存安全 (memory safety)。Rust 与 C 和 C++ 的区别在于其强大的安全保障。

除非通过使用“unsafe”关键字明确选择使用,否则Rust完全是内存安全的。

Rust的核心设计是通过编译时检查强制执行的一套严格的安全规则。为了支持更多的低级控件,Rust允许程序员绕过这些编译器检查来编写不安全的代码。MSRC (Microsoft Security Response Center) 提供的CVE中大约70%的安全问题是内存安全问题。 他们认为目前发现产生安全问题的程序如果是用 Rust 编写,那么70%的内存安全问题将不复存在。

在ACM SIGPLAN国际会议(PLDI’20)上的一篇研究论文指出“Rust语言的safe代码机制能非常有效的避免内存安全问题,所有稳定版本中发现的内存安全问题都和unsafe代码有关”

性能

如果想用Rust替换C或者C++作为主流编程语言,那必须要考虑的是该编程语言的性能以及控制能力。

Rust同样拥有可配置的runtime,以及Rust 的标准库依赖于 libc 来支持它的平台,就像 C 和 C++ 语言那样,并且Rust标准库也是可选的,Rust编译的程序在没有操作系统的平台上也是可以运行的。

内存安全硬件保护技术

此处简要的介绍一些目前学界用于内存安全硬件保护技术思路,供参考:

1.Tripwire-Based Mitigation

这类方案主要是在分配的内存块之间放置redzone,当指针访问redzone区域的时候就会爆出相应的错误。典型例子就是Google’s AddressSanitizer (ATC’12)、Valgrind’s memory checker(PLDI‘07)。

Tripwire的创新点在于,它们在内存入侵时立即被激活——依靠影子内存进行检查,而不像金丝雀(Stack Canary)等软件措施依靠软件进行显式地检查。

尽管Tripwire提供了强大的安全保障,但是会带来令人望而却步的高性能开销,因此不适合部署在性能敏感的设备中。下图是REST(ISCA‘18)的行为流程图。REST只是嵌入到程序中的一个非常大的随机值,其将redzone检测硬件化——由令牌代替redzone以此来消除对影子mem的依赖,load/store指令都会检测该地址区域是否被隔离。

2. Fat Pointers

除了Tripwire机制,胖指针也是业内比较热门的一个方向,主要是将维护对象的metadata——一般指对象的base、bounds等插入指针内与指针地址一起索引,一般会通过静态编译的时候的检查以及Runtime时候的动态插桩等进行内存安全保护。

Hardbound(SOSP’08)通过加上影子空间用于存储指针权限,是指针指向的地址为base 加上size作为整个bound区间、Softbound(PLDI’09)、Watchdog(ISCA’12)看门狗为每个内存分配生成一个唯一的标识符,将这些标识符与指针关联起来,并检查以确保该标识符在每次内存访问中,为了提供全面的检测,Watchdog几乎完全在硬件上使用基于标识符的检测。下图是HardBound设计概述图,具体含义可参考论文,本文不展开叙述。

3. Capability

Capability与Fat pointer有一定的相似程度,他们都是通过在指针上添加metadata进行保护,但是Capability与Fat pointer的区别在于它是无法被修改的Fat pointer,每个capability只能被创造、转移(子模块引用)以及被删除。每个指针的读写执行等权限也被附加到指针上。指针不再只有一个索引的作用,更像一个带有权限检索的“对象”。

同样有一些基于capability的硬件实现,代表性设计就是 CHERI(ISCA‘14, Capability Hardware Enhanced RISC Instructions)。通过metadata(边界和权限)与地址内联维护,从而通过交换区域、存储和内存带宽来消除昂贵的影子表查找。下述简要说明一下CHERI设计的一些优势:

  • 提出了CHERI的抽象保护模型,分别在64bit MIPS、32/64bit RISC-V、 64bit ARMv8-A ISA中应用实现
  • 拥有正式的ISA模型,支持Qemu-CHERI仿真,以及多个FPGA原型
  • 通过软件验证ISA安全模型是成立的
  • 众多软件配套系统:CHERI Clang/LLVM/LLD、CHERI BSD、 C/C++ APP
  • Morello:CHERI ISA 架构的工业级演示板、是目前CHERI原型架构的唯一物理实现

控制流完整性

控制流劫持攻击通过构造特定攻击载体,利用内存溢出等软件漏洞,非法篡改进程中的控制数据,从而改变进程的控制流程并执行预先构造的攻击程序,达到攻击目的。一次成功的缓冲区溢出攻击可以作为修改计算机系统运行控制流的有效前提,例如可以修改程序的返回地址、调用函数的EBP或者修改函数指针以及GOT表等等,从而将程序引向攻击者预设的攻击程序,以此执行恶意代码造成整个程序的崩坏,又或者让攻击者获取部分系统的控制权,造成整个计算机系统的安全危机。因此,对于缓冲区溢出攻击的防御具有极其重要的现实意义。

W⊕X类防御手段有效阻止了攻击者们在正常程序中执行植入的恶意程序,但是攻击者们发现,他们仍然通过可以操控程序控制流,将程序原有的可执行代码重用于恶意目的,这就是代码重用攻击。最初的代码重用攻击为Return-to-libc攻击,由于系统的libc库通常包含用于执行系统调用和其他可能对攻击者有用的功能的子例程,因此它们最有可能被寻找代码来组装攻击。

在Return-to-libc攻击中,攻击者通过利用缓冲区溢出漏洞来劫持程序控制流,选择一个可用的库函数并用其入口位置覆盖返回地址,再通过精细的堆栈位置覆盖,将设计好的参数传递给函数,完成攻击。

ROP攻击

Return-to-libc攻击绕过了W⊕X防御手段,但是其缺点也很明显:其可以执行的攻击程序灵活度不足,且容易被针对性防御,于是ROP应运而生。

ROP (Return-Oriented Programming,面向返回的编程)允许攻击者在存在安全防御(例如可执行空间保护和代码签名)的情况下执行代码。在这种技术中,攻击者可以控制调用堆栈来劫持程序控制流,然后执行精心挑选的机器指令序列,这些机器指令序列已经存在于机器的内存中,称为“小工具”(gadget)。

每个小工具通常以返回指令(ret)结束,并位于现有程序和/或共享库代码内的子例程中。这些小工具链接在一起,允许攻击者在采用防御措施的机器上执行任意操作。

ROP仍旧以返回地址和参数覆盖堆栈,但是攻击者提供的返回地址可以指向代码库中的任意点,确切地说是以ret指令结尾的任意代码片段(gadgets)。


即使现有的可用库函数完全无法利用,ROP仍可以采用拼凑的方法组合完整攻击程序,尤其是x86架构的指令集非常密集,几乎任何随机字节序列都可能被解释为一些有效的x86指令集。

ROP攻击重点————寻找一组满足如下要求的gadgets:

  • 必须以ret结尾
  • 不会显式地改变堆栈指针
  • 具有算术功能和逻辑功能等基础功能
  • 具有访存和系统调用等复杂功能
  • 具有条件分支和循环功能(通过逻辑修改esp值)
  • 只要能在可执行程序中找到一组满足以上条件的gadgets,就变相地生成了一个图灵完备的面向返回的机器

针对ROP的许多防御措施:

  • DynIMA(Dynamic Integrity Measurement and Attestation,动态完整性度量)——检测每个以ret结尾的连续执行的指令序列
  • DROP(Detecting ROP Malicious Code,检测面向返回的编程恶意代码)——检测栈中弹出的始终指向特定内存空间的返回地址
  • “Return-less”Kernels——一种编译器级优化,消除了程序中所有ret指令,使攻击者无法再使用ROP攻击
  • ……

JOP攻击

ROP攻击固然强大,但是依赖堆栈和ret指令劫持控制流也是它的劣势所在。在此基础上,攻击者们提出了JOP/COP攻击方式。

JOP/COP (Jump/Call-Oriented Programming,面向跳转/调用的编程)放弃了对栈的控制流和小工具发现和链接的所有依赖,而只是使用一系列间接跳转指令,这就完全绕过了所有针对ROP的防御。

ROP中,一个面向跳转的程序由一组小工具地址和加载到内存中的数据值组成,小工具地址类似于一个新的面向跳转机器中的操作码。在ROP中,这些数据存储在堆栈中,因此堆栈指针在面向返回的程序中充当“程序计数器”。


JOP并不局限于使用esp来引用它的小工具地址,控制流也不是由ret指令驱动的。相反,JOP使用一个分派表(dispatch table)来保存小部件地址和数据。


“程序计数器”是指向分派表的任何寄存器。控制流由执行gadget序列的特殊调度程序gadget驱动。在每次调用时,调度程序推进虚拟程序计数器,并启动相关的小部件。小工具执行结束时,返回dispatcher。


上方是一个面向跳转的程序示例,跳转的顺序由数字1->6表示。在这里,edx被用作pc, dispatcher通过简单地添加4来进入一个连续的小工具地址表中的下一个地址(因此f(pc) = pc + 4)。“攻击”函数将

  • 解引用eax
  • 将地址ebx的值加到eax
  • 将结果存储在地址ecx
    寄存器esi和edi被用来将控制返回给调度程序

防御手段

控制流执行技术(Control-flow Enforcement Technology,CET)是英特尔提出的一项专门针对ROP/COP/JOP等高级堆栈溢出的指令集扩展。其主要分为以下两个方面:

  • a .Shadow Stack(SS,影子堆栈),是一种主要针对ROP的防御手段,目标是保护栈的返回地址。该防御措施创建了独立于程序数据堆栈的第二个堆栈,当启用阴影堆栈时,CALL指令将返回地址推送到数据和阴影堆栈上。
  • b. Indirect Branch Tracking(IBT,间接分支跟踪),是一种主要针对COP/JOP的防御手段。方法为添加ENDBRANCH新指令,用于标识程序中间接调用和跳转的有效目标地址。其操作码对于不兼容该指令的旧架构表示为NOP,不会妨碍程序运行。对于支持CET的处理器,其操作码仍为NOP,不会带来额外的硬件负担。

    针对控制流完整性攻击,ARM公司提供了两种防御方案:BTI、PAC:
    a. Pointer Authentication Code(PAC,指针认证代码):ARMV8.3-A指令集中加入了指针认证(PA)机制,在使用寄存器的值作为指针访问数据或代码之前验证其内容,目的是为了对抗ROP攻击。机制的基本原理是利用特殊指令根据一个64位的上下文、指针的原始值和一个128位的密钥通过一个加密算法的运算之后得到一个64位的密文,对其进行截断之后作为PAC,在使用该指针之前利用特殊指令对指针值进行验证,验证通过之后将指针的高位恢复原状,否则在指针高位填入错误代码,在寻址阶段会触发异常。
  • b. Branch Target Identification(BTI,分支目标识别):BTI是Armv8.5增加的限制攻击的安全特性,主要用于防御JOP(jump-oriented programming)攻击方式。工作原理是处理器在编译时会为BR或BLR指令配置一个BTI指令,即为间接跳转指令设定指定的跳转目标(英文中使用了一个非常贴切的词,landing pads,着陆点)。如果间接跳转的目标不是指定的着陆点,就会产生一个跳转目标异常。着陆点的使用限制了间接跳转可能的目标数量,从而使得将gadgets串联在一起形成新程序变得困难。

内存攻击复现

此处以一段Buffer-Overflow的攻击程序片段为例:

void shellcode() {
  .......
}
int main(int argc, char *argv[]) {
  char buf[8];
  if(argc < 2) {
    printf("Pass an argument, champ!\n");
  }
  strcpy(buf,argv[1]);
  printf(buf);
}
  • 第一阶段代码植入:将攻击代码(shellcode)植入到目标程序中;

  • 第二阶段溢出攻击:通过输入特殊的字符串作为参数来达到缓冲区溢出,而且溢出后的返回地址指向攻击代码的起始地址(shellcode起始地址);

  • 第三阶段系统劫持:通过运行攻击代码劫持并且控制系统;

SoC环境为Chipyard,处理器核为SonicBoom,FPGA使用VCU118/VC707

这是一段栈溢出攻击程序输出结果示例,GDB调试找到程序RA(return address)所在的地址,通过栈溢出进行覆盖,使程序跳转到既定的攻击程序,最后的结果就是输出You win!以及改变了程序的shell。

Arm安全框架——RISC-V安全设计的重要参照系

针对上述安全威胁,RISC-V领域已经有不少开发者形成了自己的处理方案,但这些安全处理对策目前并没有被标准化。Arm架构具有高度标准化的安全对策,可以通过借鉴学习Arm安全架构,为未来RISC-V的安全扩展方向提供思路,这里主要介绍常4类安全对策:

  • Defensive Execution Technologies:这是一类针对控制流攻击、数据访问攻击以及侧信道攻击的保护技术。软件很少是完美的,可以人为的通过一些防御性的编程对一些程序漏洞进行修复,但这种方式未必适用于所有的代码程序。目前解决此类安全问题主要是通过修改硬件、编译器以及Runtime这三个技术手段进行保护。这一类内容将在后文进行详细阐述,此处不展开说明。
  • Isolation Technologies:定义明确的安全边界,是安全工程最基本的原则之一。该安全防御主要针对TEE设计的一类防御隔离技术,比较具有代表性的产品有Arm TrustZone、Intel SGX、Apple Secure Enclave、蓬莱Enclave、 Keystone Enclave等。
  • Common Platform Security Services:为了安全起见,所有装置都需要信任根(RoT),并依据安全性需求的广泛检查清单进行验证。如果没有使用可公开取得的框架,市场就无法判定产品是否对攻击具备适当的抵抗能力。
  • Standard Security API: 随着计算机科学技术高速发展,越来越多的客户通过使用开发者定制的API接口进行各种微服务的迭代开发。为此,API接口既能够连接服务的功能,又可以进行数据传输,API的安全保护愈发的重要起来。目前已经出现了多起因为API被攻击或者存在漏洞而出现的数据泄漏的事故,例如2018年国内发生的华住信息泄露事件导致大量的用户个人信息被泄露,以及2019年Instagram因API接口漏洞导致用户数据以及照片被泄露。
    如何在RISC-V生态链上建立一个完整有效的计算安全架构、减少技术设计碎片化,是目前RISC-V生态发展中极具挑战且迫切的需求。

机遇与挑战

随着5G技术的普及,真正的万物互联时代将到来,层出不穷的漏洞散发着越来越广泛的影响。现有的安全防护短板效应会进一步放大。在万物皆可被攻击的环境里,各种薄弱环节将成为攻击者的首选目标。纵观X86、Arm、MIPS等架构的发展,芯片的安全性总是在架构初期设计的时候“脱节”,在设计周期的后期再加上一个个“补丁”,那RISC-V架构是否能提早部署,建立安全的“护城河”呢?业界学界已经通过各种实例(高性能处理器、高效的加速器等)证明了开源指令集RISC-V的高效便捷性,但是目前RISC-V领域内的安全扩展仍然在积极推进中。随着越来越多的RISC-V芯片运用于关键性的任务系统上,如何在安全方法以及安全开发的生命周期中注入更多的思考与策略,如何从单点防护扩展到系统化全局防护体系建设,是对架构开发者的一个全新挑战。

猜你喜欢

转载自blog.csdn.net/weixin_45264425/article/details/132698911