与不受信任的进程共享内存是否安全？答案

【问题标题】：Is shared memory with an untrusted process safe?与不受信任的进程共享内存是否安全？
【发布时间】：2020-03-31 01:14:12
【问题描述】：

我正在尝试创建一个 x86 Linux 程序，该程序以提升的权限运行，但也可以在子进程中运行潜在的不安全代码并通过共享内存与其通信，主要是出于性能原因。我的想法是这样的：

之后访问共享内存有哪些陷阱？显然子进程可以提供无效数据并随时更改它，但它实际上是否会以其他方式损害父进程，例如阻止内存访问，甚至将其关闭或类似的东西？

或者使用安全吗？ memcpy()?

原子操作安全吗？ sem_timedwait?

【问题讨论】：

【解决方案1】：

如果你只是将内存用于简单的操作，比如memcpy，孩子不能直接伤害你，但如果你真的不信任他们，分享有什么意义呢？

将信号量放入内存是个坏主意；再说一次，你不能相信他们，也就是说，你不能相信他们。信号量、互斥量、condvars ......只能在高度信任的情况下工作。消息传递更好，但不需要共享内存。

我能想象到的最糟糕的情况是轻微的拒绝服务攻击。在 I/O 期间，页面通常不可访问。如果您的孩子复制了许多自己的副本，并设法不断地定向共享页面，则可能会严重破坏父级的执行进度。

有些人的想象力比我还多。

【讨论】：

非常感谢！这正是我正在寻找的。你有关于信号量的参考吗？
我正在尝试设计一个容错的多用户服务器架构。理论上子进程是可以信任的，但他们被黑客入侵的可能性不大，在这种情况下，必须不可能入侵或关闭父进程。
并非如此，但是当您查看 trust 时，一种方法是综合攻击。好演员按预期使用信号量；坏演员获得但从不释放。虽然优秀的参与者可能能够通过基于超时的操作来保护自己；信号量的效用仍然丢失，除非好演员变坏。您可以为其他共享同步原语构建类似的案例。
是的，如果一个孩子变坏了，显然已经没有用了。但只要不破坏系统的其余部分，这是可以容忍的。我将尝试编译有关此主题的参考列表。
看minix3；它在这些领域比大多数其他系统更具前瞻性。此外，从速率和调度限制方面分析 golang 消息传递的细微差别可能是值得的。