对于系统编程语言应该是越安全越好

编程语言数百种，哪种才是最安全的？

此前我们讨论过主动解决内存安全问题的必要性。显然仅通过工具和指导无法阻止这类漏洞。十多年来，内存安全问题与CVE（常见漏洞披露）的比例非常接近。我们认为，使用内存安全语言可以通过工具和培训无法实现的方式来缓解这种情况。

内存安全是编程语言的一种特性，在拥有内存安全的编程语言中，所有的内存访问都有明确的定义。目前使用的大多数编程语言都通过某种形式的垃圾回收实现了内存安全。然而，无法承受垃圾收集器那般繁重的运行时的系统级语言（即用于构建其他软件所依赖的底层系统的语言，比如OS内核、网络栈等）通常都不是内存安全的。

微软修复并指定了CVE的安全漏洞中，大约70%的根本原因都是内存安全问题。尽管我们采取了缓解措施，包括严格的代码审查、培训、静态分析等等。虽然许多有经验的程序员可以编写正确的系统级代码，但很明显无论采用何种缓解措施，使用传统的系统级编程语言编写内存安全的代码几乎是不可能的。

该漏洞的修复很简单：将“偏移检查”移动到距离使用时更近的地方。问题在于，复杂的代码库中很容易出现这个错误，而且简单地重构代码也可能会再次引发这个漏洞。现代C++++提供了span来强制执行数组访问的边界检查。然而，不幸的是这不是默认值，所以是否使用span完全依赖于开发人员。因此在实践中很难强制使用这种结构。

如果编程语言能够自动跟踪和验证大小，那么程序员就不必再担心正确实现这些检查，而我们也可以确定我们的代码中不存在这些问题。时间内存安全指的是确保指针在解引用时仍然指向有效的内存。

这个错误的原因是，太多的复杂API互相交互，程序员无法强制整个代码中的内存所有权。在[0]处，程序获取指向JavaScript对象拥有的对象指针。然后在[1]处，由于语言的复杂性，代码需要执行更多的JavaScript代码才能获取另一个变量。在[2]出，它会使用该缓冲区和宽度，使用该指针的内容来创建新的JavaScript对象。

程序同时使用了垃圾回收和手动内存管理。垃圾回收器会跟踪JavaScript对象，但它并不知道是否有指针指向对象的内部。由于VarToInt重入了JavaScript，JS程序可以修改状态，并清除在[1]处创建过别名的那个指针的所有权。这个漏洞与迭代器失效bug类似，当状态被修改时，所有指向JavaScript内部状态的指针都可能变成无效指针。但是在浏览器这样复杂的程序中，用静态方式来确保不发生该bug几乎不可能。该问题的根源在于给指向可修改状态的指针添加别名。C和C++没有相应的工具来防止这种错误。但是，我们建议始终使用“智能指针”来跟踪内存所有权。

当同一个进程中的两个或多个线程同时访问同一个内存地址，且至少有一个访问是写 *** 作，而且线程没有使用任何明确的锁 *** 作来控制对该内存的访问时，就会发生数据竞争。在多线程访问共享数据的情况下，保持空间和时间的内存安全变得更加困难，而且更易于出错。即使只在非常小的一段时间内共享没有同步的内存，也有可能被其他线程修改数据，而被修改的数据正是引用其他内存地址的数据。这就是检查时/使用时（TOCTOU）漏洞的原因之一，其会导致空间和时间内存安全漏洞。

Jordan Rabet在Blackhat 2018上披露的VMSwitch漏洞演示了数据竞争可能造成的影响。这段代码在虚拟机给宿主发送特定消息时被调用。这意味着，它可以以并行方式调用，来处理其他控制消息和数据包。这样做是有问题的，因为控制消息的处理函数使用的信息在被修改时没有进行任何锁 *** 作[0]。

解决本文提出的几个问题需要几种不同的度量。C++中的“现代”结构（如span）至少可以防止某些类型的内存安全问题，而其他的现代C++特性（如智能指针）应当尽可能使用。但是，现代C++依然不是完全内存安全、完全没有数据竞争的语言。更糟糕的是，这些特性使用与否，完全依赖于程序员“做正确的事情”，在大型、模糊的代码库中几乎不可能强制这一点。C++也没有能够用安全的抽象来包裹不安全代码的工具，意味着尽管在局部可以强制正确的编程习惯，但用C或C++构建安全的组件将极其困难。

除此之外，软件还应当尽可能转移到完全内存安全的语言，如C#或F#等通过运行时检查和垃圾回收来保证内存安全的语言。毕竟，除非必要，否则不应当涉足复杂的内存管理。如果出于速度、控制和可预测性等合理的理由而使用C++，那么可以考虑转移到内存安全的系统编程语言上。