RowHammer漏洞是DDR3内存中存在的问题,通过频繁的访问内存中的一行数据,会导致临近行的数据发生反转。然而由于其运行需要在目标主机上大量运行特定的代码,实施攻击存在很大的难度。本文旨在研究能否通过Javascript等脚本语言的动态执行触发RowHammer,如果能够成功将极大增加RowHammer的攻击性。为了验证该思路,本文分析了Java Hotspot、Chrome V8、.NET CoreCLR以及Firefox SpiderMonkey的实现机制并给出了可行性分析。

0x00 前言

  2015年3月Google Project Zero发表文章Exploiting the DRAM rowhammer bug to gain kernel privileges。由于文中提到的缺陷比较难以修复,需要更新BIOS来提高内存刷新的速度,引起了人们的担忧。然而由于RowHammer的运行需要在目标主机上运行特定的汇编代码,实施攻击存在很大的难度。
  本文旨在研究能否通过Javascript等脚本语言的动态执行触发RowHammer,如果能够成功将极大增加RowHammer的攻击性。为了验证该思路,本文分析了Java Hotspot、Chrome V8、.NET CoreCLR以及Firefox SpiderMonkey的实现机制并给出了可行性分析。
  遗憾的是我们在这几个程序中,没有找到最优的利用方式。要么不存在相关的指令,要么指令无法达到RowHammer要求,要么需要有额外的操作更改执行环境才能触发,缺乏实际的攻击意义。

0x01 RowHammer

  本节将简要回顾RowHammer存在的原理,其触发的机制,已经在利用时将面临到的一些挑战。

1.1 What’s RowHammer?

  RowHammer是DDR3内存中存在的问题,通过频繁的访问内存中的一行(row)数据,会导致临近行(row)的数据发生位反转。如图1.1(a)所示,内存是由一系列内存单元构成的二维数组。如图1.1(b)所示每一个内存单元由一个晶体管和一个电容组成,晶体管与wordline相连,电容负责存储数据。DRAM的每一行(row)有自己的wordline,wordline需要置高电压,特定行(row)的数据才能够访问。当某一行的wordline置高电压时,该行的数据就会进入row-buffer。当wordline频繁的充放电时,就可能会导致附近row的存储单元中的电容放电,如果在其被刷新之前,损失过多的电压就会导致内存中的数据发生变化。

  图1.2所示是一块内存,其中一个row为64kb(8KB)大小, 32k个row组成一个Bank, 8个Bank组成一个Rank, 该Rank为2G。此处需要注意不同的Bank有专用的row-buffer,访问不同Bank中的row不会导致wordline的充放电。
内存中的电压是不能长期保存的,需要不停的对其进行刷新,刷新的速度为64ms,所以必须在64ms内完成RowHammer操作。

图1.1
![](/cn/uploads/2016/10/img2.png)
图1.2

1.2 RowHammer触发的方法

  表1.1所示为Google Project Zero所给出的可以触发RowHammer的代码段。

  其中x, y地址的选择非常重要,x, y必须要在同一个Bank,不同的row中。因为不同的Bank有专用的row-buffer。如果x, y 在同一个row中就不会对wordline进行频繁的充放电,也就不会触发RowHammer。

  上述代码只是一种有效的测试方法,但并不是惟一的,归根到底我们所需要的就是在64ms内让一个wordline频繁的充放电。

1.3 触发RowHammer指令

  为了频繁的使wordline充放电,必须考虑CPU的Cache, 如果当前地址在Cache里面就不会访问内存,也就不会导致wordline的充放电情况。
表1.2
| 指令 | 作用 |
| ———– |:——————————–:|
| CLFLUSH | 将数据从Cache中擦除 |
| PREFETCH | 从内存中读取数据并存放在Cache中 |
| MOVNT* | 不经过Cache直接操作数据 |

  表1.2中的指令都可以用来频繁的访问一个内存地址,并使相应的wordline充放电,如果要触发RowHammer, 需要上述指令的配合才能完成。
(注: 这些指令并不是惟一的触发方法,比如通过分析物理地址和L3 Cache的映射关系算法(不同的CPU架构实现可能不同),找到映射到同一个Cache set的一系列地址,通过重复访问这一系列的地址即可触发RowHammer。)

