C之父做决定了内部自救！

　　作者千山、言征
　　审校云昭
　　进入2023年，技术圈都在围观大洋彼岸的聊天机器ChatGPT，但对于编程圈而言，没有什么比内存安全更能引起热议。近期美国国家安全局（NSA）点名批评C，建议使用Rust等内存安全的语言，霎时间让编程语言的安全问题摆到桌面上，那么，C到底能扛住这波压力，存活（安全）下来吗？
　　面对来自政府方面的压力，C创建者BjarneStroustrup最终还是低头了。他一改之前的激奋言辞，不再喊话谁谁不懂C、没有看到30多年来C的进步等，而是开始倾向于编程语言也应该与时俱进的说辞，加入了改变编程语言本身以解决安全问题的队伍之中，这一点对其他核心贡献者来说显然出乎意料。
　　安全掉队的C，正在找对策
　　C社区一直存在安全争议，其内存安全漏洞引起了很多开发者的警觉。
　　1月中旬，官方C指导小组发布了一份声明，解决了人们对C安全性的担忧。虽然许多语言现在都支持基本类型安全，即确保变量只访问由其数据类型明确定义的内存部分，但C一直难以提供类似的保证。
　　这个由C创建者BjarneStroustrup共同撰写的新声明现在似乎呼吁改变C编程语言本身，以解决安全问题。我们现在支持这样的想法，即安全性的更改不仅需要在工具中，而且需要在语言编译器和库中可见。
　　指导小组还支持其长期以来首选的调试工具，以确保安全（以及推动工具，以便在识别人类难以识别的安全问题时进行更全面的分析）。但1月份的声明强调了它对C内部变化的建议。
　　具体来说，它建议将几个特性打包到概要文件中（概要文件稍后定义为定义要执行的属性的限制和要求的集合，例如，通过触发自动分析。）
　　这样，新的安全更改应该是可见的，这样安全代码部分就可以被命名（可能使用配置文件），并且可以与普通代码混合。
　　这种新方法最终不仅带来了安全性，还带来了灵活性，其配置文件专门设计用于支持嵌入式计算、性能敏感应用程序或高度特定的问题领域，如汽车、航空航天、航空电子、核或医疗应用程序。
　　指导小组还建议：例如，我们甚至可能有安全嵌入式、安全汽车、安全医疗、性能游戏、性能HPC和欧盟政府法规的安全配置文件。。
　　在文件的其他地方，他们的表述更为简洁。为了支持不止一个‘安全’概念，我们需要能够说出它们的名字。
　　但提议的改变与去年12月与美联邦政府摊牌时出现的想法相呼应。1月中旬的声明指出，一个特别重要的组织，即美国商务部颇具影响力的国家标准与技术研究所，对C的安全性提出了担忧。11月，美国国家安全局（NationalSecurityAgency）也在一份关于软件内存安全的信息表中调用了C（作为其任务的一部分，以识别对各种联邦系统的威胁，并发布网络安全规范和缓解措施）。
　　也许正是这种来自高层的担忧最终埋下了变革的种子
　　国家安全问题
　　美国国家安全局援引了微软和谷歌的分析评估。
　　微软在2019年的一次会议上透露，从2006年到2018年，其发现的70的漏洞都是因内存安全问题造成的；据Google估计，Chrome中存在了类似比例的内存安全漏洞，另外90的Android系统漏洞也都是内存安全问题。
　　他们随后警告称，黑客可以利用这些漏洞进行远程代码执行或其他不利影响，这通常会危及设备，并且成为大规模网络入侵的第一步。因此，无论是内存溢出、内存分配漏洞、还是变量未初始化，所有这些内存问题都太常见了。
　　2019年微软安全演示发现，从2006年到2018年，70的漏洞涉及内存安全
　　显然，软件分析工具和操作环境选项可以发现许多问题，但美国国家安全局仍然建议，在可能的情况下，只使用内存安全语言。
　　为了明确起见，他们将其定义为一种语言，通过运行时和编译时检查，内存作为计算机语言的一部分自动管理；它不依赖于程序员添加代码来实现内存保护。NSA提供了C、Go、Java、Ruby、Rust和Swift等示例。
　　在美国国家安全局看来，常用的编程语言如C，在内存管理方面提供了很大的灵活性，但用这种语言开发的应用程序的安全性很大程度上需要依赖程序员的检测环节。但是只要程序员自身有所疏忽，就可能带来严重的内存安全隐患。尽管不少软件分析工具能够检测到内存管理问题，操作环境选项也可以提供一些防护，但内存安全语言所提供的固有保护可以规避或减轻大多数内存管理问题。
　　去年12月，Stroustrup在开放标准网站上回应称，他并不认为这些语言在我所关心的使用范围内优于C。
　　Stroustrup还反对美国国家安全局对安全的讨论仅限于内存安全，而忽略了一种语言可能（并且将会）被用来违反某种形式的安全和保障的十几种其他方式‘安全’的定义不止一种，我们可以通过编程风格、支持库和通过静态分析执行的组合来实现各种安全。
　　在这一过程中，Stroustrup还提出了第二个论点：在一些性能至关重要的现实场景中，并非所有人都将‘安全’放在首位。因此Stroustrup认为，明智的做法是列出安全问题（包括未定义的行为），然后根据需要使用预执行调试工具（如静态分析器）找到防止这些问题的方法。
　　沿着这些路线，Stroustrup已经在为C调用编译器选项和代码注释，以请求类型安全（和资源安全），说这让你只在需要的地方应用安全保证，并在需要的地方使用你最喜欢的调优技术
　　新提出的配置文件似乎是实现这一目标的一种语言方式。
　　理性看待C的安全性
　　Stroustrup还反对在美国安全局的文件中将C与C混为一谈。他指出，即使是现在，C核心指南也专门致力于为那些需要的人提供静态保证的类型安全和资源安全，而不会破坏代码库，因为这些代码库可以在没有这种强有力的保证或引入额外的工具链的情况下进行管理。
　　微软的VisualStudio分析器（及其内存安全配置文件）以及许多静态分析器已经支持这些核心准则。Stroustrup认为，这种方法允许C完全实现这些保证，而花费的成本只是转向各种新颖的‘安全’语言的一小部分。
　　Stroustrup还引用了他在2021年写的另一篇论文，该论文指出：从1979年开始，完全的类型和资源安全就一直是C的理想（目标），并且可以通过语言规则和静态分析强制执行的明智编程技术实现。（后来Stroustrup写道，解决方案是一套精心设计的编程规则，由库设施支持，并由静态分析强制执行。）
　　论文承认，就其本身而言，默认情况下，核心指南不提供完整的类型和资源安全但认为它可以通过实施额外的规则来保证（例如，由微软VisualStudio发布的核心指南检查器实现）。Stroustrup对Rust基于编译器的类型检查表示认可，他写道：编译器不是我们唯一的工具，从来都不是，并提供了（预编译）静态分析可以执行的强大检查的具体示例。例如，静态分析可以：防止不安全的类型转换防止创建未初始化的对象确保没有内存引用指针转义超出其狭窄定义的范围而错误地指向其他对象
　　在去年12月对美国安全据的回应中，Stroustrup写道，我们生活在一个数十亿行C代码不会神奇消失的世界里，并补充说，逐渐采用这些安全规则（以及在适当的情况下采用不同的安全规则）是很重要的。
　　在某种程度上，美国国家安全局的论文似乎同意其中的一些观点。其文件包括了关于强化用非内存安全语言编写的代码的技巧，推荐了用于静态分析（检查源代码）和动态分析（在代码执行时执行）的工具，以及简化结果的漏洞相关工具。解决这些工具发现的问题可能需要大量的工作，但会产生更健壮和安全的代码。
　　美国国家安全局的文件确实提到了对非内存安全语言使用附加保护所提供的相当大的保护。（它还建议通过控制流保护、地址空间布局随机化和数据执行预防等安全功能强化编译和执行环境。）
　　忆往昔，C做长期主义者
　　在Honeypot的《不为人知的开发者故事》（UntoldDeveloperStories）的一次新采访中，72岁的Stroustrup回顾了自己的学生时代，当他还是个年轻人时，获得了获得了数学和计算机科学硕士学位的他发现自己的数学不如想象中那么好，但机器架构真的很有趣。
　　当被问及，如果有时间机器可以让他回到最初创建C的时候，他最想改变的东西是什么？Bjarne说，现在的他不会比创建C时的那个他更了解那个时代，他做的任何改动可能都无法适应那个内存只有1MB的工作环境，也没法编译到早期的640MBWindows电脑上。
　　编程语言设计的有趣之处在于，如果你成功了，你就拥有了多年前和几十年前所做的一切，你必须忍受它。一旦你得到了用户，你就有责任，其中一个责任就是不破坏他们的代码有数千亿行C代码，我们无法破坏它们。
　　Stroustrup强调了他对C的信心。我认为C可以做Rust可以做的任何事情，我希望它使用起来简单得多。但他在2020年的采访中也表示，基本类型安全确保变量只能访问其清晰划分的内存块是他最早的设计目标之一，也是他花了几十年时间试图实现的目标。
　　没有时间机器，一切犹如开始
　　这位年逾古稀的C创建者，此时虽然已经恢复信心，但对于评论者的言论有些小难过，当我听到人们在谈论C时，这些人就好似回到八九十年代那样（指指点点）。
　　但正如前文所述，世间没有时间机器，C的设计理念也要随着所处的时代一路演进。
　　C在诞生近四十年后，依然保持着强大的生命力。Stroustrup认为保持其稳定性，并追求渐进式进化是必要的。
　　我从一开始就知道，我不可能构建理想的语言，因此我必须以渐进式发展为目标：改进。说真的，我并不相信完美语言的构想：要怎样就算是完美呢？对谁来说（是完美的）？他补充说：为了应对不断变化的世界的挑战，融入新思想，改进是必须的。
　　参考链接：https：thenewstack。iocancbesavedbjarnestroustruponensuringmemorysafety