Security 带设备存储器的幽灵

关于

spectre

安全问题和侧通道攻击

在和中都存在一种方法来禁用特定内存页上的缓存/推测访问。因此，对这些内存区域的任何侧通道攻击（

spectre

，

meldown

）都是不可能的。那么，为什么我们不使用它来防止侧通道攻击，将所有安全信息（密码、密钥等）存储到缓慢但安全的（？）内存区域，同时将不安全的数据放入快速但不安全的正常内存？这些页面上的访问时间将减少一个巨大的因素（~100），但内核修复也不便宜。所以，也许仅仅降低几个内存页的性能比总体上稍微降低一点要快

这将把解决问题的责任从操作系统转移到应用程序开发人员身上，这将是一个巨大的变化。但是，希望内核能够以某种方式修复所有bug似乎也不是一个好方法

所以我的问题是

使用“设备”内存页真的能防止这种攻击吗

它的缺点是什么？（除了明显的性能问题）

这种用法有多实用

---

因为我们的编译器/工具链/操作系统不支持对某些变量使用不可缓存的内存，也不支持避免将它们的副本溢出到堆栈中。（或根据它们计算出的临时值。）

另外，在Linux上，即使您愿意，也无法在用户空间进程中分配一页UC内存。当然，这可以通过

mmap

和/或

mprotect

的新标志进行更改。希望它的设计能够使在旧系统上运行新的二进制文件能够获得常规的写回内存（因此仍然可以工作，但没有安全优势）

我不认为让非特权用户空间映射WC或UC内存有任何拒绝服务的影响；您已经可以使用NT存储和/或

clflush

强制内存访问，并争夺系统内存控制器时间/资源的更大份额