文章提交注意事项：
请在发布文章时用HTML代码加上至少一条新闻来源的链接；原创性消息，可加入相关信息（如涉及公司的网址）的链接。有任何问题，邮件至：he.fang#zhiding.cn
注意：收到邮件乱码的用户请修改客户端的默认字体编码，从"简体中文（GB2312）"修改为"Unicode（UTF-8）"。
solidot新版网站常见问题，请点击这里查看。
Solidot 公告
投 票
热门文章
-
- 特朗普赦免赵长鹏 (0)
- 耐药菌发展速度快于抗生素 (0)
- 富士通推出了内置蓝光光驱的新笔电 (0)
- 无人机被用于投箭射杀动物 (0)
- Django 6.0 beta 1 释出 (0)
- ROG Xbox Ally 的 Linux 性能超过 Windows (0)
- 亚马逊上草药类书籍可能多达 82% 是 AI 写的 (0)
- CS2 饰品暴跌市值蒸发逾 30 亿美元 (0)
- 新晋诺奖得主开发出持久性调节性T细胞 (0)
- 2023 年海洋热浪导致佛罗里达造礁珊瑚功能性灭绝 (0)
热门评论
- 样本数太少 没有参考意义 (1 points, 一般) by Craynic 在 2025年09月22日13时13分 星期一 评论到 梵蒂冈的 Flathub 软件包人均安装量最高
- 杞人忧天 (1 points, 一般) by cnma_001 在 2025年08月15日12时04分 星期五 评论到 你一生中被小行星砸到的概率
- 垃圾Paypal... (1 points, 一般) by devfsdvyui 在 2025年07月17日20时13分 星期四 评论到 Valve 在支付公司压力下移除部分成人游戏
- 建议下次不要用动漫这种容易误解的词 (1 points, 一般) by solidot1550041775 在 2025年07月09日15时24分 星期三 评论到 Netflix 称其全球订户有五成看动漫
- 所以应该吃生肉吗 (1 points, 一般) by Craynic 在 2025年07月09日13时25分 星期三 评论到 研究称加工肉没有食用的安全量
- 居然只有95% (1 points, 一般) by Craynic 在 2025年06月30日13时03分 星期一 评论到 日本争议夫妇别姓法案
- 搞反了 (1 points, 一般) by Craynic 在 2025年06月25日18时46分 星期三 评论到 智能手机是人类的寄生物
- 中心思想归纳 (1 points, 一般) by 18611782246 在 2025年05月15日10时37分 星期四 评论到 研究发现要求 AI 聊天机器人给出简洁答案会显著增加幻觉可能性
- 希望能比印度猴子写得好 (1 points, 一般) by Craynic 在 2025年05月06日13时21分 星期二 评论到 微软 CEO 声称该公司三成新代码是用 AI 写的
- 如果这么干的话 (1 points, 一般) by Craynic 在 2025年04月28日13时13分 星期一 评论到 苹果计划将印度制造的 iPhone 出口到美国以避开关税
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内核加固等议题。”
