使用 C 编程是否因操作系统安全性和执行禁用而变得更容易？

Question

我知道，在过去使用 C 语言时，您可能会搞砸指针和内存分配，并且可能会意外损坏其他正在运行的程序或程序之外的操作系统本身，并导致系统崩溃。这将需要重新启动以收拾残局并继续程序开发。

系统安全性改进是否阻止了这种情况的发生？

在过去的 MSDOS 和 Windows 3.1/95/98/Me 以及 10 版之前的 MacOS 中（通常在抢占式多任务成为一切标准之前）系统安全性通常不存在。程序可以完全控制随时随地写入数据。

但现在随着更现代的系统设计和流程安全性，程序通常会被系统安全性阻止意外或故意损坏其他任何东西。

现代处理器的执行禁用功能也可能有助于防止意外跳转到随机内存位置并将那里的任何内容作为处理器机器代码运行。

那么，在不尝试破解操作系统安全性的情况下，您可以将现代 C 编程搞砸到什么程度？

你还能设法让整个系统意外崩溃吗？我认为这不再可能。内核或其他系统安全介入并停止操作。

您是否会破坏您的登录环境并​​不得不退出并重新登录？我认为这也被阻止了，因为进程通常不应该访问其他进程内存空间，即使在您自己的登录安全环境中也是如此。

总的来说，现在用 C 进行编程似乎比过去容易得多，这只是因为这些系统保护现在无处不在，可以防止你对自己和系统造成伤害。

Answer 1

在你可以不小心做的事情的领域里，它肯定比 MS-DOS 时代更容易了。我记得一个损坏内存磁盘缓存的错误。我很幸运在那之后还剩下什么。

现在，除非您编写在内核中运行的 C 代码，否则这是不可能的。除非您积极尝试利用漏洞，否则通常不会导致操作系统崩溃。

其他各种东西，比如 NX 位和其他类似尝试在 C 程序周围建立一点安全栅栏的尝试，它们确实使您的程序崩溃得更快，并且在更接近错误真正发生的地方崩溃。但它们远不及您通过简单的分隔地址空间获得的胜利水平。它们的设计目的是积极尝试更困难地利用事物，而且它们在这方面的能力远胜于捕捉事故或错误。

并且破坏不同于整个操作系统的登录环境通常在统计上也不太可能。不过，如果您的程序正在执行复杂的文件操作，您可能会遇到一个会弄乱用户文件的错误。

而且，如果没有真正使操作系统崩溃，您可能会意外导致资源耗尽。虽然这通常可以恢复，但它在进行时非常不舒服。您的系统慢到爬行，甚至可能无法启动进程。 Linux对此有一些保护。而且如果你把你的开发环境放在一个cgroup中，你可以完全阻止它。

当然，主动漏洞可以做的任何事情，你都可能犯错。但是，我说的是偶然做这些事情的统计可能性。

可能是最大的改进，因为分离的地址空间是像 Valgrind 这样的工具，可以动态监控程序的越界访问或对已释放内存的访问等。

MS-DOS 和早期的 Windows 非常奇怪，因为它们用作具有高质量 C 开发环境并具有如此混杂内存的通用计算机。 Windows 花了很长时间才超越它，而且该平台上的编程实践仍然有点奇怪。

Answer 2

简短的回答：是的。

在使用虚拟内存并将数据和代码分开的计算机上，编写灾难性错误要困难得多，因为您会遇到硬件异常（操作系统会转换为更软的东西）。所以你不能有错误运行来覆盖你自己的可执行代码，或者有失控的代码开始从数据段执行随机“操作码”。当然，错误仍然存​​在，需要修复。但这不会那么神秘，也不会那么灾难性。

不具备这些安全功能的计算机需要程序员更加小心和测试。

仍然很有可能导致整个系统崩溃，但这主要是因为操作系统和 API 中的错误。 Windows中偶尔出现的“蓝屏死机”仍然是一回事。通过使用 100% 的 CPU 或分配过多的堆内存，您还可以通过一些努力使整个计算机落后，使其几乎无用。