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

Dario Faggioli <[email protected]> Mon, 15 Apr 2019 12:08:32 +0200
Newsgroups gmane.linux.suse.opensuse.virtual,gmane.linux.suse.security
Organization SUSE
Message-ID <[email protected]>
--=-mF7o2ds1RavtK4tbkVVc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Sun, 2019-04-14 at 21:02 -0700, PGNet Dev wrote:
> BUT, checking with
>=20
> 	spectre-meltdown-checker.sh
>=20
> still returns "STATUS: VULNERABLE",
>=20
> [...]
>=20
> Since I'm on Xen, 'Mitigation 1' isn't an option.
>=20
> Two things catch my attention:
>=20
> 	(1) L1D flush enabled:  UNKNOWN  (unrecognized mode)
>=20
> Not sure yet why I'm seeing UNKNOWN here,
>=20
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
>=20
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
>=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
> What's missing in my config to mitigate/remove the CVE-2018-3646
> vulnerability?
>=20
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
--=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)


--=-mF7o2ds1RavtK4tbkVVc
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+4FAly0WCAACgkQFkJ4iaW4
c+731xAAxPEtwhq8xLJwlIXXYKhZkovMqV75Bs6v3IoNh4uinj9E2qsO32Q2n/H1
ydSxmKDm/56/PZ2Zz/qZqipmWIL5QzBTy0ipWPlfBnMXx2p7SY98DSIC6saz1kjj
iHjjHVnSgJveKgN1YorO59X/9w7dXLU1TjX0YM/o4S6SoTfZn4AvqfG0+Fh+577q
hZgc0e0Rj+YSrv6IL/J9t56jP6rdq9NuVu2sKv5qsLVb56R052KF6xswZCDZwglY
nLFIzceCszrR9EsxDIfxU1kzhTiaLmioh3TDz7XxIblC0WVua3SJNZQZzeTah0oo
MvCAr+qVc2alDB1z33LqvvrtofDkfPoI5+Mb9iF6VvD0JMAtQHvgrjBuE0u8GSuw
6yjxO2nsWMrIy3uC+dhZv3VSNBCIyQWbjEJxbshLl7ROkbo9EY08Drk56y7G/KDP
zabuM1nfcFnC++popnnqiwAY9sv/iT5PgHHRkDpW7TKveENnkxcfhsLZ/h7E02G4
9vGbLYUNtg2I0oZ2Cqe8tETQ8tbA0b8S+3sT49ylqI104wxvmPlE1z6t3M4nJrvs
UuiAn+wxEaikmyNwZB9AQAq6Fw+ypzuxpEw9ZTP6p/h+zRvu5IPMFHhYlXbM/5Sl
8wsAUst7NqAqjaaUsUEEr13bQ72KOBpZRfJiGuOxv6x563KcKu8=
=PrlG
-----END PGP SIGNATURE-----

--=-mF7o2ds1RavtK4tbkVVc--