SEH、访问冲突和堆栈保护页面答案

【问题标题】：SEH, access violation and stack guard pageSEH、访问冲突和堆栈保护页面
【发布时间】：2009-06-14 19:27:48
【问题描述】：

我已经发布了question 关于验证指针的可访问性。结论是要么使用 IsBadReadPtr 检查指针，要么使用 SEH 捕获异常（最好两者都不使用，并调试应用程序，但这不是这里的问题）。

IsBadReadPtr 被认为是坏的，除其他原因外，它会尝试读取指针，并会捕获任何异常。它可能会catch a stack guard page exception，从而阻止它到达内存管理器，这应该扩大了堆栈。

如果我使用 SEH 并且只捕获 EXCEPTION_ACCESS_VIOLATION 异常，这会产生同样的问题吗？

另一件事：使用 SEH 的含义是什么？ This 文章建议“编译器无法在受 SEH 保护的代码中执行流分析”。如果我在 __try 块中调用一个函数怎么样。编译器会不会根本不优化被调用的函数？

【问题讨论】：

另见 OSS-Security 邮件列表上的Qualys Security Advisory - The Stack Clash。它展示了一些巧妙的技巧，以及它对保护页面的诅咒。令人惊讶的是，他们用它删除了多少操作系统。我不禁想知道 Windows 是否也受到影响。

标签： c winapi seh

【解决方案1】：

如果我使用 SEH 并且只捕获 EXCEPTION_ACCESS_VIOLATION 异常，这会产生同样的问题吗？

我想会的。一种解决方法可能是在您开始调用 IsBadReadPtr 之前探测您知道和关心的任何线程的堆栈[s]（通过“探测堆栈”我的意思是故意触摸堆栈中的每个内存页，以确保每个页已预先分配）。

编译器会不会优化调用的函数？

如果函数没有内联，我希望编译器应用通常的优化（函数的优化不会受到函数调用位置的影响）。

【讨论】：

您能否确保您关心的线程上的堆栈已通过调用 CreateThread 以相同的提交值和保留值完全分配？此外，将图像线程堆栈设置设置为匹配。但是，它不适用于由库创建的线程。