0x02 脚本层面触发RowHammer

  Google Project Zero给出的POC是直接以汇编的方式来运行,可以用来验证内存是否存在安全问题。当前脚本语言大都存在JIT引擎,如果能够通过脚本控制JIT引擎直接
触发RowHammer,将会具有更大的攻击意义。为了分析其可行性,本节研究了Java Hotspot、Chrome V8等执行引擎的运行机制。

2.1 Java Hotspot

  Hotspot是Oracle JDK官方的默认虚拟机,主要用来解释执行Java字节码,其源码位于Openjdk下hotspot目录,可以独立编译。Java字节码是堆栈式指令集,指令数量少,共有256条指令,完成了数据传送、类型转换、程序控制、对象操作、运算和函数调用等功能。Java字节码存储在class文件中,作为Hotspot虚拟机的输入,其在一定程序上是用户可控的。那么能否通过构造class文件,使得Hotspot在执行时完成RowHammer呢?

  Java Hotspot默认对字节码进行解释执行,当某方法被频繁调用,并且达到一定的阈值,即会调用内置的JIT编译器对其进行编译,在下次执行时直接调用编译生成的代码。
  Java字节码解释器有两个实现,分别为模版解释器和C++解释器,Hotspot默认使用模版解释器。Java的JIT编译器有三个实现,分别为客户端编译器(C1编译器)、服务器端编译器(C2 编译器)以及Shark编译器(基于LLVM)的编译器。
图2.1所示为Java在不同平台下使用的虚拟机。

图2.1

2.1.1 模版解释器触发RowHammer?

a) 模版解释器工作原理

  模版解释器是一种比较靠近底层的解释器实现,每一个字节码对应一个模版,所有的模版组合在一起构成一个模板表。每一个模版实质上都是一段汇编代码,在虚拟机创建阶段进行初始化。在执行class文件的时候,遍历字节码,每检测到一个字节码就调用相应的汇编代码块进行执行,从而完成对于字节码的解释执行。
  为了完成对于字节码的解释执行,Hotspot在初始化时还会生成多种汇编代码块,用来辅助字节码的解释,比如函数入口代码块,异常处理代码块等。查看Hotspot中生成的代码块和模版可以采用命令 java –XX:+PrintInterpreter 指令来完成。
  针对各个字节码的模版中汇编代码比较庞大,比如字节码invokevirtual对应的代码块共有352 bytes,字节码putstatic有512 bytes。

b) 解释器能否触发RowHammer?

  字节码在解释执行的时候会产生汇编代码,那么是否可以通过class文件让解释器生成RowHammer需要的指令呢?
通过分析,字节码对应的模版和辅助代码块的指令中没有prefetch, clflush以及movnt*系列指令,所以直接通过构造字节码,然后使用模版解释器来触发RowHammer是不可行的。

2.1.2 JIT编译器触发RowHammer?

a) C1编译器工作原理

  JIT编译器也是一种编译器,只不过其是在程序动态运行过程中在需要的时候对代码进行编译。其编译流程与一般编译器基本相同。
  C1编译器是客户端使用的JIT编译器实现,其主要追求编译的速度,对于代码的优化等要相对保守。
  Hotspot编译器默认是异步编译,有线程CompilerThread负责对特定的方法进行调用,当方法调用次数达到一定阈值时将会调用JIT编译器对方法进行编译,该阈值默认为10000次,可以通过 –XX:+CompileThreshold 参数来设置阈值。

图2.2
  1编译器共包含如下几个步骤
typedef enum {
    _t_compile,
    _t_setup,
    _t_optimizeIR,
    _t_buildIR,
    _t_emit_lir,
    _t_linearScan,
    _t_lirGeneration,
    _t_lir_schedule,
    _t_codeemit,
    _t_codeinstall,
    max_phase_timers
} TimerName;

C1编译器执行流程大致如图2.2所示:

1) 生成HIR (build_hir)
  C1编译器首先分析JVM字节码流,并将其转换成控制流图的形式,控制流图的基本块使用SSA的形式来表示。HIR是一个层级比较高的中间语言表示形式,离机器相关的代码还有一定的距离。
