KSM 的安全问题
Security concerns around KSM
当使用KSM（Kernel Same-page Mapping）时，如果两个完全相同的内存页面由两个完全隔离的进程拥有，例如两个虚拟机，这些页面是否会被合并？或者由于每个进程彼此隔离，它们会保持独立吗？我很困惑，因为虚拟机归结为主机上的单个进程，但如果合并这些页面，这似乎是一个相当重要的问题，所以我假设它们是分开的？
我也很好奇这是否能区分 VM 和容器？
除了会发生什么的问题，如果他们被隔离，是否可以详细说明？我假设这是通过使用 cgroups 来实现的，这样两个进程的内存就完全隔离了，我想澄清一下。
来自不同进程的页面被合并，即使并且尤其是当它们由不同的 VM 实例拥有时。我特别说，因为合并来自不同 VM 的页面提供了通过合并内存页面可以实现的最大效果：它消除了 VM 中相同的大量库和内核代码的复制。
并且此效果已用于针对 GnuPG 1.4.13 加密库的缓存定时攻击。包含 GnuPG 库代码的合并页面在两个不同的 VM 之间共享，并且一个 VM 能够恢复另一台正在进行的加密操作所使用的密钥。由于用于侦听信息的处理器指令，该攻击被命名为 "FLUSH+RELOAD"。
这是描述攻击的 pdf 文件 link：https://eprint.iacr.org/2013/448.pdf
当使用KSM（Kernel Same-page Mapping）时，如果两个完全相同的内存页面由两个完全隔离的进程拥有，例如两个虚拟机，这些页面是否会被合并？或者由于每个进程彼此隔离，它们会保持独立吗？我很困惑，因为虚拟机归结为主机上的单个进程，但如果合并这些页面，这似乎是一个相当重要的问题，所以我假设它们是分开的？
我也很好奇这是否能区分 VM 和容器？
除了会发生什么的问题，如果他们被隔离，是否可以详细说明？我假设这是通过使用 cgroups 来实现的，这样两个进程的内存就完全隔离了，我想澄清一下。
来自不同进程的页面被合并，即使并且尤其是当它们由不同的 VM 实例拥有时。我特别说，因为合并来自不同 VM 的页面提供了通过合并内存页面可以实现的最大效果：它消除了 VM 中相同的大量库和内核代码的复制。
并且此效果已用于针对 GnuPG 1.4.13 加密库的缓存定时攻击。包含 GnuPG 库代码的合并页面在两个不同的 VM 之间共享，并且一个 VM 能够恢复另一台正在进行的加密操作所使用的密钥。由于用于侦听信息的处理器指令，该攻击被命名为 "FLUSH+RELOAD"。
这是描述攻击的 pdf 文件 link：https://eprint.iacr.org/2013/448.pdf