From nobody Wed Sep 22 01:14:09 2021 X-Original-To: freebsd-virtualization@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A139A17D34EC for ; Wed, 22 Sep 2021 01:14:22 +0000 (UTC) (envelope-from me@anatoli.ws) Received: from out-mx.anatoli.ws (out-mx.anatoli.ws [177.54.157.124]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "out-mx.anatoli.ws", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HDgLP5nNgz3Ckh for ; Wed, 22 Sep 2021 01:14:21 +0000 (UTC) (envelope-from me@anatoli.ws) Received: from [192.168.0.1] (unknown [192.168.0.1]) by out-mx.oprbox.com (Postfix) with ESMTPSA id 1058F1E00BCA for ; Wed, 22 Sep 2021 01:14:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=anatoli.ws; s=vnptcm0lqn; t=1632273252; bh=npER10nnVicx9Z5Fo7yp4lPl+Ml1HPJMbxApJha+x7g=; h=To:From:Subject:Date; b=XFnLKrWYcWQzYUU7Rj8ncCw/l4qgLtqbiB3v+5XYl3o+erkrtjhMSKL8ZB41KyNov v7OfoQANzg9hCKjnPWeJ67jDe1eqqbvvPjFHYtZ3HjpUXKavcqP1NdrH7KJt9oEOOc wgrMn8RI4V6wR6hSoiA9J47Hc13pHATFOeQbxewGzc96eAuwpigCnnSP1xL2CPzBbS M904yRAIRpOrjkmMdK4RYB8+/maxh41aMlI2MhVLpWa4AnPVHSCbdQJDy7tLNbO3g7 dZh3AqZttBCNzhhEwalrJYKG03GERxXtvclsCZO7jQfvmlqhnFQaeYDocyHzoZ0NNU hM3MP8EmFkvBw== To: freebsd-virtualization@freebsd.org Subject: Review of vulnerabilities in other virtualization projects Message-ID: <00a0c3ed-dfa5-4d90-ea10-78d7d1147c63@anatoli.ws> Date: Tue, 21 Sep 2021 22:14:09 -0300 List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HDgLP5nNgz3Ckh X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=anatoli.ws header.s=vnptcm0lqn header.b=XFnLKrWY; dmarc=pass (policy=reject) header.from=anatoli.ws; spf=pass (mx1.freebsd.org: domain of me@anatoli.ws designates 177.54.157.124 as permitted sender) smtp.mailfrom=me@anatoli.ws X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[anatoli.ws:s=vnptcm0lqn]; FREEFALL_USER(0.00)[me]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-virtualization@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+a:out-mx.anatoli.ws]; DKIM_TRACE(0.00)[anatoli.ws:+]; MID_RHS_MATCH_FROM(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[anatoli.ws,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:262287, ipnet:177.54.156.0/23, country:BR]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Reply-To: me@anatoli.ws From: Anatoli via freebsd-virtualization X-Original-From: Anatoli X-ThisMailContainsUnwantedMimeParts: N 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