Ubuntu 禁用 Spectre/Meltdown 防护
2018年公开的一类针对CPU的 speculative execution 攻击在当时看来具有灾难性影响。但相应的修复措施同样带来了显著代价。Speculative execution 本是提升CPU性能的重要手段，移除这些优化导致性能大幅下降。
如今，业界开始重新权衡这一利弊。Ubuntu已禁用部分防护措施，从而获得20%的性能提升。
经过Intel与Canonical安全团队的讨论，双方一致认为在计算运行时（Compute Runtime）层面不再需要对GPU进行Spectre防护。目前，Spectre漏洞已在内核层面得到缓解，计算运行时构建过程中的明确警告可作为通知，提醒那些运行未打补丁修改内核的用户。基于这些原因，我们认为计算运行时的Spectre缓解措施已不足以证明当前性能代价的合理性。
我同意这一权衡。这类攻击难以成功实施，且不易窃取有用数据。攻击系统存在更简单的方式。
新闻链接。
标签：网络攻击、恶意软件、操作系统
发布于 2025年7月2日上午7:02 • 22条评论
评论
PG •
2025年7月2日上午7:09
这些缓解措施对Intel的经济问题产生了多大影响？禁用措施在多大程度上是由于这些经济问题？
Clive Robinson •
2025年7月2日上午7:47
@所有人，
关于“这些攻击难以成功实施，且不易窃取有用数据”这一说法，其基于一个未经证实且可能不成立的假设：即所有此类攻击已被充分了解并定性，从而可做出价值判断。
Intel最初就持这一“默认立场”。但我曾警告，该问题将是“持续送礼的圣诞礼物”，预计未来五年或更长时间会出现更多类似缺陷。事实证明确实如此，已发现更多此类错误，且没有理由认为我们已停止发现。
关于未来“黑天鹅”事件的两个问题：
- 它们是否难以实施？
- 它们是否难以用于窃取数据？
答案均为“概率未知”。假设“低垂果实已被摘取”在特定情况下是危险的。
第三个问题：是否存在易于实施的缓解措施？
答案是“通过隔离实现”。
但问题四：是否存在无法采用“隔离缓解”的系统配置？
不幸的是，答案是“存在”。
问题五：原因何在？
答案可归结为MBA式的谬论：“任何通信都是好事”，这显然是错误的，实则为“为犯罪分子敞开所有门窗”的幼稚借口。
真正问题在于“不放弃任何利益”的论点。对此的简单回答是：“安全漏洞将带来代价。”
唯一问题类似于“勒索软件”：谁会在问题修复前后首先受害？
事实上，除硬隔离外还有其他缓解措施，但即使成本较低的方案也常因财务原因未获实施。
因此，同意这一权衡某种程度上是接受“无能管理为王”的现实。但在美国，由于法院“股东价值最大化”的裁决推动短期价值观，这实际成为法律立场。其他地区和实体持有不同观点，且应对10-30%性能损失的缓解成本远低于处理勒索软件攻击及清理的成本，尤其在涉及国家安全时。
Anonymous •
2025年7月2日上午9:16
“……这可能会开辟未知的攻击途径……无已知漏洞……可能暴露被缓解措施掩盖的其他漏洞……我们有一定信心……可能存在未知行为差异……”
未知因素太多。这能称为安全吗？
Mexaly •
2025年7月2日上午9:38
有人说过：“难攻破的攻击只会变得更容易”，或类似意思。
Mr. Peed Off •
2025年7月2日上午9:59
Spectre/Meltdown防护长期受游戏玩家和其他计算机性能爱好者诟病。大多数用户不太可能成为此类攻击目标。当然，可能被针对的用户应采取全面防护。
Clive Robinson •
2025年7月2日上午11:00
@Mr Peed Off及所有人，
关于“Spectre/Meltdown防护长期受游戏玩家诟病”，您是否阅读了Dan Goodin在ARS文章倒数第二段的说明：“Ubuntu用户需知，此变更仅在使用OpenCL框架或OneAPI Level Zero接口的GPU处理工作负载时提升性能。这意味着游戏玩家可能无法受益。”
Grima Squeakersen •
2025年7月2日下午3:47
加密货币挖矿系统是否易受Spectre/Meltdown（或类似）攻击？是否受缓解措施性能影响？若是，禁用缓解措施可能带来有趣动机：一是提升挖矿系统效率，二是使挖矿系统易受攻击。任一可能性都可能以某种方式、某种规模操纵财富。随着加密货币日益被视为国际贸易和财富存储工具，此时机可能对某些方有利。
Jon (a different Jon) •
2025年7月2日下午9:06
我认为可安全地说， speculative execution 本质存在安全弱点。只要存在，就可能以某种方式被利用。
好比房屋窗户是安全弱点，但比较完美安全与无窗生活的成本。对某些房屋，窗户价值超过安全成本；对某些掩体，安全价值超过窗户价值。
欢迎来到工程领域，特别是安全工程。总有权衡，且您可（大多）自行决策。
但需注意，与随时间稳定的窗户攻击不同，通过在线连接对CPU的攻击只会变得更易、更高效。十年前可接受的权衡现在可能不再适用。时间不站在防御方。
J.
Gilbert •
2025年7月3日上午5:37
我在运行Fedora的联想主笔记本上保持防护，用于浏览和编程。
但家中有几台高性能计算机用于运行或设计模型，我关闭了缓解措施以获取最大性能。这些机器不接入互联网。性能差异巨大，可达30%。
问题在于我们如何解决此问题。CPU性能很大部分来自缓存、 speculative execution……若移除这些，性能将下降。随着我们转向多处理器标量分布式计算，安全要求我们移除或限制这些标量方面，而因频率提升受限（硬件问题，我们远未达到使用太赫兹组件的技术水平），我们需在多计算单元上实现标量分布。
有趣问题：若寻求冯·诺依曼架构的替代方案会如何？当前机器同一内存空间存储数据和指令。但我们可以采用无限栈（自有空间）和另一内存空间存储逆波兰式Forth类语言，对仅含数据的“无限栈”进行操作。这并非奇想：核武器编程即采用此方式。Forth，无限（内存允许）栈存放数据，严格硬件分离数据栈与执行代码。
我对永恒向上兼容感到厌倦。x86世界（32位或64位）缓慢前进，拖着兼容性如脚镣。何时Intel或AMD能设计全新CPU，完全“新设计”，摒弃8086/DOS时代遗留，在每个步骤做出性能、安全最佳选择？然后我们移植系统至新平台，移除旧垃圾，跃入新世代。设计新处理器时，使其免受当前安全问题影响，如同密码学中设计必须免疫所有已知攻击。
我认为Intel曾有项目设计技术“跳跃”，从零开始摆脱向上兼容枷锁。但Intel日渐衰落，已放弃该项目。
Clive Robinson •
2025年7月3日上午8:08
@Grima Squeakersen及所有人，
关于“加密货币挖矿系统是否易受Spectre/Meltdown攻击及性能影响？”，我认为对某些类型挖矿（非全部）答案为“是”。
但应问：“此类设备是否需要直接连接互联网或其他公共网络？”答案为“否”。
因此，对此类攻击的缓解答案是：“您可在自有挖矿设备上充分缓解”。
然而……众所周知，部分挖矿设备通过恶意软件在他人设备上运行，通常需要互联网连接，故易受攻击。但控制这些“僵尸”者实为窃取他人电力并加速硬件老化……合理缓解措施将“扼杀窃贼商业模式”，这或许是好事。
jbmartin6 •
2025年7月3日上午8:30
我不责怪他们。据我所知，尚无真实漏洞利用，且无重要努力寻找。当然，我的知识有限，且总需担忧未来。另一方面，最可能利用路径——HTTP浏览器——在漏洞公开后不久即在其JavaScript引擎中缓解此风险。在盲目接受巨大性能代价前，攻击者仍有大量更易、更佳路径可利用。
Clive Robinson •
2025年7月3日下午1:33
@jbmartin6，
关于“据我所知，尚无真实漏洞利用，且无重要努力寻找”，这实为“若不寻找则无从知晓”的问题。
真正问题在于，大多数重大有害攻击并非通过攻击本身被察觉，而是通过数据窃取阶段的副作用或攻击者最终目的达成。例如“勒索软件”，有多少攻击在造成实际危害前的早期阶段被截获？而非当网络使用警报触发或组织数据不可用且“账单已呈递”时？
我们曾用APT（高级持续威胁）描述某些攻击者目标，现用LotL（无文件攻击）描述某些攻击者隐蔽方法。结合APT和LotL，可让“立足点”随时间变为不仅“主要桥头堡”，而是对组织/实体信息系统、数据和知识的完全渗透与掌控。
其成功部分原因包括：
- 零日或类似“无迹象”攻击入口方法。
- 缓慢变化或“无迹象”有效载荷方法。
关键点在于“无迹象”常称为“低于噪声”或“藏身草丛”的方法保持低于自动警报和大多数人眼阈值，因而对系统操作员和管理员“不可见”。
您只能对部分或全部观察到的事物做出响应，而当全部显现时通常为时已晚。更糟的是，可能仅在攻击者故意让您知晓时才意识到。
我们知道，意识有时间接产生，如“工业间谍活动”时已为时过晚，对组织/实体实为生存威胁。
我们知道法国、以色列、中国和俄罗斯国家实体曾经并假定仍在进行APT/LotL，以极低成本获取组织研发成果，使其国家经济或行业以低成本、短时间受益。此类信息价值可能超过勒索软件或常见犯罪活动所能获取……
[1] APT定义参考链接
[2] LotL定义参考链接
lurker •
2025年7月3日下午2:07
@Gilbert
您的想法与我平行。但不能等待Intel解决问题。他们是商业公司，受向后兼容性拖累。而Forth/RPL操作独立数据栈的想法可能曾存在于Intel工程师口袋中（以HP计算器形式）。
Peter A. •
2025年7月3日下午2:53
@Gilbert：
即使非冯·诺依曼架构也非万能。若代码有漏洞，畸形/精心构造的数据可导致其进入非预期/有害路径。
此类分离代码与数据的Forth系统适用于一次性任务。您设计、编码、审查、测试，在规定时间内尽可能消除漏洞，然后烧录至某种WORM内存即可。若需更改，需在硬件层面整体更换或更换WORM单元。
这对需适应变化需求的通用计算不实用。无合理更新路径。代码即数据。如何从供应商到消费设备全程分离代码路径与数据路径？一条路径在8位时代已走过：卡带。想要新软件版本，购买新卡带并丢弃旧版。但盗版卡带（多为游戏）存在。如何确保整个供应链安全，获得原始、无漏洞、安全软件而非被三字母机构、犯罪组织或供应商自身“加料”的版本？
Jon (a different Jon) •
2025年7月3日下午9:02
@Gilbert：
顺便一提，许多（大多数？）嵌入式微控制器正是如此工作（哈佛架构）。代码通过完全不同的编程硬件写入ROM，而代码使用的内存（RAM）是物理分离的晶体管组。
当然，多数提供“引导加载程序”指令，允许RAM内容更改ROM，但使用繁琐，且常被原始代码编写者省略或故意禁用。
@Peter A：
正确，异常数据可导致（有漏洞？）代码进入异常路径，但除非原始设计者加入代码自修改能力（“引导加载程序”），数据难以造成永久性损害。
因此有“关闭再重启”的调试方法。清除“异常数据”重新开始。😉
最后，不幸的是，许多现代嵌入式微控制器正涌向近乎全“引导加载程序”环境，因更廉价——不再需要昂贵编程硬件。这打破了代码与数据的分离——但更便宜。唉。
J.
Swede •
2025年7月4日上午12:23
此变更影响OpenCL使用，主要关联GPU。据我所知，openssl未使用它。
Clive Robinson •
2025年7月4日上午5:33
@Swede及所有人，
关于“此变更影响OpenCL使用，主要关联GPU”，这是我的理解（故对@Mr Peed Off的评论）。
但ARS文章未明确区分，混淆了原始CPU问题与此GPU问题。
更普遍情况下，此类“加速技巧”可见于任何可进行底层硬件并行执行之处（这也是它们仍在所有架构中被发现的原因）。
更糟的是，它们还可从使用加密保护信息存储和通信的安全区域内部携带秘密流出。
因为对信息可做三件事：
- 传输
- 存储
- 处理
当前最敏感的是“处理”，此类技巧可将元数据直接带出安全处理环境。
此类“隐蔽信道”问题在于“元数据”形式可重建不仅数据，还有处理中被视为重要的数据值。
这是计算栈各层级“并行处理”可能泄露机密信息的一个方面。出于某种原因，它很少被讨论，甚至被主动劝阻。
或许因为我们现在正逼近终结Intel创始人Gordon Moore观察（现称“摩尔定律”，尽管是六十年前观察而非定律）的“物理墙”，它具有“撞墙”含义。
多数高端硅制造商正尝试通过一种或多种并行处理形式“转向”。我们从Meltdown起作用的“微代码”层面上升至“多核”，当前“救星”在于众多程序员无法超越传统串行思维，从而可避免问题但性能代价更高……
这需要改变，随着变化，此类隐蔽信道泄漏将在人们试图提升支撑Gordon Moore观察的一条或多条效率/性能曲线时“打开”。
最终无法避免的问题是“光速C”，它对给定时间内信息传输距离设定了硬限制。有方法可应对，但涉及移除许多串行思维程序员视作基础方法的“闭环”等……
参考https://en.m.wikipedia.org/wiki/Loop_unrolling#Advantages 了解若需“驯服C”必须缓解的一些问题领域。
Who? •
2025年7月4日上午5:59
@Clive Robinson, Mr. Peed Off
我同意Clive Robinson。存在这些漏洞的巧妙概念验证，一旦有可适配代码库，利用并不难。
我们会说RowHammer难以利用；但有概念验证可修改目标位。类似funtenna攻击。
建立既高效又安全（抗经典和量子计算）的计算机间安全通信看似困难。但我们有OpenSSH。无人会说OpenSSH难用。
关于Mr. Peed Off评论：
Spectre/Meltdown防护长期受游戏玩家诟病。大多数用户不太可能被针对。当然，可能被针对者应采取全面防护。
我不关心游戏玩家，及那些认为对公民的高调攻击是都市传说者。我们有三字母机构和政府因不喜我们活动而入侵计算机（难以想象帮助NGO为何是犯罪）。我们有犯罪组织利用政府监视公民的相同基础设施。
我们甚至有Meta和Yandex等公司使用本应属高端监视机构的技术监视公民。
游戏玩家想要不安全计算机？很好，为他们构建这些系统！但让那些想要计算机做更多事而非击杀其他玩家的人拥有安全平台。
最终问题在于Intel和AMD等公司太贪婪；他们知SMT危险但仍实施（即使SMT可能成为某些高CPU使用的瓶颈）。他们知 speculative execution 危险但不在乎，因它让处理器看起来更快。
问题不在公司贪婪，而在他们将决策强加于所有人。我未听闻无 speculative execution 处理器。我未听闻真正无Intel AMT/ME的系统。
他们不向终端用户出售高保障平台计算机。为何安全仅属政府？为何公民无权购买使用相同安全系统？
不，Bruce，如Clive一样，我不同意您的评论。这些漏洞可能难以利用，但一旦拥有一个，可对数百万计算机使用相同漏洞。
我会仔细思考此事，答案并非看似简单。
Clive Robinson •
2025年7月4日下午4:54
@所有人，
我在上述评论中提到“光速C”是墙但非多数人想的“硬墙”。
我提到使用“循环展开”作为绕过C问题的一些方法。
但还有其他方式，其中之一我在1990年代曾考虑用于博士研究。随着互联网诞生，我看到高度并行计算将快速超越Hyper-Cubes及其他类似几何结构（诺贝尔物理学家Richard Feynman研究领域）。即使百万CPU构建为100x100x100立方体，也可将数据传输距离削减约十倍。
但削减距离不削减数据速率，故带宽问题。
我研究了降低符号率（波特）和数据速率的两个方面。一是使用每符号可传输64比特数据的相位和幅度调制形式。二是通过压缩算法减少传输比特数。
许多压缩算法问题在于它们与“通用数据”“不匹配”，若使用错误算法可能增加而非减少传输比特数。更糟的是，许多算法“缓慢如猪”，需要大量CPU周期。
一些“老练”读者知IEEE和CEPT曾研究在电话线上使用压缩。最终结果是在硬理论无法支持19K符号的信道上实现端到端56K平均数据速率……端到端数据速率相对传输速率3:1提升基本靠压缩算法变体。
我以为这是三十年前的“旧闻”，故在IT术语中属20代前的想法。故阅读https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Compression_dictionary_transport 时我很惊讶。
数学家、“硬件工程师”及少数非常规通信工程师早已完成这一切的事实未被提及。
但嘿，“曾做此事”但不像Richard Feynman“穿了T恤”😉
[1] Richard Feynman被誉量子计算思想发明者，但某英国大学持不同观点……故Prof David Deutsch常被描述为“量子计算之父”。
“年轻人”较少知Richard Feynman协助开发“连接机器”的工作，这是将64