80% 的问题：RunSafe 揭示隐藏的 AI 风险

嵌入式系统的悄然革命刚刚开始喧嚣起来。根据 RunSafe Security 发布的 2025 年最新报告，80.5% 的嵌入式工程师现在正在使用 AI 工具编写代码，而令人震惊的 83.5% 已将 AI 生成的代码直接部署到生产环境中。

在任何其他行业，这将是生产力的胜利。但在嵌入式系统领域（代码控制胰岛素泵、工业电枢和汽车制动系统），它代表了速度与有效性的可怕脱钩。

这份题为“嵌入式系统中的人工智能：人工智能就在这里。安全并不存在”的报告描绘了一个处于危险拐点的行业的景象。工程师编写代码的速度比以往任何时候都快，使用的语言从未被设计为安全的，并将其部署到不易修补的硬件中。

技术深入探讨：为什么“好”代码会崩溃

代码质量不是主要问题。 LLM 生成有效的语法。

问题在于，C 和 C++ 本质上是不安全的语言，需要开发人员保持高度警惕，而人工智能模型（概率令牌预测器）无法在结构上保证这一点。

内存安全漏洞

在现代高级应用程序（用 Python、Rust 或 Go 编写）中，语言运行程序处理内存分配。你创建一个对象；系统找到空间。你停止使用它；垃圾收集器释放它。

在嵌入式 C/C++ 中，您是垃圾收集器。您手动分配内存 (malloc) 并手动释放它 (free)。如果你犯了一个错误，你不仅会得到一个错误，还会得到一个错误。你创造了一个漏洞。

RunSafe 报告强调，这种“手动变速箱”方法正在与人工智能速度发生冲突。当 AI 为 JSON 流生成 50 行解析器时，它通常使用标准、高效的 C 模式。但它很少考虑内存布局的“上下文”。

• 缓冲区溢出：AI 将数据写入缓冲区，而没有严格检查数据是否合适。在桌面应用程序中，这会使程序崩溃。在没有 MMU（内存管理单元）的嵌入式控制器中，这会覆盖指令指针并使攻击者能够控制设备。
• 释放后使用 (UAF)：AI 正确地释放了指针，但在代码中的其他地方留下了对其的悬空引用。随后，逻辑尝试访问已释放的内存。如果攻击者向堆中喷洒了恶意数据，他们现在就拥有了执行权。

攻击面乘数

由于“表面积”，报告中的统计数据令人震惊。 53% 的受访者将安全性视为他们最关心的问题，但 91% 正在增加对嵌入式安全性的投资。他们知道浪潮即将来临。

传统开发是代码量的自然节流器。人类工程师每天只能编写这么多行 C++，优秀的团队会审查这些代码。 AI取消油门。该行业现在正在向遗留代码库注入大量新的、未经验证的逻辑。

如果人类代码的万分之一存在严重的内存缺陷，而人工智能可以让工程师在编写 10,000 行代码的时间内编写 100,000 行代码，那么该行业不仅提高了生产力，而且还提高了生产力。它使潜在漏洞的密度增加了一个数量级。

背景历史：疏忽的模式

业界以前看过这部电影，只是在不同的屏幕上。

2000 年代初，物联网热潮的“连接一切”阶段催生了 Mirai 僵尸网络。制造商争先恐后地将 IP 堆栈安装在摄像机和 DVR 上，而没有考虑默认密码或开放的 telnet 端口。结果是用受损的烤面包机和网络摄像头构建了大规模的 DDoS 基础设施。

2010 年代，汽车行业急于为汽车添加信息娱乐和连接功能。结果就是 Jeep Cherokee 黑客事件，研究人员远程终止了高速公路上车辆的传输，因为娱乐系统可以与 CAN 总线通信。

现在，到 2025 年，代码生成将再次发生这种情况。 RunSafe 报告指出，73% 的工程师将 AI 代码的风险评为“中等或更高”，但部署数字 (83.5%) 表明他们无论如何都会继续进行。

提供“智能”功能（预测性维护、边缘人工智能处理、语音接口）的经济压力正在压倒确保这些功能所需的工程学科。

