编辑：需要明确的是，这个答案解决了“为 32 位 x86 与 x86-64 编译我的应用程序是否更安全？”的问题，并且没有解决哪个硬件更安全的问题。

这是64 位应用程序比 32 位应用程序有任何安全优势的部分副本吗？，但更广泛，而且这个问题也很老了。

在大多数方面，x64 更好。几个原因：

• 因为size_t是 64 位，所以由于加法或乘法而发生整数溢出的可能性要小得多，这使得一些常见的缓冲区溢出情况不太可能发生。
• 由于实际可分配的物理或虚拟内存量远低于SIZE_T_MAX，因此某些可能导致溢出的场景反而会导致内存分配失败，这更容易检测到。例如，如果攻击者可以根据输入字符串的长度在缓冲区中实例化任意数量的 32 字节结构，尝试获取其中的 0x0800 0001 将溢出 32 位size_t而不是 64 位，同时一个长（但不是不可能的长）输入，其中 0x0800 0000 0000 0001 将溢出 64 位size_t，但也将是一个完全不可能的长输入。
• 因为地址空间要大得多，所以可以使用更高熵的 ASLR。使用低熵 ASLR，可以快速多次尝试相同攻击或一次尝试攻击多个受害者的攻击者可能会完全靠运气成功。较小的地址空间有时也会限制加载库的重定位，这也会损害 ASLR。这是上面链接的问题的主要方面。
• 因为 32 位进程只能分配（4GB 内核保留空间）内存，大但有限的内存泄漏或昂贵的分配可能会使它们饿死或崩溃，而 64 位进程会很好（假设有足够的物理 RAM）。

然而，这并不全是有利的。32 位进程的一个优点是行为不端的进程根本无法消耗现代系统上的所有可用 RAM。我曾经发现我的 PC 运行非常缓慢，并意识到这是因为一个聊天应用程序发生了可远程触发的内存泄漏，并且耗尽了我 PC 上所有 32GB 的 RAM。虽然在这种情况下它实际上并不是恶意的，但它是一个清醒的提醒，在后台运行的单个行为不端的应用程序中的错误（或漏洞，即使不能用于代码执行）可能会严重损害整个计算机的功能. 如果应用程序是 32 位的，它只能消耗几 GB，并且机器的性能根本不会受到任何有意义的影响。

但是，实现这一优势的正确方法是使用限制和/或沙箱。所有主要的消费者和服务器操作系统都有方法限制一个进程可以消耗多少资源，这些方法都比简单地依赖 32 位限制更具可定制性，并且可以应用于任何程序，无论它是如何编译的。此外，沙盒可以减少其他漏洞（或不可利用的错误）的影响。