From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mx.groups.io with SMTP id smtpd.web08.9914.1605209896090302553 for ; Thu, 12 Nov 2020 11:38:16 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=R/0aqzoz; spf=pass (domain: redhat.com, ip: 63.128.21.124, mailfrom: dgilbert@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605209895; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=iLSjnuLQG4uRpwBTmWJI6a4d3TVo8rDr3WIFDu7JRbE=; b=R/0aqzozvQ2fBUO+VFbe2Yb4G3KyUP77tpzPY+gP2u3XNMMfOOlqndwoMolmFLJ15OKSS2 Hby3c63aCc4/PioP3QCnFRSSBUdDqlzowqT407Kmt9mN4yJ7TD+BYvhVCfeKD0R/+C8s3s HURSfWClEqwzN/YW7CAML15ACcwdObE= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-474-XSvwlb3JPSWHBVSdess6gA-1; Thu, 12 Nov 2020 14:38:11 -0500 X-MC-Unique: XSvwlb3JPSWHBVSdess6gA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 67A9E1074666; Thu, 12 Nov 2020 19:38:09 +0000 (UTC) Received: from work-vm (ovpn-115-60.ams2.redhat.com [10.36.115.60]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 02B655B4C2; Thu, 12 Nov 2020 19:38:06 +0000 (UTC) Date: Thu, 12 Nov 2020 19:38:04 +0000 From: "Dr. David Alan Gilbert" To: Brijesh Singh Cc: James Bottomley , devel@edk2.groups.io, dovmurik@linux.vnet.ibm.com, Dov.Murik1@il.ibm.com, ashish.kalra@amd.com, tobin@ibm.com, david.kaplan@amd.com, jon.grimm@amd.com, thomas.lendacky@amd.com, frankeh@us.ibm.com Subject: Re: [PATCH 0/4] SEV Encrypted Boot for Ovmf Message-ID: <20201112193804.GJ2905@work-vm> References: <20201112001316.11341-1-jejb@linux.ibm.com> <5cb9e43e-b22f-0ffc-3b02-1b173454de9f@amd.com> MIME-Version: 1.0 In-Reply-To: <5cb9e43e-b22f-0ffc-3b02-1b173454de9f@amd.com> User-Agent: Mutt/1.14.6 (2020-07-11) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dgilbert@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit * Brijesh Singh (brijesh.singh@amd.com) wrote: > Hi James, > > Thanks for series, I glanced at it, the changes looks okay to me. I have > one questions. > > How does the grub locate the disk decryption key ? Am I correct in > assuming that the gurb is iterating through a configuration table > entries and comparing the Secret GUID to locate the secret key. As per > the SEV spec, its possible that a guest owner can call the secret > injection more than once. I don't see the patch consider that case, > should we support this or limit to one inject?  Maybe Qemu can enforce > this property. That's interesting, I hadn't realised that was possible - however, I can't see a way to use it - for it to be useful, you would have to have a way for the guest to communicate to the owner that it had finished with the first injection and would like the next; but if you already have a way to communicate from the guest to the owner to request stuff, then you could pass a new secret by that comms route? > Do you see any need for the Linux kernel needing to access the secret? > Since the secret blob is available through configuration table, I > believe we can have a platform driver that can read the configuration > table and retrieve the secret blob. I guess it depends if you get the Grub to pass the fs secret down to the kernel or let it pick it up itself from the same place. Dave > > thanks > > On 11/11/20 6:13 PM, James Bottomley wrote: > > From: James Bottomley > > > > This patch series is modelled on the structure of the Bhyve patches > > for Ovmf, since it does somewhat similar things. This patch series > > creates a separate build for an AmdSev OVMF.fd that does nothing > > except combine with grub and boot straight through the internal grub > > to try to mount an encrypted volume. > > > > Concept: SEV Secure Encrypted Images > > ==================================== > > > > The SEV patches in Linux and OVMF allow for the booting of SEV VMs in > > an encrypted state, but don't really show how this could be done with > > an encrypted image. Since the key used to decrypt the image must be > > maintained within the SEV encryption envelope, encrypted QCOW is not > > an option because the key would then have to be known to QEMU which is > > outside the encryption envelope. The proposal here is that an > > encrypted image should be a QCOW image consisting of two partitions, > > the normal unencrypted EFI partition (Identifying it as an OVMF > > bootable image) and a luks encrypted root partition. The kernel would > > be inside the encrypted root in the /boot directory. The secret > > injected securely through QEMU is extracted by OVMF and passed to grub > > which uses it to mount the encrypted root and boot the kernel > > normally. The creator of the secret bundle must be satisfied with the > > SEV attestation before the secret is constructed. Unfortunately, the > > SEV attestation can only be on the first QEMU firmware volume and > > nothing else, so this patch series builds grub itself into a firmware > > volume and places it inside OVMF so that the entire boot system can be > > attested. In a normal OVMF KVM system, the variable store is on the > > second flash volume (which is read/write). Unfortunately, this > > mutable configuration provided by the variables is outside the > > attestation envelope and can significantly alter the boot path, > > possibly leading to secret leak, so encrypted image boot should only > > be done with the OVMF.fd that combines both the code and variables. > > the OVMF.fd is constructed so that it becomes impossible to interrupt > > the boot sequence after attestation and the system will either boot > > the image or fail. The boot sequence runs the grub.efi embedded in the > > OVMF firmware volume so the encrypted image owner knows their own > > version of grub is the only one that will boot before injecting the > > secret. Note this boot path actually ignores the unencrypted EFI > > partition. However, as part of this design, the encrypted image may be > > booted by a standard OVMF KVM boot and in that case, the user will > > have to type the encryption password. This standard boot will be > > insecure but it might be used by the constructor of the encrypted > > images on their own private laptop, for instance. The standard boot > > path will use the unencrypted EFI partition. > > > > Patches Required Outside of OVMF > > ================================ > > > > There is a patch set to grub which allows it to extract the SEV secret > > area from the configuration table and use the secret as a password to > > do a luks crypto mount of root (this is the sevsecret grub module). > > > > There is also a patch to qemu which allows it to search through the > > OVMF.fd and find the SEV secret area which is now described inside the > > Reset Vector using the existing SEV_ES reset block. This area is the > > place QEMU will inject the encrypted SEV secret bundle. > > > > Security of the System > > ====================== > > > > Since Grub is now part of the attested OVMF.fd bundle, the VM owner > > knows absolutely that it will proceed straight to partition decryption > > inside the attested code and boot the kernel off the encrypted > > partition. Even if a different QCOW image is substituted, the boot > > will fail without revealing the secret because the system is designed > > to fail hard in that case and because the secret is always contained > > within the encrypted envelope it should be impossible for the cloud > > operator to obtain it even if they can pause the boot and examine the > > machine memory. > > > > Putting it All Together > > ======================= > > > > This is somewhat hard. You must first understand how to boot a QEMU > > system so as to have the VM pause after firmware loading (-S option) > > and use the qmp port to request an attestation. Only if the > > attestation corresponds to the expected sha256sum of OVMF.fd should > > the secret bundle be constructed and injected using qmp. The tools > > for constructing the secret bundle are in > > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAMDESE%2Fsev-tool%2F&data=04%7C01%7Cbrijesh.singh%40amd.com%7Ceb007b21e05c4e9c05cf08d8869fc874%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637407368116062086%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BbCtv37bH0%2B6JDLM3afAubVN6K0Y%2FdO4TRz4ZkP1AKg%3D&reserved=0 > > > Where you able to use the sev-tool as-is to generate a secret blob that > can be injected through the Qemu QMP interface? The reason why I am > asking this is because the last time when I looked at the sev-tool I > found that it did not generated the blob which was in the correct format. > > > > > > James > > > > --- > > > > James Bottomley (4): > > OvmfPkg/Amdsev: Base commit to build encrypted boot specific OVMF > > OvmfPkg/AmdSev: add Grub Firmware Volume Package > > OvmfPkg: create a SEV secret area in the AmdSev memfd > > OvmfPkg/AmdSev: Expose the Sev Secret area using a configuration table > > > > OvmfPkg/OvmfPkg.dec | 6 + > > OvmfPkg/AmdSev/AmdSevX64.dsc | 1035 +++++++++++ > > OvmfPkg/AmdSev/AmdSevX64.fdf | 515 ++++++ > > OvmfPkg/AmdSev/Grub/Grub.inf | 37 + > > .../SevLaunchSecret/SecretDxe/SecretDxe.inf | 38 + > > .../SevLaunchSecret/SecretPei/SecretPei.inf | 46 + > > .../PlatformBootManagerLibGrub.inf | 84 + > > OvmfPkg/ResetVector/ResetVector.inf | 4 + > > .../PlatformBootManagerLibGrub/BdsPlatform.h | 179 ++ > > .../SevLaunchSecret/SecretDxe/SecretDxe.c | 29 + > > .../SevLaunchSecret/SecretPei/SecretPei.c | 26 + > > .../PlatformBootManagerLibGrub/BdsPlatform.c | 1538 +++++++++++++++++ > > .../PlatformBootManagerLibGrub/PlatformData.c | 213 +++ > > OvmfPkg/AmdSev/Grub/.gitignore | 1 + > > OvmfPkg/AmdSev/Grub/grub.cfg | 35 + > > OvmfPkg/AmdSev/Grub/grub.sh | 54 + > > OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 4 + > > OvmfPkg/ResetVector/ResetVector.nasmb | 2 + > > 18 files changed, 3846 insertions(+) > > create mode 100644 OvmfPkg/AmdSev/AmdSevX64.dsc > > create mode 100644 OvmfPkg/AmdSev/AmdSevX64.fdf > > create mode 100644 OvmfPkg/AmdSev/Grub/Grub.inf > > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.inf > > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.inf > > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBootManagerLibGrub.inf > > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.h > > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretDxe/SecretDxe.c > > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.c > > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatform.c > > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformData.c > > create mode 100644 OvmfPkg/AmdSev/Grub/.gitignore > > create mode 100644 OvmfPkg/AmdSev/Grub/grub.cfg > > create mode 100644 OvmfPkg/AmdSev/Grub/grub.sh > > > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK