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 09:59 -0700, PGNet Dev wrote:
On 4/15/19 9:34 AM, Dario Faggioli wrote:
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
read the memory of other applications inside the same VM, of
VMs and also of the hypervisor.
It is not entirely trivial, even without mitigations applied,
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
(or with hyperthreading properly disabled), if L1D flush is
(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.

That's really clear. And the 1st time I've read it all, so
succinctly stated, in one place.

Ah, thanks. :-)

atm, on this particular host, my Xen cmd line includes:

spec-ctrl=ssbd,l1d-flush=true pv-l1tf=dom0=true,domu=true

which may, or not, be overkill/risky; still need to do some reading
up on the relative merits.

As we were saying, it's rather hard to tell from the outside whether
it's balanced or overkill.

It's pretty much what we do by default, which might be seen as a good
sign, I guess.

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

Don't have a Xen HVM up right at the moment.

For KVM guest (@ Linode, fwiw),

CVE-2018-3646 aka 'Foreshadow-NG (VMM), L1 terminal fault'
* Information from the /sys interface:
* This system is a host running an hypervisor: NO
* Mitigation 1 (KVM)
* EPT is disabled: N/A (the kvm_intel module is not loaded)
* Mitigation 2
* L1D flush is supported by kernel: YES (found flush_l1d in
kernel image)
* L1D flush enabled: UNKNOWN (unrecognized mode)
* Hardware-backed L1D flush supported: NO (flush will be
done in software, this is slower)
* Hyper-Threading (SMT) is enabled: NO
> STATUS: NOT VULNERABLE (this system is not running an

> SUMMARY: CVE-2017-5753:OK CVE-2017-5715:OK CVE-2017-5754:OK
CVE-2018-3640:OK CVE-2018-3639:OK CVE-2018-3615:OK CVE-2018-3620:OK

IIUC from your comments above, the apparently *dis*abled SMT
hyperthreading leads, in this case, to the mitigation STATUS ==> NOT

Well, not quite. :-/

In fact, this is from inside a guest. In order for things to be 100%
safe, hyperthreading should be disabled at the _host_ level, which is
something that the guest can't know.

Actually, the guest can't know for sure whether or not the underlying
host it is running on has L1D flush supported and enabled either.

So, I think it is calling it "NOT VULNERABLE" on the ground, e.g., that
, as it says, "this system is not running an hypervisor". But that is
going to be true for any VM, unless one is using nested virtualization.

If that's the case, the whole 'Foreshadow-NG (VMM)' block appears to be
rather bogous... but I really want to speak only after having checked
the code. :-)

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

< Previous Next >
List Navigation
Follow Ups