只要 VM 不执行不受信任的代码，就不会.

请注意，“执行不受信任的代码”包括从 Github、StackOverflow 或其他地方获取代码片段并在任何类型的沙箱中运行它们，例如：a chroot、隔离容器或虚拟机（但浏览器沙箱除外，例如 Brython 或 Emscripten，一旦适当的浏览器缓解措施到位）。

如果 VM 在任何情况下都可以执行不受信任的代码，那么答案是：它取决于. 它仍然可能不需要JS 引擎现在提供的所有或任何缓解措施，但是您的威胁模型变得更加复杂。

到目前为止，您的虚拟机必须满足一些要求才能在理论上暴露于 Meltdown 或 Spectre 的影响：

1. 虚拟机运行一个不受信任的代码，至少可以向外界发送消息。

   包括但不限于 Internet 访问或将数据显示或写入某个位置的权限，该位置稍后可能会被攻击者访问。

2. VM 允许使用可用于测量相应编程语言指令的相对执行时间的高精度计时器或工具。

   包括但不限于并发线程之间共享的缓冲区。

3. VM 具有优化技术，至少在理论上，可以允许不受信任的代码以近似于已编译代码的效率运行。

   包括但不限于即时 (JIT) 编译或优化的字节码生成。

   据信^{[需要引用]}，至少在 CVE-2017-5715 的情况下，在某些情况下（例如，系统库中存在特定二进制指令序列和一系列不幸事件），这一特定要求可以进一步放宽或举起。

4. 满足以下任一条件：

   • 未应用针对 Meltdown 的操作系统缓解措施
   • 虚拟机在不受信任的代码片段可以运行的同一进程中加载​​敏感信息
   • 攻击者可以在不受信任的代码运行的同时，从不受信任的代码本身或通过任何其他方式，直接或间接

如果以上四个条件都成立，那么理论上，您的 VM 可用于根据 Spectre 和/或 Meltdown 的影响从系统中提取敏感信息。

一个简单的虚拟机示例，尽管通常有效地运行第三方代码，但没有暴露给 Spectre，它是 TrueType 字形提示语言 VM，它不允许以任何方式进行线程或指令计时，因此至少会破坏，要求#2。

关于系统更新的重要说明。

在 Javascript PoC 的情况下，Meltdown 或 Spectre 不用于读取内核内存或其他进程的内存。它们可以是，但 Javascript VM 中的 Spectre 的主要问题是 VM 在包含敏感数据（网站密码、cookie 等）的浏览器进程内的沙箱（之前是隔离和安全的）中运行。

操作系统更新（例如 Linux 的 KPTI）无助于完全缓解该问题，因为：

1. 他们的目标是 Meltdown，而主要问题是 Spectre；
2. KPTI 唯一保证的是进程无法读取内核内存（以及映射到内核空间的其他进程的内存，仅通过 Meltdown）。KPTI 不禁止进程中的线程读取内存，从操作系统的角度来看，内存可供整个进程读取，密码和 cookie 存储在同一浏览器进程中的情况是 JS 沙箱跑进去。

此外，为了百分百准确，您已经询问过其他语言的 VM 中是否需要“类似的缓解措施”（针对 JS VM 的缓解措施）。请注意，当代的浏览器内 JS VM 已经具有一个整体设计良好的沙箱，它对文件系统、IPC、汇编语言和其他系统资源的访问权限有限。如果您的虚拟机（例如 Node.js 平台附带的 V8 JS 虚拟机）比浏览器内的 JS 虚拟机拥有更多的权限或能力，它可能不需要类似的，但需要进一步和更严格的缓解措施。

截至 2018 年 1 月 14 日，这是理论上的；但你的问题也是理论上的。