我们知道一些短期措施,以缓解某些微处理器的崩溃和幽灵漏洞,在这些微处理器中,投机性执行对缓存时间(主要是对微代码、操作系统和任何包含信任边界的应用程序的补丁)有可衡量的影响。
这个问题的长期解决方案是什么?
显而易见,简单的解决方案,如“不投机”或“投机时忽略缓存”,是不可能被接受的,因为性能方面的考虑从一开始就引入了猜测。
也许推测的指令可以使用单独的缓存,只有在推测成功的情况下才会复制到主缓存?若否,原因为何?
处理器能否向页表条目添加特权信息,从而使内核页表隔离自动化(并降低其性能影响)?
有没有其他设计上的改变可以提高安全性而不影响性能呢?
发布于 2018-01-19 22:02:46
修复崩溃很简单:如果CPU执行推测性的执行,就不要从内存的受保护区域读取数据。熔毁几乎完全是英特尔公司的事实表明,这是一个设计缺陷,而不是投机性执行的固有副作用。
在一般情况下修复幽灵要困难得多。幽灵是指将程序诱导为推测性故障,然后观察该故障的副作用。您无法消除所有的副作用:即使您可以回滚所有的缓存、缓冲区、表和诸如此类的东西,也有一个简单的事实,即投机性执行涉及投机性执行。运行推测指令需要(在某种程度上是数据可控的)时间,除非计算出时间旅行,否则无法取消。
所能做的是大大增加诱发投机故障的难度。目前,大多数CPU没有"process“的概念,在分支预测表中执行查找时只使用部分地址。如果对分支预测数据进行标记以指示它属于哪个进程,或者在每个上下文开关上刷新分支预测表,则有效地消除了一个程序错误训练分支预测器对另一个程序的动作的能力。类似地,如果使用完整地址执行分支预测,程序就无法攻击自己(例如,Javascript将无法使用web浏览器沙箱中的谱突破)。
发布于 2018-01-19 19:06:51
这三种攻击都使用了一些副作用,投机处决产生的副作用可以被实际观察到.
为了防止这类攻击,必须更改推测执行电路,使其不产生任何可观察的处理器状态变化(除了它们产生的临时结果)。例如,处理器可以在推测执行之前对所有缓存、缓冲区和表进行快照,并在不获取分支的情况下恢复它们。或者,它可以通过例如在分支预测失败后第一次使对所有缓存行的访问速度相等来防止观察效果。
不幸的是,任何修复都将意味着对当前处理器设计和方法的重大改变,并且可能会否定分支预测和推测执行的许多好处。
发布于 2018-01-19 14:17:39
据我所知,缓解某些微处理器崩溃和幽灵漏洞的短期措施是,投机性执行对缓存时间(主要是对微代码、操作系统和任何包含信任边界的应用程序的补丁)有可衡量的影响。
因此,我可以说,防止来自CPU/GPU/PSU的任何信息泄漏的正确方法是"Ziploc“范式。ziploc范式A.K.A Ziparadignloc,是防止这种东西被正确密封的唯一方法。
https://security.stackexchange.com/questions/177972
复制相似问题