对策：加载时函数随机化 (LFR)

如果对代码的信任是不可能的（因为代码太多）并且一夜之间将 30 年的 C++ 重写为 Rust 也不可行，那么防御是什么？

该报告指出了运行时弹性。如果您假设该错误存在，则必须使其无法被利用。

嵌入式领域最有效的技术之一是加载时函数随机化 (LFR)。

它是如何运作的

在标准固件编译中，每个函数都位于静态的已知地址中。 calculate_voltage() 可能始终位于 0x08001234。

攻击者喜欢这个。要构建漏洞利用程序（例如面向返回的编程或 ROP），他们需要确切地知道跳转到哪里来执行他们想要的代码。他们将现有代码（小工具）的小片段链接在一起来构建恶意程序。

LFR 打破了这条链条。

1. 编译时：编译器发出的代码不会跳转到绝对地址。相反，它跳转到“存根”或查找表。
2. 加载时间：设备启动时，安全加载程序会洗牌。它随机地将实际内存地址分配给所有函数。
3. 修补：加载程序更新查找表或修补内存中的二进制文件，以便调用仍然有效。

结果呢？每次设备重新启动（或每次更新固件，具体取决于实现）时，内存映射都会发生变化。在设备 A 上起作用的漏洞会使设备 B 崩溃。昨天起作用的漏洞在重新启动后将不起作用。

RunSafe 对该技术的专有实现正在获得关注，因为它不需要重写源代码。您可以在二进制级别应用它。这对于已经尝试使用运行时保护的 60% 受访者来说至关重要。

前瞻性分析：5 年展望

2025 年报告是过渡期的缩影。该行业目前正处于人工智能代码生成的“狂野西部”阶段。

未来五年预计将发生三大转变：

1. 基于芯片的安全性的兴起：LFR 等软件缓解措施实际上将成为强制性的。法规（类似于欧盟的网络弹性法案）可能会要求关键基础设施设备具有二进制随机化功能。
2. Rust 过渡：虽然 AI 可以轻松编写 C++，但它也可以轻松编写 Rust。随着人工智能处理样板文件，切换到内存安全语言的阻力将会减少。但是，这仅保护新代码。遗留的数十亿行 C/C++ 仍然存在。
3. 责任转移：由于人工智能生成的代码会导致物理故障（例如，机械臂摆动太快、电池管理系统故障），因此法律对话将从“软件错误”转向“产品责任”。如果制造商在没有人工审查或运行时保护的情况下使用人工智能生成安全关键代码，那就是疏忽。

底线

RunSafe 安全 2025 报告不仅仅是调查的集合；这是警告弹。业界已经打开了人工智能生产力的瓶颈，并且无法再将其放回去。

所生成的代码数量之大意味着大规模的手动审查在数学上是不可能的。不再可能假装每个错误都可以被捕获。唯一可行的前进道路是假设代码被破坏并构建拒绝让它破坏机器的系统。

对于 2025 年的嵌入式工程师来说，工作不再仅仅是编写 C。它正在构建遏制领域，以防止 C 伤害任何人。

数学附录：利用概率

对 LFR 的值进行建模需要计算 ROP 链成功利用的概率 P。标准链需要 k 个小工具。在静态内存映射中，在已知位置找到小工具 i 的概率为 1。

静态利用的概率实际上是 100%。

使用 LFR，如果一个函数有 N 个可能的位置（槽），并且攻击者有 N 个机会猜测每个独立小工具（简化模型）的正确偏移量，则概率大致下降到 **1 除以 N 的 k 次方。

概率实际上为零。

即使熵适中（N=256）和短链（k=3），难度也会从确定性飙升至千分之一。

资料来源 (6)

• runsafesecurity.com RunSafe Security Blog
• themanufacturingconnection.com The Manufacturing Connection
• vmblog.com VMblog 2025 Predictions
• runsafesecurity.com Medical Device Cybersecurity Index 2025
• news.mit.edu MIT News: Memory Safety Tipping Point
• appsecengineer.com Defending Memory Corruption