SSM 能否可靠地防止缓冲区溢出？

它没有声称提供 100% 的预防，但与以前基于硬件的解决方案（通常具有页面粒度）相比，它确实提供了更细粒度的保护，并且比具有相似粒度的基于软件的保护具有更好的性能。有一些限制，例如

• 您的代码必须实际使用它。这可以像使用提供的 malloc 一样简单，但是需要更改像在 OpenSSL 中所做的自定义内存分配。而且我不知道编译器是否也会向堆栈添加这种保护，或者这是否仅适用于在堆上分配的数据。
• 内存必须对齐到 64 字节。因此它不会检测到您何时溢出仅 32 字节的分配。
• 每个 64 字节区域只有 16 种颜色（4 位）可用。因此，一些随机指针与受保护的内存区域具有相同颜色的机会仍然是 6%。

因此，它并不完美，但与现有解决方案相比，及早发现问题从而防止攻击的机会要高得多，至少在相同性能级别的解决方案中是这样。

解决缓冲区溢出的早期尝试（例如 DEP）

在我看来，DEP 根本不能防止缓冲区溢出，而只是确保不能简单地执行写入堆栈或堆的代码。因此，它只处理一些利用成功缓冲区溢出的可能方法，而 SSM 可以帮助防止溢出本身。

作为对这里其他答案的补充，我将指出两个额外的问题，在The Register的这个项目中指出：

第一： 即使攻击者的代码错误地猜测了它需要在其恶意指针中使用的“颜色”（并且至少在这种情况下，16 分之一的机会得到正确的可能性并不是很微不足道）和异常来自处理器会导致相关应用程序崩溃，这在许多情况下可能还不够好。目标将需要安全或日志监控软件来（a）查看崩溃已经发生并识别它的特殊原因，以及（b）至少向管理员发出有关攻击的警报。（当然，最好是在目标服务器上安装一个复杂的基于主机的 IDPS，既能够识别触发异常的漏洞利用代码，又能够自动采取对策，防止它在进一步的攻击中再次运行。

另一方面，如果应用程序崩溃没有引起注意，并且崩溃的实例只是自动重新实例化足够多次，最终攻击者的代码将达到 16 分之一的机会匹配它想要的 64 位内存块的颜色加载。绕过这道防线。换句话说，如果您不注意您的应用程序和服务器在做什么，您仍然很可能会被烧毁。（是的，呃。）

第二： 如果攻击者能够找出某种方法来辨别他/她想要加载的特定内存块的颜色是什么或将是什么，那么攻击者可能（可能）只是能够简单地将指针设置为该颜色。新的保护措施在多大程度上容易受到这些方面的攻击？好吧，要开始回答这个问题，可能需要更多的技术细节，而不是目前看来关于这一切如何运作的更多细节。（加上一个比我更了解 SPARC 的方式、方式、方式的回答者。）

尽管如此，即使存在上述问题/限制，这是一个非常有趣的基于硬件的安全措施，它似乎比硅制造商其他架构（咳……英特尔……ARM……咳）正在尝试的更雄心勃勃立即改善内存保护。（即使为内存块提供保护密钥/检查信息的一般概念并不是什么新鲜事。）看看这对 Oracle 商店来说在漏洞利用保护（如果有的话）方面有多少真正的、积极的差异真的会很有趣。 .