文章提交注意事项：
请在发布文章时用HTML代码加上至少一条新闻来源的链接；原创性消息，可加入相关信息（如涉及公司的网址）的链接。有任何问题，邮件至：he.fang#zhiding.cn
注意：收到邮件乱码的用户请修改客户端的默认字体编码，从"简体中文（GB2312）"修改为"Unicode（UTF-8）"。
solidot新版网站常见问题，请点击这里查看。
Solidot 公告
投 票
热门文章
-
- 英伟达据报上调 GPU MSRP 5-15% (0)
- 日产计划裁员两万人 (0)
- 猫为什么比狗长寿？ (0)
- Firefox 源代码迁移到 GitHub (0)
- 气候危机威胁香蕉 (0)
- 西部数据投资声称能将数据保存 5000 年的德国公司 (0)
- Google 测试用 AI Mode 取代 I’m Feeling Lucky 按钮 (0)
- 粘性天然聚合物能清除水中的大多数微塑料 (0)
- Telegram 封禁被指洗钱高达 84 亿美元的新币担保 (0)
- 微软裁员 3% (0)
热门评论
- 笑看外挂 (1 points, 一般) by cnma_001 在 2025年04月03日13时47分 星期四 评论到 韩国游戏工作室竞争开发星际争霸新作
- 一个数据参考 (1 points, 一般) by hhding 在 2025年03月31日09时06分 星期一 评论到 AI 数据中心太多了
- 非技术的说法 (1 points, 一般) by hhding 在 2025年03月31日08时56分 星期一 评论到 AI 数据中心太多了
- 主体错误 (1 points, 一般) by solidot1740402558 在 2025年02月24日21时10分 星期一 评论到 Starlink 面临越来越多的竞争
- 先能过了小米高考再说 (1 points, 一般) by ooxx 在 2025年01月06日15时43分 星期一 评论到 小米修改了引导程序解锁政策
- (1 points, 一般) by 18611782246 在 2024年12月18日18时06分 星期三 评论到 司机死于阿尔茨海默病的可能性较低
- BaD kEyBoArD: eXtRa SpAcE (1 points, 一般) by lot 在 2024年12月11日04时10分 星期三 评论到 高温环境可能加速衰老
- BaD kEyBoArD: tYpO (1 points, 一般) by lot 在 2024年12月11日04时09分 星期三 评论到 Goolge 宣布了新量子芯片 Willow
- 喵喵喵 (1 points, 一般) by solidot1733326472 在 2024年12月04日23时35分 星期三 评论到 澳大利亚面临太阳能供大于求
- 懂了 这就去安装刺客信条 (1 points, 一般) by Craynic 在 2024年11月27日19时36分 星期三 评论到 微软临时阻止安装刺客信条等育碧游戏的 PC 更新 Windows 11 24H2
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内核加固等议题。”
