G.O.S.S.I.P 阅读推荐 2026-09-04 龙之逆鳞
原创 G.O.S.S.I.P 2026-09-04 18:38 上海
关于USENIX Security 2026会议论文中龙芯相关安全漏洞的非官方介绍~
很多人都听说过龙芯，但是真正使用过龙芯的用户恐怕不多，而G.O.S.S.I.P在去年就已经入手了3A6000，实测下来FFMpeg还是可以用的，虽然速度略慢一点。
不过我们发现，现实中最为关心龙芯安全问题的不光是国内的用户，欧洲的安全研究人员也在关注着这款新架构CPU的安全（好事啊！）而在刚刚过去的USENIX Security 2026会议上公开的论文 LoongLeak: Architectural Cross-Privilege-Boundary Data Leakage on LoongArch CPUs 中，作者具体讨论了关于龙芯CPU的龙架构（LoongArch）存在的一个侧信道安全问题：
首先说一句，技术问题本身就是很纯粹的，但是在国内好像有时讨论技术就变了味，非要扯上什么大义凛然或者孰强孰弱甚至阴谋论，充满了敏感的味道，这就很不科学。我们今天还是要从科学的角度来读这篇论文，分析一下问题到底出在哪里。其实如果大家在网上多搜索搜索（嗯，不知道这个年代是不是已经没人用搜索引擎而是都去问AI了），就能看到国内很多专业的回复，比如来自清华大学的陈嘉杰博士在他的个人网站上就写了一篇非常专业的分析，实际上我们可以看到，这个问题在USENIX Security论文发表之前也已经被陈嘉杰博士独立发现了（https://github.com/jiegec/LoongBleed 这里都给出了PoC代码）：
关于这篇论文以及论文提到的LoongLeak漏洞（a.k.a 陈嘉杰博士发现的LoongBleed漏洞），本质上又可以回到2018年开始大家疯狂讨论的Meltdown & Spectre 漏洞的核心问题——CPU在微架构（micro architecture）层面上无法感知到更为上层的操作系统、应用程序设定的隔离机制，底层的硬件只要用了相同的计算和存储部件去执行了不同的（需要被隔离的）代码，就有可能产生信息的共享（也就导致了leak）。这种问题其实非常难修复：硬件工程师优化性能都已经头大了，哪有什么精力去考虑上层系统的安全隔离会不会被破坏啊？
而LoongLeak/LoongBleed漏洞其实只是因为龙芯CPU在执行特定的向量扩展指令（LSX和LASX向量扩展指令集，类似x86 CPU上的SSE、AVX这类指令集）在执行过程中的一个未定义行为：在执行 LSX 指令后，向量寄存器的高位部分可能出现“随机”数值。此事在Chips and Cheese 于 2023 年发布的分析文章 Loongson’s LSX and LASX Vector Extensions 中已有记载（https://chipsandcheese.com/p/loongsons-lsx-and-lasx-vector-extensions 陈嘉杰博士正是受到该文章启发找到了LoongLeak/LoongBleed漏洞）。
在 Chips and Cheese 当时的文章中，作者用“I find undefined behavior interesting”来表达了对这一发现的好奇，而我们知道，未定义的行为一旦被安全研究人员盯上，就有可能产生血淋淋的后果。在USENIX Security论文中，作者测试了LoongLeak/LoongBleed漏洞可能打破的隔离边界，发现敏感的数据只有不同的CPU物理核之间存在隔离，如果不同的代码（不管是内核态、用户态甚至是Hypervisor）在相同的CPU核心上执行了相关操作，数据就可以在这些代码之间通过向量寄存器的高位部分“自由流通”。
在论文中，作者给出了几个具体的例子，展示了磁盘加密的密钥、用户的登录口令Hash都可以用LoongLeak/LoongBleed漏洞提供的信息泄露渠道去获取。这个具体的细节我们就以“安全围栏”的名义忽略不介绍了（偷懒），不过这里比较有趣的是关于LoongLeak/LoongBleed漏洞的具体成因的讨论，实际上论文的作者和陈嘉杰博士并没有达成一致：论文认为数据泄露是由于特定的L1 cache line被读取的时候同时也存储到了向量寄存器中，而后面因为没有清零导致了LoongLeak/LoongBleed漏洞（如下图所示），陈嘉杰博士则认为“这让我们联想到：会不会是寄存器重命名没有清空寄存器——这与 ZenBleed 的机制类似——理论上就可以泄露内核态数据。于是我们做了实验验证这一假设，发现确实如此，并且在龙芯 3A5000 和 3A6000 上都能复现。” 不过论文也好，陈博士的文章也好，都只能是提出hypothesis——因为龙芯底层的硬件实现机理并没有公开的文档可以查到。
回到龙芯这边，龙芯中科还是很得体地回复了针对安全问题的质疑，也明确了这个漏洞的利用条件和危害程度。而在两年前，同样是今天这篇论文的作者发现的GhostWrite安全问题（G.O.S.S.I.P 阅读推荐 2024-08-12 影子写手），那时候可能国内厂商就还不太清楚应该怎么去处理。随着国产化CPU的普及，日后肯定会有更多这样的问题出现，如何做好安全问题的响应肯定也是日后各家厂商需要去学习的重要技能。
讲到最后，我们再介绍一个前段时间由知名的逆向工程研究人员、《x86 Software Reverse‐Engineering, Cracking, and Counter‐Measures》一书的作者Christopher Domas（大家都很喜欢八卦他和他太太，以及他在2026年甚至还有许多头发）发现的奇异现象：在早期的AMD Family 16h 系列处理器（别想了，苏妈上任后的Zen系列是AMD Family 17h 系列处理器，不受影响）中，你按照下面这个gif动画里面的代码去执行，就能触发意想不到的效果：
这里面提到的神秘内存地址0xf80c2094究竟是什么？它又是怎么样打穿了AMD处理器的内存控制器？请看 今天的《走近科学》特别节目之 Spaghettifying DRAM的具体介绍：
论文：https://www.usenix.org/system/files/usenixsecurity26-hetterich-lorenz-loongleak.pdf