Re: How to correctly configure mitigation of CVE-2018-3646 'Foreshadow-NG (VMM)' on Xen Dom0 host?

--=-tXf/Pd7tWfyvS1n7boTO
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2019-04-15 at 07:17 -0700, PGNet Dev wrote:
> On 4/15/19 3:08 AM, Dario Faggioli wrote:
> > >=20
> > In fact, if you run this check from within a Xen dom0 (which you
> > are,
> > aren't you?),
>=20
> Yes, I am exec'ing this at the Dom0 shell.
>=20
> > 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).
>=20
> Which, IIUC, would be the case for ANY Xen PV-guest as well?
>=20
Yes.

> I do note that, cursorily testing the checker in a (hosted
> elsewhere)=20
> KVM guest, I see:
>=20
>    STATUS:  NOT VULNERABLE  (this system is not running an
> hypervisor)
>=20
> which is a different result, though still in a Hypervisor-host's VM=20
> guest ...
>=20
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=20
  from inside a VM. This means malicious code running inside a VM can=20
  read the memory of other applications inside the same VM, of other=20
  VMs and also of the hypervisor.
  It is not entirely trivial, even without mitigations applied, but=20
  it's possible, and proofs of contept do exist;
- for Xen PV guests, if the guest has "PTE Inversion" and Xen has=20
  pv-l1tf enabled, the problem is fully mitigated;
- for Xen HVM guests or KVM guests, on system without hyperthreading=20
  (or with hyperthreading properly disabled), if L1D flush is supported
  (by hardware and hypervisor) and enabled, the problem is fully=20
  mitigated;
- for Xen HVM guests or KVM guests, on system with hypetrheading,=20
  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
> > >=20
> > > 	(XEN) [00000028c19f6e50]   Hardware features: IBRS/IBPB STIBP
> > > L1D_FLUSH SSBD
> > >=20
> > 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.
>=20
> To be clear, is the *existence* of "L1D_FLUSH" in that 'Hardware=20
> Features:' log line evidence that the feature is, in fact, *in use*
> as a=20
> Spectre mitigation?
>=20
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=3D"...spec-ctrl=3D...,l1d-flush=3Dtrue ..."

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

(XEN)  Xen settings: BTI-Thunk RETPOLINE, SPEC_CTRL: IBRS- SSBD+, Other: IB=
PB 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=3Dtrue" 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.
>=20
> Yep.  And I do ... _mostly_.  On occassion, I do run HVM guest, so=20
> fussing with this.
>=20
> Generally, I'd like to get a handle on all the mitigations, in all
> use=20
> cases, and then make any decisions about performance-vs-security ...
>=20
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).
>=20
> Sure.  With the available 'compromise' of leaving it enabled, if one=20
> makes the call that the host/guest are under sufficiently secure
> control ...
>=20
Exactly.

Regards
--=20
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)


--=-tXf/Pd7tWfyvS1n7boTO
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEES5ssOj3Vhr0WPnOLFkJ4iaW4c+4FAly0sqgACgkQFkJ4iaW4
c+5nuxAA519UNTGHmcdS7rCXyqZAp7oqZnk2ICTyDxkGMT3ZXY8v9WRq6AZCs5En
JjjNeGkE3ouYCg/2QFSLy3tk2KTQthbHmJsfuYDVtA8/pt0IYuZikcMQKf2vMgLX
GPjbe+v1yr+08HMweBDZubBF6x0FnPqa+faZ99rlwu1fBcDf65snjZUmree3QoZx
HxXJjdXLCldKRHAjy9Hh2kiQqGWV1LYb6JcDYN6eoSlwNyqbSOWERDj80Wrb4g3m
w7Pha+HxtSDIC5TJsdoREZYGoooNL2dppx5EaeQTp6peZsKyWuZOWPVZ3zBDOYbb
g5sPCrc0BT92//V5IEFj6fQ/JVUjhAmsxxEo9uO/kRsljfGMWzvgOK9vspSihlNn
Mpg5b/MzBaArlhFcdCDYsFw2kuFPFrMdkMEYM2T++4JC8bqQ1S8vr0sRhjQSfag4
2KhQ04MDhilib5ZenHYxR9mYJY2mjZ+ClcmZqsbK2RYr07ZpGa8wLUDCQzpCyCnf
rFYul+jTDtptYRpdmAQuaQqZn6XVgwCocZv8EOi0udnGzT1ZLcKRcpq2w6+iAEkx
7Sl/kXzNPP2XYIni3Wpy6/LfTxc8qSlhNWXP95AZ3VjhWRMJRa0u1tOvocvVJ5HD
XvwAH4PI1NfhJK3gdnmm27HrCkzEyMp8Ew8I5vgNQ7uEUzUnOmc=
=hVwI
-----END PGP SIGNATURE-----

--=-tXf/Pd7tWfyvS1n7boTO--