2) 生成LIR (emit_lir)
  遍历控制流图的各个基本块,以及基本块中个各个语句,生成相应的LIR形式,LIR是一个比较接近机器语言的表现形式,但是还不是机器可以理解的代码。
3) 寄存器分配
  LIR中使用的是虚拟寄存器,在该阶段必须为其分配真实可用的寄存器。C1为了保证编译的速度采用了基于线性扫描的寄存器分配算法
4) 生成目标代码
  真正生成平台相关的机器代码的过程,在该阶段遍历LIR中的所有指令,并生成指令相关的汇编代码。主要是使用了LIR_Assembler类。

LIR_Assembler lir_asm(this);
lir_asm.emit_code(hir()->code());

  通过遍历LIR_List依次调用,依次调用各个指令相关的emit_code(如表2-3),LIR中的指令都是继承自LIR_Op

op->emit_code(this);

  以LIR_Op1为例,其emit_code方法为

void LIR_Op1::emit_code(LIR_Assembler* masm) {    //emit_code
    masm->emit_op1(this);
}

  以LIR_Op1为例,其emit_code方法为

case lir_prefetchr:
  prefetchr(op->in_opr());
  break;

  最终会调用 prefetchr函数,该函数为平台相关的,不同的平台下实现不同,以x86平台为例,其实现位于assembler_x86.cpp

void Assembler::prefetchr(Address src) {
    assert(VM_Version::supports_3dnow_prefetch(), "must support");
    InstructionMark im(this);
    prefetch_prefix(src);
    emit_byte(0x0D);
    emit_operand(rax, src); // 0, src
}

  最终将会生成相应的机器码。

b) 能否触发RowHammer

  C1编译器是否能够触发RowHammer? 经过分析发现,在x86平台下封装了prefetch相关的指令,确实是有希望控制产生prefetch指令。
  从底层向上分析,如果要生成prefetch指令,在LIR层需要出现LIR_op1操作,且操作码需要为lir_prefetchr或者lir_prefetchw,进一步向上层分析,要在LIR层出现这样的指令,在从字节码到HIR的过程中必须能够调用到GraphBuilder::append_unsafe_prefetch函数。该方法在GraphBuilder::try_inline_instrinsics函数中调用,进一步分析只需调用sun.misc.unsafe的prefetch操作即可触发。通过深入分析,Hotspot确实是支持prefetch操作,然而在Java的运行库rt.jar中,sun.misc.unsafe并没有声明prefetch操作,导致无法直接调用,需要更改rt.jar才能触发成功。这样就失去了攻击的意义。

  在Hotspot中还存在clflush这种指令,在hotspot的初始化阶段,其会生成一个代码块。如下所示:

__ bind(flush_line);                         
__ clflush(Address(addr, 0));          //addr: address to flush 
__ addptr(addr, ICache::line_size);                                         
__ decrementl(lines);                   //lines: range to flush
__ jcc(Assembler::notZero, flush_line);

该部分代码在C1编译器编译完成之后有调用

// done
masm()->flush();             //invoke ICache flush  

对当前代码存储的区域进行cache flush

void AbstractAssembler::flush() {
    sync();
    ICache::invalidate_range(addr_at(0), offset());
}

  这种方法可以对内存做cache flush, 主要问题在于代码存储的区域在堆中是随机分配的,无法直接指定cache flush的区域,而且由于涉及到编译的操作,无法在短时间内大量产生clflush指令。

c) 其它编译器实现

  C2编译器与C1编译器有一定的相似性又有很大的不同,由于主要在服务器端使用所以C2编译器更加注重编译后代码的执行效率,所有在编译过程中相对C1编译器做了大量的优化操作,但是在生成汇编代码的时候两者使用的是同一个抽象汇编,所以C2编译器与C1编译器应该大体相同,能够生成prefetch指令,但是在默认的情形下无法直接使用。
  Shark编译器是基于LLVM实现的,一般都不会开启,没有对该编译器进行进一步的分析。

2.2 Chrome V8

  V8是Google开源的Javascript引擎,采用C++编写,可独立运行。V8会直接将JavaScript代码编译成本地机器码,没有中间代码,没有解释器。其执行机制是将Javascript代码转换成抽象语法树,然后直接walk抽象语法树,生成相应的机器码。   在V8生成机器码的过程中无法生成prefetch, clflush, movnt*系列指令。但是在V8执行的过程中可能会引入prefetch指令。   产生prefetch的函数为
