文章提交注意事项：
请在发布文章时用HTML代码加上至少一条新闻来源的链接；原创性消息，可加入相关信息（如涉及公司的网址）的链接。有任何问题，邮件至：he.fang#zhiding.cn
注意：收到邮件乱码的用户请修改客户端的默认字体编码，从"简体中文（GB2312）"修改为"Unicode（UTF-8）"。
solidot新版网站常见问题，请点击这里查看。
Solidot 公告
投 票
热门文章
热门评论
- 很正常 (1 points, 一般) by Craynic 在 2026年07月27日13时22分 星期一 评论到 古代语言的多样性远超今日
- 发电不需要油吗 (1 points, 一般) by Craynic 在 2026年06月03日13时51分 星期三 评论到 能源危机推动 37 个国家的电动汽车销量创新高
- 所以firefox 已经路边一条，对用户的需求漠视的结果就是这样了 (1 points, 一般) by solidot1745479987 在 2026年04月20日11时14分 星期一 评论到 Firefox 加入了对 Web Serial API 的支持
- (1 points, 一般) by solidot1775703930 在 2026年04月09日11时09分 星期四 评论到 Sam Altman 能被信任吗？
- 很难想象现代Linux居然还能跑在i486上 (1 points, 一般) by Craynic 在 2026年04月07日19时41分 星期二 评论到 Linux 准备移除对 i486 CPU 的支持
- 很多单词已经不再实用 (1 points, 一般) by Craynic 在 2026年04月07日13时22分 星期二 评论到 人们日常说话的单词量比上一年减少 300 个单词
- 表示方向不还是得有那么多个维度吗 (1 points, 一般) by Craynic 在 2026年03月30日13时35分 星期一 评论到 Google TurboQuant AI 压缩算法大幅减少大模型内存使用
- sora的核心用户是内容创作者 (1 points, 一般) by Craynic 在 2026年03月27日13时16分 星期五 评论到 Sora 为何失败：每天推理成本最高 1500 万美元总收入仅为 210 万美元
- 夏天骑摩托的时候，最喜欢带着有线耳机听相声或小说 (1 points, 一般) by kracker1911 在 2026年03月17日09时36分 星期二 评论到 有线耳机销量暴增
- 不如用网易邮箱 (1 points, 一般) by Craynic 在 2026年03月10日11时20分 星期二 评论到 FBI 通过 Proton Mail 识别抗议者身份
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内核加固等议题。”
一门编程语言在设计时可能就倾向于提供内存安全机制，例如自动垃圾回收、数组边界检查等，这些机制在规范层面上勾画了一个理想状态。但在现实中，不同的实现者会出于需求和性能指标的考虑采取不同的策略。例如，虽然 Lisp 通常配备垃圾回收机制、支持灵活的数据操作和动态类型系统，但这并不意味着所有 Lisp 解释器都能完全消除内存安全问题。如果由于特定需求或追求性能而对部分安全检查作出妥协，那么内存越界或非法指针访问等安全隐患依然有可能出现。
同样，C/C++ 被长期视为“不安全”的语言，因为它允许程序员直接操作内存和执行指针运算。然而，通过严谨的工程化手段（如静态分析工具、严格的代码审查、运行时检测机制等），使得 C/C++ 在特定环境下无限接近无 Bug 状态也是可能的。本文将以 HardenedLinux 过去数十年中在对抗系统复杂性、提升内存安全方面的一些做法为背景进行探讨。总体来看，内存安全不仅关乎编译器或运行时单一环节的责任，而是需要在语言设计、工具支持、工程实践等多方面协同努力，以实现最终“系统不被攻陷”的安全目标。本文不涉足强制访问控制，沙箱，Linux内核加固等议题。”
