Review of vulnerabilities in other virtualization projects

Hi,

Just wanted to ask the virtualization dev team whether some analysis of new
vulnerabilities found in other virtualization projects, like KVM on Linux, VMM
on OpenBSD, Xen, QEMU, etc. is conducted regularly to see if the same problems
are present in bhyve and the FreeBSD virt stack in general?

As an example, have the following recent vulnerabilities in KVM and Xen been
checked for same problems in bhyve and pci(4)?

Maxim Levitsky and Paolo Bonzini discovered that the KVM hypervisor
implementation for AMD processors in the Linux kernel allowed a guest VM to
disable restrictions on VMLOAD/VMSAVE in a nested guest. An attacker in a
guest VM could use this to read or write portions of the host's physical
memory. (CVE-2021-3656)

Maxim Levitsky discovered that the KVM hypervisor implementation for AMD
processors in the Linux kernel did not properly prevent a guest VM from
enabling AVIC in nested guest VMs. An attacker in a guest VM could use this
to write to portions of the host's physical memory. (CVE-2021-3653)

Guests are permitted access to certain Xen-owned pages of memory.  The
majority of such pages remain allocated / associated with a guest for
its entire lifetime.  Grant table v2 status pages, however, are
de-allocated when a guest switches (back) from v2 to v1.  Freeing
such pages requires that the hypervisor enforce that no parallel request
can result in the addition of a mapping of such a page to a guest.  That
enforcement was missing, allowing guests to retain access to pages
that were freed and perhaps re-used for other purposes.

Both AMD and Intel allow ACPI tables to specify regions of memory
which should be left untranslated, which typically means these
addresses should pass the translation phase unaltered.  While these
are typically device specific ACPI properties, they can also be
specified to apply to a range of devices, or even all devices.

On all systems with such regions Xen failed to prevent guests from
undoing/replacing such mappings (CVE-2021-28694).

On AMD systems, where a discontinuous range is specified by firmware,
the supposedly-excluded middle range will also be identity-mapped
(CVE-2021-28695).

Further, on AMD systems, upon de-assigment of a physical device from a
guest, the identity mappings would be left in place, allowing a guest
continued access to ranges of memory which it shouldn't have access to
anymore (CVE-2021-28696).

All these vulnerabilities were published in the past 30 days.

Just to clarify, the question is not about whether these specific
vulnerabilities apply or not to the way bhyve is implemented, but rather whether
there's a process in place to review the newly discovered security problems in
other virtualization projects.

Regards,
Anatoli