solidot新版网站常见问题,请点击这里查看。
安全
Wilson(42865)
发表于2025年05月09日 19时20分 星期五
来自光明之子
Shawn the R0ck 写道:“Memory safety 近年来成为热门话题。但在讨论“memory safety”时,我们需要先明确究竟在探讨什么、追求什么目标。你是在关注通过编译器完成静态分析(如 Clang Static Analyzer、rustc 等)来在编译阶段捕获潜在问题,还是更信任编译器让代码顺利编译,通过运行时机制(比如 Go 或 Java 中的垃圾回收)来解决所有问题?或者,你仅仅关注于安全加固的最终目标——即防止系统遭受攻击?内存安全问题的复杂性正反映了安全领域的本质:安全是一门交叉学科,融合了计算机科学和复杂性理论,这使得要完全掌控其复杂性变得异常困难。因此,企图通过单一或者几种 “memory-safe language” 重写现有软件,从而彻底杜绝所有安全隐患,并非现实可行的方案。
一门编程语言在设计时可能就倾向于提供内存安全机制,例如自动垃圾回收、数组边界检查等,这些机制在规范层面上勾画了一个理想状态。但在现实中,不同的实现者会出于需求和性能指标的考虑采取不同的策略。例如,虽然 Lisp 通常配备垃圾回收机制、支持灵活的数据操作和动态类型系统,但这并不意味着所有 Lisp 解释器都能完全消除内存安全问题。如果由于特定需求或追求性能而对部分安全检查作出妥协,那么内存越界或非法指针访问等安全隐患依然有可能出现。
同样,C/C++ 被长期视为“不安全”的语言,因为它允许程序员直接操作内存和执行指针运算。然而,通过严谨的工程化手段(如静态分析工具、严格的代码审查、运行时检测机制等),使得 C/C++ 在特定环境下无限接近无 Bug 状态也是可能的。本文将以 HardenedLinux 过去数十年中在对抗系统复杂性、提升内存安全方面的一些做法为背景进行探讨。总体来看,内存安全不仅关乎编译器或运行时单一环节的责任,而是需要在语言设计、工具支持、工程实践等多方面协同努力,以实现最终“系统不被攻陷”的安全目标。本文不涉足强制访问控制,沙箱,Linux内核加固等议题。”