OpenVelinux内核中的MDS问题分析与防护指南
什么是MDS问题
MDS(Microarchitectural Data Sampling,微架构数据采样)是Intel处理器中存在的一类硬件安全问题,它允许攻击者通过推测执行技术访问处理器内部缓冲区中的敏感数据。
这类问题源于现代CPU为了提高性能而采用的微架构优化设计。当处理器执行存储、加载或L1缓存重填操作时,数据会被临时存放在各种微架构缓冲区中。在特定条件下,这些缓冲区中的无关数据可能被推测性地转发给加载操作,进而通过侧信道攻击被恶意程序获取。
受影响的处理器范围
MDS问题主要影响Intel处理器家族,以下情况不受影响:
- AMD、Centaur等非Intel厂商的处理器
- CPU家族号小于6的早期处理器型号
- 部分Atom处理器(Bonnell、Saltwell、Goldmont、GoldmontPlus系列)
- IA32_ARCH_CAPABILITIES MSR中设置了ARCH_CAP_MDS_NO位的Intel处理器
值得注意的是,并非所有受影响处理器都会遭遇所有MDS变种攻击,但由于防护措施相同,内核将它们统一视为同一类问题处理。
MDS问题变种与对应CVE编号
MDS包含多个具体变种,每个都有独立的CVE编号:
| CVE编号 | 缩写 | 全称 |
|---|---|---|
| CVE-2018-12126 | MSBDS | 微架构存储缓冲区数据采样 |
| CVE-2018-12130 | MFBDS | 微架构填充缓冲区数据采样 |
| CVE-2018-12127 | MLPDS | 微架构加载端口数据采样 |
| CVE-2019-11091 | MDSUM | 微架构不可缓存内存数据采样 |
问题原理深度解析
现代处理器在执行内存操作时,会使用多种临时缓冲区来优化性能:
- 存储缓冲区(Store Buffer):暂存尚未提交到缓存的内存写入操作
- 填充缓冲区(Fill Buffer):处理缓存未命中时的数据填充
- 加载端口(Load Port):执行内存加载操作的执行单元
当加载操作引发故障或需要辅助处理时,这些缓冲区中的无关数据可能被推测性地转发。虽然这些数据最终会被丢弃,不会影响程序正确性,但攻击者可以利用侧信道技术(如缓存计时分析)来推断这些数据的内容。
由于超线程技术会共享这些内部缓冲区,因此跨超线程的攻击也成为可能。这使得MDS问题在云环境和虚拟化场景中尤为危险。
实际攻击场景分析
MDS问题可能被以下方式利用:
- 本地用户空间攻击:恶意应用程序可以尝试提取同一物理核心上其他进程的敏感数据
- 虚拟机逃逸攻击:客户机可能利用问题获取宿主机或其他客户机的数据
- 浏览器攻击:虽然通过JavaScript实施攻击被认为非常困难,但WebAssembly等技术的滥用可能性不能完全排除
与某些其他推测执行问题不同,MDS攻击者无法控制目标内存地址,攻击完全基于采样技术。但正如TLBleed攻击所证明的,采样数据经过后处理仍可能获取有价值信息。
系统问题状态检查
OpenVelinux内核通过sysfs接口提供了系统MDS状态的详细信息:
/sys/devices/system/cpu/vulnerabilities/mds
该文件可能显示以下状态之一:
- Not affected:处理器不受影响
- Vulnerable:处理器存在问题但未启用防护
- Vulnerable: Clear CPU buffers attempted, no microcode:处理器存在问题且微码未更新,内核尝试最佳防护
- Mitigation: Clear CPU buffers:处理器存在问题且已启用CPU缓冲区清除防护
对于存在问题的系统,还会追加显示SMT(超线程)状态信息:
- SMT vulnerable:SMT已启用且未防护
- SMT mitigated:SMT已启用且已防护
- SMT disabled:SMT已禁用
- SMT Host state unknown:内核运行在虚拟机中,宿主机SMT状态未知
防护机制详解
OpenVelinux内核为MDS问题提供了多层次的防护措施:
1. CPU缓冲区清除
核心防护机制是在以下场景清除CPU内部缓冲区:
- 返回用户空间时
- 进入客户机时
- 空闲状态进入时(仅对MSBDS变种需要)
对于仅受MSBDS影响的处理器,用户空间、客户机和空闲状态转换的防护已足够,不需要额外处理SMT。
2. 虚拟化场景防护
宿主机到客户机的防护取决于处理器的L1TF问题状态:
-
受L1TF影响:
- 如果启用了L1D刷新防护且微码已更新,则自动获得防护
- 否则需要显式启用MDS防护
-
不受L1TF影响:
- 当宿主机MDS防护启用时,进入客户机前会刷新CPU缓冲区
3. XEON PHI处理器特殊处理
XEON PHI系列仅受MSBDS影响,且攻击可能通过用户空间的MWAIT指令实现。可通过内核命令行参数ring3mwait=disable关闭此功能。由于XEON PHI不受L1TF影响,不需要禁用SMT即可获得完全防护。
4. SMT控制
除MSBDS外,其他MDS变种都能跨超线程攻击。因此对大多数受影响处理器,完全防护需要禁用SMT。这会带来性能影响,需根据工作负载类型权衡。
内核命令行参数配置
通过mds=参数可控制防护措施:
| 参数值 | 作用 |
|---|---|
| full | 启用所有防护措施,包括用户空间和VM进入时的缓冲区清除,但不自动禁用SMT |
| full,nosmt | 启用全部防护并禁用SMT,提供完全防护 |
| off | 完全禁用MDS防护 |
不指定该参数等价于mds=full。对于同时受TAA和MDS影响的处理器,仅设置mds=off而不同时设置tsx_async_abort=off将不会生效,因为两者使用相同的防护机制。
防护策略选择指南
-
可信用户空间环境:如果所有应用都来自可信源且不执行外部代码,可考虑禁用防护
-
可信客户机的虚拟化环境:与可信用户空间同理
-
不可信客户机的虚拟化环境:防护效果取决于L1TF防护状态。启用MDS防护并禁用SMT可防止客户机间和客户机到宿主机的攻击
默认防护策略
OpenVelinux内核默认对受影响处理器启用CPU缓冲区清除防护,但不会自动禁用SMT。这与L1TF的默认策略一致,需要在安全性和性能间取得平衡。对于运行不可信代码的SMT系统,管理员应手动禁用SMT以获得完全防护。
通过全面了解MDS问题原理和OpenVelinux提供的防护机制,系统管理员可以根据实际环境需求制定适当的安全策略,在安全性和性能之间做出合理权衡。
kernelopenEuler内核是openEuler操作系统的核心,既是系统性能与稳定性的基石,也是连接处理器、设备与服务的桥梁。C037
Kimi-K2-ThinkingKimi K2 Thinking 是最新、性能最强的开源思维模型。从 Kimi K2 开始,我们将其打造为能够逐步推理并动态调用工具的思维智能体。通过显著提升多步推理深度,并在 200–300 次连续调用中保持稳定的工具使用能力,它在 Humanity's Last Exam (HLE)、BrowseComp 等基准测试中树立了新的技术标杆。同时,K2 Thinking 是原生 INT4 量化模型,具备 256k 上下文窗口,实现了推理延迟和 GPU 内存占用的无损降低。Python00
kylin-wayland-compositorkylin-wayland-compositor或kylin-wlcom(以下简称kywc)是一个基于wlroots编写的wayland合成器。 目前积极开发中,并作为默认显示服务器随openKylin系统发布。 该项目使用开源协议GPL-1.0-or-later,项目中来源于其他开源项目的文件或代码片段遵守原开源协议要求。C00
PaddleOCR-VLPaddleOCR-VL 是一款顶尖且资源高效的文档解析专用模型。其核心组件为 PaddleOCR-VL-0.9B,这是一款精简却功能强大的视觉语言模型(VLM)。该模型融合了 NaViT 风格的动态分辨率视觉编码器与 ERNIE-4.5-0.3B 语言模型,可实现精准的元素识别。Python00
GLM-4.7GLM-4.7上线并开源。新版本面向Coding场景强化了编码能力、长程任务规划与工具协同,并在多项主流公开基准测试中取得开源模型中的领先表现。 目前,GLM-4.7已通过BigModel.cn提供API,并在z.ai全栈开发模式中上线Skills模块,支持多模态任务的统一规划与协作。Jinja00
agent-studioopenJiuwen agent-studio提供零码、低码可视化开发和工作流编排,模型、知识库、插件等各资源管理能力TSX0114
Spark-Formalizer-X1-7BSpark-Formalizer 是由科大讯飞团队开发的专用大型语言模型,专注于数学自动形式化任务。该模型擅长将自然语言数学问题转化为精确的 Lean4 形式化语句,在形式化语句生成方面达到了业界领先水平。Python00