Hi, On Sun, 2019-04-14 at 21:02 -0700, PGNet Dev wrote:
BUT, checking with
spectre-meltdown-checker.sh
still returns "STATUS: VULNERABLE",
[...]
Since I'm on Xen, 'Mitigation 1' isn't an option.
Two things catch my attention:
(1) L1D flush enabled: UNKNOWN (unrecognized mode)
Not sure yet why I'm seeing UNKNOWN here,
I haven't checked the source code but that's, most likely, because the checked tries to figure out whether the Linux kernel, on top of the hardware where it's running, has the capability to --let's say-- issue the L1D-Flush instructions, without taking into account the fact that you may be running inside a Xen (PV) guest. In fact, if you run this check from within a Xen dom0 (which you are, aren't you?), 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 for it). So, this is all technically correct.
(2) Hardware-backed L1D flush supported: NO
Again, this is correct. As far as the dom0 PV kernel knows and see, the hardware is not capable of that. That's because the view of the hardware it has is filtered by Xen, and Xen let it believe (and that's on purpose) that this is the situation.
even though
(XEN) [00000028c19f6e50] Hardware features: IBRS/IBPB STIBP L1D_FLUSH SSBD
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 place.
What's missing in my config to mitigate/remove the CVE-2018-3646 vulnerability?
There's nothing you're missing, as far as I can tell. What the problem seems to be, is that spectre-and-meltdown-checker.sh does not treat the case of this check being made within a Xen (PV) guest properly. I'll check whether this is actually the case, and I'll to see about fixing that, as soon as I find a minute. Oh, BTW, you know this already, but let me also add this: if you are running only PV guests, with the settings you've shown you are using, you are indeed safe against L1TF. 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 the case for KVM too, FWIW). Regards -- Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <<This happens because _I_ choose it to happen!>> (Raistlin Majere)