Windows的一次漏洞修复却误伤了Linux，双系统用户意外中招 最近，许多同时使用windows和Linux双系统的用户遇到了一个问题。这些用户在安装了微软最新的windows更新后，他们的Linux系统突然无法启动了。 这是咋回事呢？ 事情的起因是微软针对一个名为CVE-2022-2601的漏洞发布更新。 这个漏洞本身与GRUB有关，GRUB是大多数Linux系统用来引导启动的重要组件。为了修复这个漏洞，微软在更新中引入了SBAT机制，意指增强系统启动时的安全性。同时，微软还称这个更新不会影响装有任何Linux系统的设备。结果却被打脸了。 安装更新后，许多用户在启动Linux时遇到错误提示，系统显示“Verifying shim SBAT data failed: Security Policy Violation”以及“SBAT自检失败：违反安全策略”。这些错误提示表明系统无法通过安全策略的验证，导致Linux无法正常启动。 有用户对此提出疑问，微软为什么要插手修复跟他们的Windows系统不直接相关的组件？ 微软方面的解释却显得有些敷衍。他们称，在检测到系统中存在Linux启动选项时，这次更新本不应该被应用，并且问题可能是由“过时的”Linux加载程序引起的。他们正在与Linux合作伙伴一起解决这个故障。 用户显然不接受这种解释，因为这一问题在多个Linux发行版上都有发生，无论是新版本的Ubuntu，还是老版本的Debian，都未能幸免。 有网友表示，如果你只用Linux，根本不用担心发生这样的故障。另外还有人提问，为什么会有人使用GRUB来只启动windows？ 这些质疑声无不指向微软排挤Linux。这场风波让人不禁想起微软与Linux的“爱恨情仇”。 早些年，微软曾试图通过安全启动机制阻止Windows 10用户启动其他操作系统，而这次更新的结果难免令人怀疑，微软是否对双系统用户做了足够的测试？ 当然，微软也提供了替代方案，比如WLS（Windows Subsystem for Linux），允许用户在Windows中运行Linux子系统，但对于那些真正需要双系统的用户来说，这显然不是最佳选择。 总而言之，面对突如其来的故障，用户们纷纷在网上寻求帮助，社区里都是大家的讨论和分享。 有的用户提出了临时的解决办法，先进入BIOS关闭安全启动功能，进入Linux系统后通过命令行删除导致问题的SBAT策略，接着再重启系统，最后重新打开安全启动。 虽然这一方法能暂时解决问题，但用户们心里还是有些不安——谁知道下次更新又会不会出现类似的状况呢？