Re: [PATCH 3/4] KVM: arm64: Parse reserved-memory node for pkvm guest firmware region
From: Will Deacon <will@kernel.org>
Date: 2021-06-08 12:31:27
Also in:
kvm, kvmarm
Hi Mark, On Fri, Jun 04, 2021 at 03:21:41PM +0100, Mark Rutland wrote:
On Thu, Jun 03, 2021 at 07:33:46PM +0100, Will Deacon wrote:quoted
Add support for a "linux,pkvm-guest-firmware-memory" reserved memory region, which can be used to identify a firmware image for protected VMs.The idea that the guest's FW comes from the host's FW strikes me as unusual; what's the rationale for this coming from the host FW? IIUC other confidential compute VM environments allow you to load up whatever virtual FW you want, but this is measured such that the virtual FW used can be attested.
The rationale is that, as far as possible, we're trying to keep the EL2 code simple and agnostic of the guest and the SoC. We therefore assign validation of the guest payload to this firmware image which is executed when first entering the guest and made inaccessible to the host kernel as part of the deprivilege operation during boot. The VMM could still provide its own virtual firmware, which would then be measured by the firmware here and chainloaded. We just deprivilege that logic from EL2 to EL1. For pKVM on Android, it is the Android Bootloader which loads both the host kernel and the guest firmware (which is actually just u-boot). Before entering the host, it verifies and measures the guest firmware, appending secrets to the reserved memory region which are later used by the firmware to generate per-VM identities. These certificates are then used by the guest to establish a communication channel with Android's "Keymint" [1] HAL on the host and get access to hardware-backed key resources. That way we have a certificate chain which ties directly into Android Verified Boot [2] and extends to the guest payload without KVM having to be aware of any of it. Since this is all pretty specific to Android, delegating it to the firmware allows others to use their own mechanisms without bloating the privileged code at EL2 or enforcing a specific flow. A straightforward extension in future would be to make this firmware optional when spawning a protected VM, but since we have no need for that in Android (where we require the firmware), we elected to keep things minimal at first. Cheers, Will [1] https://source.android.com/security/keystore [2] https://source.android.com/security/verifiedboot _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel