英特尔证实Alder Lake BIOS源码泄露 但安全无需多虑

英特尔证实AlderLakeBIOS源码泄露但安全无需多虑近日泄漏到4chan和GitHub上的AlderLakeBIOS源码，已经得到了英特尔的证实，可知其中6GB文件包含了用于构建和优化BIOS/UEFI映像的工具和代码。该公司在致Tom'sHardware的声明中称：“我公司专有的UEFI代码，似乎已被第三方泄露。但Intel认为这不会暴露任何新的安全漏洞，因为我们不依赖混淆信息作为安全措施”。PC版：https://www.cnbeta.com/articles/soft/1325429.htm手机版：https://m.cnbeta.com/view/1325429.htm

泄露的英特尔酷睿Alder Lake BIOS的5.9GB源代码被发布到GitHub上

泄露的英特尔酷睿AlderLakeBIOS的5.9GB源代码被发布到GitHub上之前我们报道过英特尔酷睿AlderLakeBIOS的源代码已在被完整地泄露了，未压缩版本的容量有5.9GB，它似乎可能是在主板供应商工作的人泄露的，也可能是一个PC品牌的制造伙伴意外泄露的。PC版：https://www.cnbeta.com/articles/soft/1324985.htm手机版：https://m.cnbeta.com/view/1324985.htm

英特尔 20GB 机密数据泄漏，涉及 BIOS 和专有技术源代码等

英特尔20GB机密数据泄漏，涉及BIOS和专有技术源代码等https://www.cnbeta.com/articles/tech/1012713.htm英特尔已开始调查20GB机密文档泄漏，目前认为是有权限人员下载并分享http://www.techweb.com.cn/world/2020-08-07/2799928.shtml「TillKottmann称他所上传的文档，是来自一位匿名黑客，后者声称他在今年年初攻击了英特尔。TillKottmann还表示，目前公布的只是多批与英特尔相关的文档的第一批。」意思是接下来还要公开更多资料

英特尔第12代Alder Lake CPU的源代码据称在黑客攻击中被泄露

英特尔第12代AlderLakeCPU的源代码据称在黑客攻击中被泄露VX-Underground在Twitter上表示，在经历一次重大的黑客攻击之后，英特尔第12代AlderLake的源代码（包括BIOS文件等）在网上泄露。英特尔的AlderLakeCPU于去年11月4日发布，2021年，数据包括容量2.8GB的压缩源代码（完整文档5.86GB），据称泄漏来自4chan。据说该代码库非常庞大，但内容还有待核实。PC版：https://www.cnbeta.com/articles/soft/1324897.htm手机版：https://m.cnbeta.com/view/1324897.htm

英特尔已确认导致第13代和第14代CPU崩溃的问题，计划通过BIOS补丁解决

英特尔已确认导致第13代和第14代CPU崩溃的问题，计划通过BIOS补丁解决英特尔对第13/14代酷睿台式机处理器的稳定性问题作出回应，确认过高的运行电压是导致处理器不稳定的原因。这一问题由微代码算法错误导致，该算法向处理器发送了错误的电压请求。为解决此问题，英特尔计划在八月中旬发布微代码补丁，并正在进行全面验证以确保解决所有相关稳定性问题。关注频道@ZaiHuaPd投稿爆料@ZaiHuabot

英特尔发布Linux系统下的CPU微代码更新

英特尔发布Linux系统下的CPU微代码更新tip.git的x86/microcode分支对Linux内核的x86微代码处理进行了初步改进。这些补丁删除了一些无用的互斥，丢弃了一些旧的调试代码，并使CPU微代码加载支持在基于x86的系统上不再是一个选项，而是始终启用。在英特尔和AMD系统上，任何需要微码加载支持的"合理配置"，现在都会启用该选项。早先的x86微代码加载改进至少已在TIP中排队等候，很可能成为即将到来的Linux6.6周期的一部分：https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=x86/microcode英特尔至强Max服务器CPUThomasGleixner一直在领导改进英特尔Linux系统后期微码加载的工作。他在这个补丁系列中解释说："企业用户希望延迟加载微代码。延迟加载是有问题的，因为它需要详细了解变更，并分析该变更是否修改了内核已经在使用的内容。大型企业客户拥有工程团队和深入的技术供应商支持。而普通管理员没有这样的资源，因此内核在后期加载后总是会有污点。英特尔最近在微码头中添加了一个新的保留字段，其中包含了CPU上必须运行的最小微码版本，以确保加载安全。在所有较旧的微代码版本中，该字段的值都是0，内核会认为这些微代码版本不安全。最小版本检查可通过Kconfig或内核命令行执行。这样，内核就会拒绝加载不安全的修订版。默认情况下，内核会像以前一样加载不安全的版本，并玷污内核。如果加载的是安全版本，内核就不会被玷污。但这并不能解决延迟加载的所有其他已知问题：-当前英特尔CPU上的延迟加载与启用超线程时的NMI相比是不安全的。如果在主处理器加载微代码时发生NMI，次处理器就会崩溃。-当微码更新修改了MWAIT时，使用MWAIT的软脱机SMT姊妹们也会造成损坏。在"nosmt"缓解措施的背景下，这是一种现实的情况。无论是核心代码还是英特尔特定代码，都根本不会处理这些问题。在尝试实现这一点时，我无意中发现了一些功能失常、复杂得可怕的冗余代码，因此我决定先清理这些代码，以便在干净的石板上添加新功能"。在Linux上，延迟加载微代码是指当系统已经启动并运行软件时，允许更新CPU微代码，而不是在CPU内核不忙的启动时间提前加载微代码。延迟加载CPU微代码对于超大规模企业、云服务提供商和其他大型企业尤其有用，因为它们希望以安全的名义快速部署CPU微代码更新，但又要避免系统宕机。目前还不清楚改进后的英特尔CPU微代码延迟加载是否能在v6.6内核中及时完成，但至少这项改进正在进行中。...PC版：https://www.cnbeta.com.tw/articles/soft/1377059.htm手机版：https://m.cnbeta.com.tw/view/1377059.htm