VirtualBox 5.2.18 vulnerable to spectre/meltdown despite microcode being installed (#17987)

[socratis]

---

ModEdit; related ticket: #17987: VirtualBox 5.2.18 vulnerable to spectre/meltdown despite microcode being installed

---

How to reproduce:

A host running Debian stretch.
Using VirtualBox version 5.2.18.
A guest running Debian stretch.

Host using stretch-backports with get access to newer microcode. (Old versions are incapable to show spectre/meltdown fixed.)

spectre-meltdown-checker being installed on host and in guest from stretch-backports. (Old versions are incapable to show spectre/meltdown fixed.)

Code: Select all   Expand viewCollapse view

sudo su -c "echo -e 'deb http://http.debian.net/debian stretch-backports main contrib non-free' > /etc/apt/sources.list.d/backports.list"


Code: Select all   Expand viewCollapse view

sudo apt-get update

Code: Select all   Expand viewCollapse view

sudo apt-get -t stretch-backports install spectre-meltdown-checker

Suppose microcode being installed.

Intel:

Code: Select all   Expand viewCollapse view

sudo apt-get -t stretch-backports install intel-microcode

Amd:

Code: Select all   Expand viewCollapse view

sudo apt-get -t stretch-backports install amd64-microcode

Suppose running spectre-meltdown-checker on the host looks fine.

Code: Select all   Expand viewCollapse view

sudo spectre-meltdown-checker --paranoid ; echo $?

By fine I mean exit code 0 and not showing "vulnerable".

Suppose using all VirtualBox spectre/meltdown defense options.

Code: Select all   Expand viewCollapse view

VBoxManage modifyvm vm-name --ibpb-on-vm-entry on

Code: Select all   Expand viewCollapse view

VBoxManage modifyvm vm-name --ibpb-on-vm-exit on

Code: Select all   Expand viewCollapse view

VBoxManage modifyvm vm-name --spec-ctrl on

Code: Select all   Expand viewCollapse view

VBoxManage modifyvm vm-name --l1d-flush-on-sched off

(These options were introduced in VirtualBox version 5.2.18.)

Expected result:

spectre-meltdown-checker in guest VM saying "all fine".

Code: Select all   Expand viewCollapse view

sudo spectre-meltdown-checker --paranoid ; echo $?

By fine I mean exit code 0 and not showing "vulnerable".

Actual result:

spectre-meltdown-checker reporting vulnerable.

Questions:

Can you reproduce the same issue?

Were all necessary steps performed to protect the guest from spectre/meltdown?

Is this a VirtualBox issue or false-positive in spectre-meltdown-checker?

[adrelanos]

Any idea why no one replied to me?
Maybe posted in the wrong place?

VirtualBox ticket created:
VirtualBox 5.2.18 vulnerable to spectre/meltdown despite microcode being installed

[mpack]

Speaking personally, I didn't respond because I didn't see a VirtualBox question. The CPU, the bug, the fix, the host OS, the guest OS - they are all outside VirtualBox control so far as I know.

Is it really necessary to install the patch in both host and guest? I would have thought that patching the host is all that's required. VirtualBox is after all just an application running on the host.

Possibly I'm wrong, this isn't an area of expertise for me, and nor I suspect for most other users participating around here - another reason for not getting a response.

[adrelanos]

Host:
The host needs to be patched.

Guest:
The guest may or may not need to be patched (dunno) but spectre-meltdown-checker from stretch-backports has bug fixes for false positives so I mention it.

VirtualBox:
Among other commands which are were introduced in VirtualBox 5.2.18 and which are referenced in my original post, in the ticket VirtualBox 5.2.18 vulnerable to spectre/meltdown despite microcode being installed --spec-ctrl on has been recommended as well.

VirtualBox manual talks about CVE-2018-3646 (which is speculative execution which is also referenced as spectre). So it's safe to conclude that VirtualBox plays a role in getting this issue fixed inside virtual machines despite the host's patching status.

[The Raven]

You may wish to read the readme for that package. It has a lot of useful information
and does include the following comments

"This tool does its best to determine whether your system is immune (or has proper mitigations in place) for the collectively named "speculative execution" vulnerabilities. It doesn't attempt to run any kind of exploit, and can't guarantee that your system is secure, but rather helps you verifying whether your system has the known correct mitigations in place. However, some mitigations could also exist in your kernel that this script doesn't know (yet) how to detect, or it might falsely detect mitigations that in the end don't work as expected (for example, on backported or modified kernels)."

and also

"This tool has been released in the hope that it'll be useful, but don't use it to jump to conclusions about your security."

It also appears that if you run it as a standalone script you will get a full display of the BIOS/CPU settings it has detected
and more importantly which vulnerabilities it thinks you are exposed to. I would recommend that full display should be used
as the first point of reference in trying to decide which vulnerability it thinks you are exposed to.

I shall also try and recreate on my systems as I am also running Debian 9 Hosts with the latest microcode updates and
Debian 9 guests.

[mpack]

VirtualBox:
Among other commands which are were introduced in VirtualBox 5.2.18 ...

Well, I'm not sure of the purpose of that command. Yes, I can see circumstances in which you might want to test a CPU microcode fix in a VM when it hasn't already been installed on the host. I can see that that may not always work effectively. 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.

[adrelanos]

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.

---

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.

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?

[The Raven]

If the host operating system is considered spectre/meltdown safe, will VirtualBox guests in extension also be spectre/meltdown safe?

Not necessarily.
Take the exposure to CVE-2018-3646 which is neither Spectre or Meltdown - it's actually known
as L1 Terminal Fault. To mitigate against this attack needed both microcode updates, kernel changes
and VMM (VirtualBox) changes.

Your system is running Debian 9 with either latest 4.9 kernel or perhaps 4.17 from backports and
the latest intel-microcode package and VirtualBox 5.2.18

At face value the host is protected but if you run with a guest defined with both the --l1d-flush settings
OFF then you would still be exposed to CVE-2018-3646.

Furthermore, the --spec-ctrl settings controls whether the IBRS, IBPB and STIBP CPU flags are revealed to
the guest or not (assuming they are supported by the host microcode). Those CPU flags are related to
microcode changes to mitigate against Spectre.
The default for this setting is OFF, therefore, any guest kernel activating mitigations based on those flags
will not do so (as it thinks the CPU doesn't support the feature) and therefore will still be exposed unless
it takes other measures, eg using the retpoline mitigation technique.

[levitation]

The problem is that VirtualBox is not exposing SSBD flag (and of course, potentially also the relevant instructions, I cannot confirm the latter).

[The Raven]

The problem is that VirtualBox is not exposing SSBD flag

Agreed - that's what I've found on my system as well with the latest microcode, 4.17 kernel in the
host and latest 4.9 kernel in guest.
Running the checker in the guest shows it is vulnerable to both CVE-2018-3639 and CVE-2018-3640.

It's the mitigation for CVE-2018-3639 that relies on the SSBD flag being present. The documentation
for some other hypervisors indicate they have made changes to expose that flag.

[The Raven]

Regarding the checker results mentioned above saying that my machine is vulnerable to
CVE-2018-3640, I'm not sure that's quite correct.

I'm running with the latest intel-microcode package from backports which includes the
following description in the changelog :
"Implements SSBD support (Spectre v4 mitigation),
Disable speculation for (some) RDMSR/WRMSR (Spectre v3a fix)
Intel SA-00115, CVE-2018-3639, CVE-2018-3640"

Then Intel advisory also states for the CVE-2018-3640 mitigation :
"The microcode updates will also address Rogue System Register Read (RSRR) – CVE-2018-3640
by ensuring that RDMSR instructions will not speculatively return data under certain conditions.
This is documented in whitepapers located at Intel’s Software Side-Channel Security site.
No operating system or hypervisor changes are required to support the RDMSR change."

Therefore, the CVE-2018-3640 mitigation is purely made by the microcode change but is not related
to presence of the SSBD change (that's addressing CVE-2018-3639).
However, the checker we're mentioning in this thread just uses the presence of the SSBD flag to
determine the microcode level in use but of course, in a guest where the SSBD flag has not been
provided, the checker thinks it's on an earlier microcode - hence it thinks you have no mitigation
for CVE-2018-3640.