MemMoveFunction CreateMemMoveFunction() {

    __ prefetch(Operand(src, 0), 1);
    __ cmp(count, kSmallCopySize);    //kSmallCopySize=8
    __ j(below_equal, &small_size);  
    __ cmp(count, kMediumCopySize);   //kMediumCopySize=63
    __ j(below_equal, &medium_size);
    __ cmp(dst, src);
    __ j(above, &backward);

  该函数的主要作用是当缓冲区无法满足指令的存储时,需要将缓冲区扩大一倍,在该过程中会调用一次prefetch指令,但是调用的此处远远不足RowHammer触发的条件。

2.3 .NET CoreCLIR

  CoreCLR是.NET的执行引擎,RyuJIT是.NET的JIT实现,目前已经开源。作为Java的竞争对手,.NET大量参考了Java的实现机制,从字节码的设计,到编译器的实现等,都与Java有几分相似。在RyuJIT的指令集定义中只定义了一些常见的指令(图2.3),但是没有RowHammer需要的指令,所以无法直接触发。但是在CoreCLR的gc中存在prefetch操作(表2.12),然而该指令默认是被置为无效的(表2.13)。

图2.3
void gc_heap::relocate_survivor_helper (BYTE* plug, BYTE* plug_end)
{
        BYTE*  x = plug;
        while (x < plug_end)
        {
                size_t s = size (x);
                BYTE* next_obj = x + Align (s);
                Prefetch (next_obj);
                relocate_obj_helper (x, s);
                assert (s > 0);
                x = next_obj;
        }
}
图2.4
//#define PREFETCH
#ifdef PREFETCH
__declspec(naked) void __fastcall Prefetch(void* addr)
{
     __asm {
             PREFETCHT0 [ECX]
                ret
        };
}
#else //PREFETCH
inline void Prefetch (void* addr)
{
        UNREFERENCED_PARAMETER(addr);
}
#endif //PREFETCH
图2.5

2.4 Firfox SpiderMonkey

  SpiderMonkey是Firfox默认使用的带有JIT的Javascript引擎,在SpiderMonkey中没有RowHammer所需要的指令出现。

0x03 总结

  本文研究的主要目的是希望通过JIT引擎来触发RowHammer的执行,为了提高脚本语言的执行效率,当前绝大多数脚本引擎都带有JIT编译器以提高运行的效率。本文研究了Hotspot、V8、RyuJIT和SpiderMonkey,其中并没有找到比较好的触发RowHammer的方法,当然依旧有一些JIT还没被研究,不过通过以上研究证明JIT触发的方式非常困难,原因主要有以下几点:

1) RowHammer的触发条件比较苛刻,64ms内触发成功也就意味着无关指令的数目必须很少,否者在64ms内wordline无法充放电足够的次数。

2) Cache相关的指令并不常用,RowHammer运行需要使用CLFLUSH, PREFETCH, MOVNT*系列指令,这些指令在实际的使用过程中并不常见,在用户态进行Cache相关操作的情形比较少见。

3) 站在JIT开发人员的角度考虑,为了实现跨平台,一般会对指令进行抽象,然后在各个平台上具体实现。抽象的指令一般都尽可能少,因为每抽象一个指令就需要再添加大量的代码。在分析的JIT引擎中只有hotspot抽象了prefetch指令,引擎都尽可能少的去抽象编译器要用到的指令,想通过脚本直接生成需要的汇编指令很困难。(特例是如果采用了第三方引擎(比如AsmJit),引擎会抽象所有的汇编指令,则有更大的可能性触发,然而当前主流语言的JIT部分大都是独立开发,而第三方引擎则多是从这些代码中提取并逐步完善的)。

4) 在整个分析过程中发现指令出现的原因主要是辅助JIT编译,比如使用prefetch提高某些数据存取的速度,使用CLFLUSH刷新指令缓冲区等。指令出现的次数与频率,远远达不到RowHammer的要求。

参考资料

  1. Google Project Zero
    http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
  2. Paper: Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors http://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf
  3. 高级语言虚拟机群组 http://hllvm.group.iteye.com/
  4. 各语言开放的源代码