去年，我们报道了一个漏洞，可以让攻击者绕过AMD的安全加密虚拟化(SEV)技术提供的保护，该漏洞存在于AMD的EPYC服务器处理器中。
当这个问题被曝光后，AMD驳回了这个漏洞，理由是它需要物理访问硬件，但这只是故事的一半。负责最初发现的研究人员罗伯特·布伦(Robert Buhren)说，物理访问只在第一个实例中需要，之后该漏洞可能被远程利用，造成灾难性的影响。
然而，从那以后，另一位名叫Atul Payapilly的安全专家为这个漏洞设计了一个解决方案，他说这个方案可以关闭远程攻击载体，并保留AMD SEV的效用。唯一的问题是，AMD对此并不感兴趣。
表的内容
为什么这很重要?
AMD SEV漏洞的核心是一种名为远程认证的机制，通过这种机制，云客户可以验证其虚拟机的正确部署。
远程认证的功能取决于芯片背书密钥(CEK)的安全性，CEK对每个EPYC处理器来说都是独一无二的，充当信任的根。如果任何AMD EYPC背书密钥被攻击者泄露，AMD SEV在所有部署中提供的保护将失效，因为密钥是可互换的。
最初的研究人员发现，通过操纵通过EPYC SoC的电压，AMD安全处理器(AMD- sp)的只读存储器(ROM)引导加载程序中可能会产生一个错误，从而释放最重要的CEK。这种攻击可以在公开市场上购买的硅上进行，这意味着攻击者不必渗透到部署在生产环境中的硬件。
当这个漏洞出现在黑帽大会上时，Buhren声称这个问题没有缓解的办法，他说这个问题只能在未来几代的EPYC处理器中得到纠正。
这种情况的后果是多种多样的。实际上，这意味着任何希望在AMD SEV之上构建服务的公司都必须立即停止其计划，并等待今年晚些时候EYPC热那亚芯片的到来——前提是下一代芯片的解决方案已经交付。
Payapilly之所以开始研究这个问题，是因为他发现自己正处于这样的境地。他的公司verifiable使用可信的执行环境来证明代码的完整性。然而，现在AMD SEV的安全性受到了质疑，该公司不能真诚地利用该技术来支持其预期的产品。
解决方案
Payapilly不相信不需要等待新硬件上市就无法解决AMD SEV漏洞的说法，于是开始寻找解决方案。
他设计的解决方案建立在这样一个原则之上:现在是时候接受硬件安全永远无法得到保证的事实了。因此，我们需要能够降低这种风险的基于软件的解决方案。
提出的解决方案旨在消除远程攻击载体，解决了目前在芯片背书密钥(CEK)被滥用之前，无法确定哪个芯片背书密钥(CEK)已被泄露的问题。可以总结如下:
- 云提供商使用从其部署的每个AMD EYPC处理器中提取的CEKs填充白名单
- 当客户执行远程认证时，云提供商会对其可信密钥列表进行交叉检查
- 在信息最终发布之前，查询被传递到AMD对根密钥进行签名
变通方案的有效性得到了Buhren的单独证实，尽管他急于强调这不是对最初袭击的缓解。他还指出，解决方案将要求客户信任他们的云提供商。
Payapilly表示，尽管AMD无需为解决方案的实施付出任何代价，但通过与云服务提供商合作，公司将从中受益。然而，AMD迄今没有表现出任何兴趣。
Payapilly最初在2月14日那周联系了该公司，但没有回复。3月8日，AMD告诉TechRadar Pro，它不会对该漏洞被远程利用的机会、提议的解决方案或未来几代EYPC处理器解决该问题的计划发表评论。
