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 > > are, > > 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 > > for > > it). > > Which, IIUC, would be the case for ANY Xen PV-guest as well? > Yes.
> I do note that, cursorily testing the checker in a (hosted > elsewhere) > KVM guest, I see: > > STATUS: NOT VULNERABLE (this system is not running an > hypervisor) > > 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 mitigated; - 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 > > > 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. > > 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 L1D_FLUSH 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 > > are > > running only PV guests, with the settings you've shown you are > > using, > > 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 > use > 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 > > the > > 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 ... > Exactly. 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)
signature.asc
Description: This is a digitally signed message part
