解析Frozen Cache抵内存威胁
来源：不详 责任编辑：栏目编辑 发表时间:2013-07-01 03:30 点击:次
Cold boot 攻击对全磁盘加密解决方案所提供的数据安全保护是一个重大威胁，大部分计算机都容易受到这种攻击，而到目前为止还没有通用方法可以解决这个问题。
为什么这篇文章名为“冻结缓存(Frozen Cache)”呢?因为我们决定采用CPU缓存来抵御Cold boot 攻击(至少对于所有X86系统)。
这个概念很简单：将缓存切换到特殊模式，该模式下可以强迫数据在缓存中而不是被写入支持RAM位置。因此，加密密钥不能从RAM提取，其实这种技术并不新鲜：LinuxBIOS/CoreBoot将这种技术称为Cache-as-RAM，并使用这种技术来允许“RAM访问”，即使是在初始化内存控制器前。
下列步骤加载并维护CPU缓存中的256位的加密密钥，并假定加密密钥存放在RAM的线性地址X中：
1. 从RAM将加密密钥加载到一些CPU注册器中(如SSE注册器)：
movq 电脑技术学习：, %xmm0
movq [X+8], %xmm1
movq [X+16], %xmm2
movq [X+24], %xmm3
2. 使用0值复写RAM中加密密钥
movq 0, 电脑技术学习：
movq 0, [X+8]
movq 0, [X+16]
movq 0, [X+24]
3. 刷新缓存(从而真正覆盖RAM中的加密密钥)
wbinvd
4. 添加需要的RAM区域到CPU的MTRR(4K部分包含密钥)
movl (X | MEMORY_TYPE_WRITEBACK), %eax
xorl %edx, %edx
movl 0x200, %ecx
wrmsr
movl ( ~(1) | MTRR_VALID ), %eax
movl 0x1, %edx
movl 0x201, %ecx
wrmsr
5. 禁用/冻结CPU的缓存(CR0.CD=1)
movl %cr0, %eax
orl 0x40000000, %eax
movl %eax, %cr0
6. 从CPU注册器向RAM写入加密密钥(数据仍然在缓存中，不会写入内存)
movq %xmm0, 电脑技术学习：
movq %xmm1, [X+8]
movq %xmm2, [X+16]
movq %xmm3, [X+24]
“禁用/冻结”CPU的缓存严重降低了性能，但是，这似乎也是可以接受的，因为考虑到只需在屏幕锁定时设置特殊模式(如果笔记本被盗，那么所以努力都毫无意义)。在Linux系统的首次概念证明测试结果表明，需要对解锁GUI进行很多必要的性能优化(从性能/可用性角度考虑)。
这段文字只是描述了基本的概念，下面将涉及多CPU/Core问题、性能考虑和优化等问题。
性能方面
如上所述，性能问题是将缓存切换到“冻结”模式的主要关注问题，CPU架构的广泛范围(多CPU、多核和多线程)和各自的缓存配置让问题变得更加复杂。
首先：只有一个CPU缓存需要“冻结”以有效保护加密密钥。其他CPU允许执行政策缓存模式。只要每个(逻辑或者虚拟的)CPU完全使用自己的缓存：采用线程技术(如英特尔的超线程HyperThreading)CPU会作为两个(或者可能更多)逻辑CPU，但是这两个CPU共享相同的缓存，而它们必须同时切换至冻结缓存模式。对于多核CPU，可能情况更加复杂，如果内核都有自己的(L1和L2)缓存。
加密密钥仅位于单个CPU的缓存中，只有这个CPU必须执行加密和解密线程，在全磁盘加密解决方案中最常见的架构就是采用内核模块，它会产生一个为加密和解密逻辑指定的内核线程，内核线程是可调度实体，因此可以绑定在CPU上，CPU缓存中有加密密钥。
回到更加“传统的”性能考虑，怎样做可以减少冻结CPU缓存带来的影响呢?将最常用的内存区域加载到缓存(冻结前)是个不错的开始，其中最适合的包括：系统调用入口端点、计时器中断线程及其“帮助”功能，以及内核线程执行的加密/解密功能。目前L2缓存通常可以容纳所有这些代码，但是同时还需要考虑缓存的结合问题，以避免相关问题。另一个好办法就是将所有其他进程的时间表分配给其他可用的CPU(不使用冻结缓存的CPU)：这样可以以正常的速度执行，另一个很重要的原因就是，我们能获得更多时间。
现在已经很明显了，将需要部署确定具体(运行中的)CPU/缓存组件的程序并有针对性的管理他们。
缺乏缓存控制
一旦缓存被冻结，对这些缓存内容的管理就没有结束：同样重要的是，缓存中的数据(加密密钥)并没有写回内存。不幸的是，英特尔架构只允许非常少的缓存控制：
· 启用/禁用缓存(系统范围：CR0.CD，每个内存区域：MTRR，每页：PAT)
· 清除缓存(wbinvd
就是如此，根本没有查询缓存状态(目前在单个缓存线中的RAM
为什么这篇文章名为“冻结缓存(Frozen Cache)”呢?因为我们决定采用CPU缓存来抵御Cold boot 攻击(至少对于所有X86系统)。
这个概念很简单：将缓存切换到特殊模式，该模式下可以强迫数据在缓存中而不是被写入支持RAM位置。因此，加密密钥不能从RAM提取，其实这种技术并不新鲜：LinuxBIOS/CoreBoot将这种技术称为Cache-as-RAM，并使用这种技术来允许“RAM访问”，即使是在初始化内存控制器前。
下列步骤加载并维护CPU缓存中的256位的加密密钥，并假定加密密钥存放在RAM的线性地址X中：
1. 从RAM将加密密钥加载到一些CPU注册器中(如SSE注册器)：
movq 电脑技术学习：, %xmm0
movq [X+8], %xmm1
movq [X+16], %xmm2
movq [X+24], %xmm3
2. 使用0值复写RAM中加密密钥
movq 0, 电脑技术学习：
movq 0, [X+8]
movq 0, [X+16]
movq 0, [X+24]
3. 刷新缓存(从而真正覆盖RAM中的加密密钥)
wbinvd
4. 添加需要的RAM区域到CPU的MTRR(4K部分包含密钥)
movl (X | MEMORY_TYPE_WRITEBACK), %eax
xorl %edx, %edx
movl 0x200, %ecx
wrmsr
movl ( ~(1) | MTRR_VALID ), %eax
movl 0x1, %edx
movl 0x201, %ecx
wrmsr
5. 禁用/冻结CPU的缓存(CR0.CD=1)
movl %cr0, %eax
orl 0x40000000, %eax
movl %eax, %cr0
6. 从CPU注册器向RAM写入加密密钥(数据仍然在缓存中，不会写入内存)
movq %xmm0, 电脑技术学习：
movq %xmm1, [X+8]
movq %xmm2, [X+16]
movq %xmm3, [X+24]
“禁用/冻结”CPU的缓存严重降低了性能，但是，这似乎也是可以接受的，因为考虑到只需在屏幕锁定时设置特殊模式(如果笔记本被盗，那么所以努力都毫无意义)。在Linux系统的首次概念证明测试结果表明，需要对解锁GUI进行很多必要的性能优化(从性能/可用性角度考虑)。
这段文字只是描述了基本的概念，下面将涉及多CPU/Core问题、性能考虑和优化等问题。
性能方面
如上所述，性能问题是将缓存切换到“冻结”模式的主要关注问题，CPU架构的广泛范围(多CPU、多核和多线程)和各自的缓存配置让问题变得更加复杂。
首先：只有一个CPU缓存需要“冻结”以有效保护加密密钥。其他CPU允许执行政策缓存模式。只要每个(逻辑或者虚拟的)CPU完全使用自己的缓存：采用线程技术(如英特尔的超线程HyperThreading)CPU会作为两个(或者可能更多)逻辑CPU，但是这两个CPU共享相同的缓存，而它们必须同时切换至冻结缓存模式。对于多核CPU，可能情况更加复杂，如果内核都有自己的(L1和L2)缓存。
加密密钥仅位于单个CPU的缓存中，只有这个CPU必须执行加密和解密线程，在全磁盘加密解决方案中最常见的架构就是采用内核模块，它会产生一个为加密和解密逻辑指定的内核线程，内核线程是可调度实体，因此可以绑定在CPU上，CPU缓存中有加密密钥。
回到更加“传统的”性能考虑，怎样做可以减少冻结CPU缓存带来的影响呢?将最常用的内存区域加载到缓存(冻结前)是个不错的开始，其中最适合的包括：系统调用入口端点、计时器中断线程及其“帮助”功能，以及内核线程执行的加密/解密功能。目前L2缓存通常可以容纳所有这些代码，但是同时还需要考虑缓存的结合问题，以避免相关问题。另一个好办法就是将所有其他进程的时间表分配给其他可用的CPU(不使用冻结缓存的CPU)：这样可以以正常的速度执行，另一个很重要的原因就是，我们能获得更多时间。
现在已经很明显了，将需要部署确定具体(运行中的)CPU/缓存组件的程序并有针对性的管理他们。
缺乏缓存控制
一旦缓存被冻结，对这些缓存内容的管理就没有结束：同样重要的是，缓存中的数据(加密密钥)并没有写回内存。不幸的是，英特尔架构只允许非常少的缓存控制：
· 启用/禁用缓存(系统范围：CR0.CD，每个内存区域：MTRR，每页：PAT)
· 清除缓存(wbinvd
就是如此，根本没有查询缓存状态(目前在单个缓存线中的RAM
相关新闻>>
最新推荐更多>>>
- 发表评论
-
- 最新评论 更多>>