肯·汤普森在1983年图灵奖演讲中提出了编译器后门问题，通过修改C编译器二进制文件，可在编译"login"程序时植入后门且不留源码痕迹。文章展示了如何实际运行这个被篡改的编译器，揭示了软件供应链安全的古老隐患。

运行《对信任的信任的反思》编译器

供应链安全是当今的热门话题，但它其实是个古老的问题。1983年10月，40年前的这一周，肯·汤普森（Ken Thompson）选择供应链安全作为他的图灵奖演讲主题，尽管当时还没有这个特定术语。他的演讲后来发表在《ACM通讯》上，题为《对信任的信任的反思》。这是一篇经典论文，篇幅很短（3页）；如果你还没读过，应该去读一读。

在演讲中，肯通过三个步骤解释了如何修改C编译器二进制文件，使其在编译"login"程序时插入后门，且不在源代码中留下任何痕迹。本文将使用肯的实际代码来运行这个被植入后门的编译器。

三个关键步骤

1. 编写自复制程序
   第一步是编写一个能打印自身源代码的程序。这种程序在计算领域被称为"quine"（奎因）。例如，这是一个Python的quine： python s='s=%r;print(s%%s)';print(s%s)

2. 编译器学习机制
   第二步是注意到当编译器编译自身时，某些重要细节可能只存在于编译器二进制文件中，而不在源代码中。肯以C字符串中转义序列的数值为例说明了这一点。

3. 植入后门
   第三步是将前两步结合起来，使编译器"学会"错误编译目标程序（演讲中的login）。关键技巧是：

   • 识别login并插入后门
   • 识别编译器自身并插入这两处修改的代码

实际运行代码

在2023年南加州Linux博览会上，肯透露他仍然保留着这段代码。通过电子邮件联系后，他发送了一个名为nih.a的加密文件。这个代码可以干净地应用到研究Unix第六版（V6）的C编译器上。

通过在线模拟器，我们可以实际运行这段代码。操作步骤包括： 1. 登录系统（用户ken，密码ken） 2. 提取nih.a档案文件 3. 查看和修改源代码 4. 构建"邪恶"编译器 5. 安装并测试后门

历史背景与影响

这段代码可以追溯到1974年6月至1975年6月之间。虽然它没有被用在V6中，但档案文件记录了每个文件的修改时间。

关于后门部署的故事已被公开讲述多次。根据这些讲述，后门被PWB小组（而非有时报道的USG）复制，最终导致该系统的login程序也被植入后门。PWB发现异常是因为编译器每次编译自己时都会变大，最终他们破坏了复制机制，得到了干净的编译器。

现代启示

1. 代码量惊人地少
   后门实现仅需99行代码，外加一个20行的shell脚本。看到它实际运行，以及它有多小多简单，真正让人意识到这种修改有多容易，也凸显了使用可信来源构建的重要性。

2. Go语言的引导
   Go编译器现在可以自行编译，但我们从不要求编译器必须重建自身。相反，编译器总是从早期发布的版本构建。这样任何人都可以从Go 1.4（用C编写）开始，逐步构建后续版本，没有环节需要编译器必须编译自身，也就没有地方可以隐藏仅二进制形式的后门。

3. 信任的引导
   自1983年以来，我们已经知道一种防御这种后门的方法：用两种不同的方式构建编译器源代码。这种方法被称为"多样化双重编译"（diverse double-compiling）。

4. 可重现构建
   任何通过重建源代码来验证二进制文件的方法都依赖于构建的可重现性。现代系统在这方面面临诸多挑战，如嵌入文件名、当前时间、当前目录等不必要的信息。

5. 现代安全状况
   在某种程度上，计算安全性自1974年6月空军关于Multics的报告以来已经退步。半个世纪后，我们都在运行没有源代码的二进制文件。即使源代码可用，如Linux等开源操作系统，也几乎没有人检查分发的二进制文件是否与源代码匹配。

肯在图灵演讲的最后说道："道德是显而易见的。你不能信任那些不是你完全自己创建的代码。（尤其是那些雇佣像我这样的人的公司的代码。）任何源代码级别的验证或审查都无法保护你免受不可信代码的影响。"

虽然我们的安全状况看起来可能很糟糕，但考虑到我们所有的鲁莽行为，实际出现的问题比预期的要少得多。也许我们的安全姿态比看起来要好。尽管如此，如果能生活在一个唯一可能的攻击都需要肯那种复杂方法的世界里，可能会更好。我们仍然有工作要做。

评论总结：

1. 关于"信任的反思"的讨论：

• 有用户提出对经典论文《Reflections on Trusting Trust》的反思
• "Reflections on Trusting 'Reflections on Trusting Trust'?"（评论2）

2. 关于LLM能力的探讨：

• 有用户好奇LLM是否能在特定条件下生成类似内容
• "Would be fun to see if an llm could produce this"（评论3）

3. 关于开源系统二进制验证的现状：

• 有用户指出原文关于无人验证二进制文件的说法已不准确
• "This was not the case in 2023 for Arch Linux...and is also not the case for Debian since 2024"（评论4）
• 提供了Arch Linux和Debian的可重现构建项目链接作为证据

4. 相关讨论链接：

• 评论1提供了原始讨论的链接
• "Discussion at the time: https://news.ycombinator.com/item?id=38020792"（评论1）

注：所有评论均未显示评分（None），因此无法评估认可度。