VirtualBox 5.2.18 introduced various options regarding spectre/meltdown.
--ibpb-on-vm-[enter|exit] on|off: Enables flushing of the indirect branch prediction buffers on every VM enter or exit respectively. This could be enabled by users overly worried about possible spectre attacks by the VM. Please note that these options may have sever impact on performance.
--spec-ctrl on|off: This setting enables/disables exposing speculation control interfaces to the guest, provided they are available on the host. Depending on the host CPU and workload, enabling speculation control may significantly reduce performance.
--l1d-flush-on-sched on|off: Enables flushing of the level 1 data cache on scheduling EMT for guest execution. See Section 13.4.1, “CVE-2018-3646”.
--l1d-flush-on-vm-enter on|off: Enables flushing of the level 1 data cache on VM enter. See Section 13.4.1, “CVE-2018-3646”.
Manual of VirtualBox 5.2.18 was updated regarding --nestedpaging.
--nestedpaging on|off: If hardware virtualization is enabled, this additional setting enables or disables the use of the nested paging feature in the processor of your host system; see Section 10.7, “Nested paging and VPIDs” and Section 13.4.1, “CVE-2018-3646”.
Manual of VirtualBox 5.2.18 introduced it's own chapter on spectre/meltdown in VirtualBox
https://www.virtualbox.org/manual/ch13. ... -2018-3646
13.4. Security Recommendations
This section contains security recommendations for specific issues. By default VirtualBox will configure the VMs to run in a secure manner, however this may not always be possible without additional user actions (e.g. host OS / firmware configuration changes).
13.4.1. CVE-2018-3646
This security issue affects a range of Intel CPUs with nested paging. AMD CPUs are expected not to be impacted (pending direct confirmation by AMD). Also the issue does not affect VMs running with hardware virtualization disabled or with nested paging disabled.
For more information about nested paging, see Section 10.7, “Nested paging and VPIDs”.
Mitigation options:
13.4.1.1. Disable nested paging
By disabling nested paging (EPT), the VMM will construct page tables shadowing the ones in the guest. It is no possible for the guest to insert anything fishy into the page tables, since the VMM carefully validates each entry before shadowing it.
As a side effect of disabling nested paging, several CPU features will not be made available to the guest. Among these features are AVX, AVX2, XSAVE, AESNI, and POPCNT. Not all guests may be able to cope with dropping these features after installation. Also, for some guests, especially in SMP configurations, there could be stability issues arising from disabling nested paging. Finally, some workloads may experience a performance degradation.
"Disable nested paging" sounds confident, reliable, secure but also major performance penalty.
13.4.1.2. Flushing the level 1 data cache
This aims at removing potentially sensitive data from the level 1 data cache when running guest code. However, it is made difficult by hyper-threading setups sharing the level 1 cache and thereby potentially letting the other thread in a pair refill the cache with data the user does not want the guest to see. In addition, flushing the level 1 data cache is usually not without performance side effects.
...
"Flushing the level 1 data cache" doesn't sound very reliable, secure.
mpack wrote:
I can't see why you'd want to install the microcode twice, since I assume a CPU will only have one microcode storage area, regardless of its core count. It certainly doesn't store separate microcode for each OS app.
I never suggested installing microcode twice. I never suggested installing microcode updates inside VM.
mpack wrote:adrelanos wrote:
VirtualBox:
Among other commands which are were introduced in VirtualBox 5.2.18 ...
Well, I'm not sure of the purpose of that command.
Me neither. I am not sure about the purpose of all of these new VirtualBox 5.2.18 commands and documentation.
Are all of these new VirtualBox 5.2.18 configuration options only useful for host operating systems which are vulnerable to spectre/meltdown that cannot be patched? Did the VirtualBox go through implementing all of these options just help out people who can't patch spectre/meltdown?
I guess my major question boils down to...
If the host operating system is considered spectre/meltdown safe, will VirtualBox guests in extension also be spectre/meltdown safe? Perhaps the developers could clarify?