C++沙盒动态库
我想知道是否可以通过 dlopen 和朋友对动态链接库进行沙箱处理。目的是从库中的错误中恢复，而无需拆除整个应用程序，例如 SEGFAULT 等。
有人在这方面有任何经验吗？
I'm wondering if at all it is possible to sandbox a dynamically linked library via dlopen and friends. The aim is to recover from an error within the library without tearing down the whole application e.g SEGFAULT, etc.
Anyone had any experience in this area?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以在调用库之前fork()，然后将结果传递给您的母进程。让母进程等待子进程的数据，如果崩溃则报告错误。
You can fork() before calling the library, then pass the result to your mother process. Let mother process wait for data from child, or report error if it crashes.
一般来说，异常处理高度依赖于操作系统。我将做出一些假设并尝试提供一些通用指导。请注意，这绝不是一个详尽的答复，但应该作为一个起点。
我将假设：
在大多数情况下，您对防止内存泄漏感兴趣。
自从您提到 dlopen（否则您可能会说 LoadLibrary）以来，您对 Windows（这是完全其他的蜡球）不感兴趣
你知道链接 C++ 符号的细微差别。如果您没有阅读关于 dlopen c++ 的迷你指南
一般来说
如果不涉及提供数据和代码段沙箱的专门操作系统，则没有针对所描述问题的通用解决方案 有可信系统以及可以执行此操作的专用操作系统内核，但我假设您想在良好的旧 *nix 或 windows 环境中执行此操作。
编译器的东西使问题进一步复杂化（默认情况下，您的 C++ 编译器是否生成弱符号？通常会）这会影响 try-catch 中异常处理的方式。
引发信号的简单操作系统异常处理（SIGSEGV、SIGFPE 等）：
在支持 sigaction 的 POSIX 系统下...
假设您想要防止诸如内存损坏之类的通用问题寻址。在 dlopening 库之前使用 sigaction 捕获 SIGSEG（以防止 .init 函数），然后在调用库内的函数之前执行信号检查。考虑使用 SA_STACK 来确保您的处理程序跳转到您可以很好控制的堆栈中，并使用 SA_SIGINFO 来确保您的处理程序获取有关源的信息。
一个很好的起点是 GNU libc 手册上的信号处理
在 C++ 下：使用包装器并使用 try-catch 来捕获软异常
try {
foo();
}
抓住（） {
// 做某事
其中
foo 是一个弱符号，指向 dll 中的函数 请参阅 c++ dlopen mini-howto 了解有关加载类等的更多示例和详细信息。
如果您有更具体的需求，请发布它们，我会看看是否可以提供更多信息。
干杯
OK well generally speaking exception handling is highly operating system dependent. I am going to make some assumptions and try to provide some generic guidance. Please know that this is by no means an exhaustive reply, but should serve as a place to start.
I will assume that:
For the most part, you are interested in safeguarding against memory leaks.
You are not interested in Windows (which is whole-other-ball-of-wax) since you mentioned dlopen (you would have said LoadLibrary otherwise)
That you are aware of the nuances of linking against C++ symbols. If you are not read up on it at mini howto on dlopen c++
Generally speaking
There is no general solution to the described problem without involving specialized operating systems that provide data and code segment sand-boxing there are Trusted Systems and specialty operating system kernels that can do this, but i assume that you want to do this on a good old *nix or windows environment.
Compiler stuff further complicates issues (does your C++ compiler generate weak symbols by default? typically it would) This affects how exception handling happens in a try-catch.
Simple operating system exception handling that raises signals (SIGSEGV, SIGFPE etc.):
Under POSIX system supporting sigaction...
Let's say you want to protect against generic things like bad memory addressing. Trap the SIGSEG using sigaction before dlopening a library (to protect against .init functions) and then also do a signal check before calling a function within the library. Consider using SA_STACK to ensure that your handler jumps into a stack you have good control over, and SA_SIGINFO to ensure that your handler gets info about the source.
A good place to start on this is at the Signal handling on GNU libc manual
Under C++: use wrappers and with try-catch to catch soft exceptions
try {
foo();
}
catch() {
// do something
}
where foo is a weak symbol pointing to a function in your dll see c++ dlopen mini-howto for a lot more examples and details on loading classes etc.
If you have more specific needs, post them, i'll see if i can provide more info.
Cheers
您如何区分段错误与您的应用程序和相关动态库？正如他所描述的那样，创建一个单独的流程来隔离库似乎是最好的方法。
编辑：
发现此相关问题，指向 CERT 建议 建议如果您需要可移植性，则不要从 SIGSEGV 处理程序返回。
How would you differentiate a segfault from your application and the dynamic library in question? Creating a separate process to fence off the library as che described seems like the best approach.
edit:
found this related question, pointing at a CERT advisory suggesting not to return from a SIGSEGV handler if you desire portability.