Mailinglist Archive: opensuse-virtual (17 mails)

< Previous Next >
Re: [opensuse-virtual] How to correctly configure mitigation of CVE-2018-3646 'Foreshadow-NG (VMM)' on Xen Dom0 host?
On Mon, 2019-04-15 at 07:17 -0700, PGNet Dev wrote:
On 4/15/19 3:08 AM, Dario Faggioli wrote:

In fact, if you run this check from within a Xen dom0 (which you
aren't you?),

Yes, I am exec'ing this at the Dom0 shell.

you're inside a PV-guest, on top of Xen, and a PV-guest
can't do the L1D flush (basically because that would be pointless

Which, IIUC, would be the case for ANY Xen PV-guest as well?


I do note that, cursorily testing the checker in a (hosted
KVM guest, I see:

STATUS: NOT VULNERABLE (this system is not running an

which is a different result, though still in a Hypervisor-host's VM
guest ...

I still haven't time to download and check the code of the checker, but
point is this:
- exploiting L1TF, it may be possible to read the host physical RAM
from inside a VM. This means malicious code running inside a VM can
read the memory of other applications inside the same VM, of other
VMs and also of the hypervisor.
It is not entirely trivial, even without mitigations applied, but
it's possible, and proofs of contept do exist;
- for Xen PV guests, if the guest has "PTE Inversion" and Xen has
pv-l1tf enabled, the problem is fully mitigated;
- for Xen HVM guests or KVM guests, on system without hyperthreading
(or with hyperthreading properly disabled), if L1D flush is supported
(by hardware and hypervisor) and enabled, the problem is fully
- for Xen HVM guests or KVM guests, on system with hypetrheading,
the problem can't be fully mitigated.

So, the tool reporting "STATUS: UNKNOWN" for your dom0 was wrong,
because you seem to have all the pieces in place for PV guests to not
be vulnerable.

For KVM guests and Xen HVM guests, can you paste the full output of the
section "CVE-2018-3646 aka 'Foreshadow-NG (VMM), L1 terminal fault'" ?

even though

(XEN) [00000028c19f6e50] Hardware features: IBRS/IBPB STIBP

Exactly, and this is what is important to have in the logs and to
check, in order to know whether you have the L1TF mitigations in

To be clear, is the *existence* of "L1D_FLUSH" in that 'Hardware
Features:' log line evidence that the feature is, in fact, *in use*
as a
Spectre mitigation?

The existence of that line in 'Hardware Feature' is evidence that your
hardware is (quite possibly thanks to a microcode update) capable of
doing L1D flushes, which can be used by the hypervisor as part of the
mitigations for L1TF.

In Xen, the fact that you are specifying this:

GRUB_CMDLINE_XEN="...spec-ctrl=...,l1d-flush=true ..."

And more specifically the fact that you have this in the logs:

(XEN) Xen settings: BTI-Thunk RETPOLINE, SPEC_CTRL: IBRS- SSBD+, Other: IBPB

is evidence that, let's say, L1D_FLUSH is being use to L1TF, for HVM
guests. If you have hyperthreading disabled (e.g., from BIOS, as I see
you have "smt=true" on Xen cmd line), then it's a full and proper
mitigation. If (much more likely, I think) you have hyperthreading
enabled, that's only a partial mitigation.

Oh, BTW, you know this already, but let me also add this: if you
running only PV guests, with the settings you've shown you are
you are indeed safe against L1TF.

Yep. And I do ... _mostly_. On occassion, I do run HVM guest, so
fussing with this.

Generally, I'd like to get a handle on all the mitigations, in all
cases, and then make any decisions about performance-vs-security ...

Sure, I understand. Our policy, for this things, is to stay much rather
on the secure side (more than others, e.g., we use IBRS on SkyLake and
later hardware, which is something others call paranoid and just go
with Retpoline).

On this L1TF-vs-hyperthreading thing, well, both the risk assessment
and the performance impact are so much use case and workload dependant
that we need the user to step in.

If you are running HVM guests too, the only way to be totally and
absolutely safe is, for now, to disable hyperthreading (and that's
case for KVM too, FWIW).

Sure. With the available 'compromise' of leaving it enabled, if one
makes the call that the host/guest are under sufficiently secure
control ...


Dario Faggioli, Ph.D
Virtualization Software Engineer
<<This happens because _I_ choose it to happen!>> (Raistlin Majere)

< Previous Next >
List Navigation
Follow Ups