From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (NAM10-BN7-obe.outbound.protection.outlook.com [40.107.92.58]) by mx.groups.io with SMTP id smtpd.web11.7917.1605202327724328785 for ; Thu, 12 Nov 2020 09:32:07 -0800 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@amdcloud.onmicrosoft.com header.s=selector2-amdcloud-onmicrosoft-com header.b=zFNLOsEc; spf=none, err=SPF record not found (domain: amd.com, ip: 40.107.92.58, mailfrom: brijesh.singh@amd.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FeKXrvCkr/HI9CWiubOyT8qw/L9ljlamh4W01AbK3fQ6NoQUFj8TZseyH4+Aq3m5mJaPFE7o21cywyQb47HCET8ZcMkYU7c2K03pWCZE9vko4jA1W2+H3nTEsuhCPqIy36HPixwLTAs1WXb2i80qy5dod+5hz4cciGtx/yJWzFoZgVkzv1j6SvQ0E27Fog7OXdFj0I3QuoljpW9scVXOW3VBL8RKJv3Iq5g+KZtLVJjcTvFwIyikOD6Oisnv0PC5Uku8HeTR+kAqZtS+s5zPtoyrgTXfO9AHP6atsfyPZn2QVj68AEj3VuITFiuZuvwdDaBriMoKB8Bq1zgSAuSe+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q7r9q6OpX7ryiAdn12E2OZwAgEJNJY4ND+fmHM8QDEw=; b=mNunSJdrmo02dGSq5m046IWfvlp7j8aLHeqAfdbAHm7Gk2P+kDKIjpdNBddBPNZ0FGK/B3Ft6HzMo5Aief+myZlg/l+CCoSoU3rU2SY4i44eMGSlPSHODejFekjyAg4l3f/jEGpdcB9vZkNZ+tjLid2rbzHukg+C/rS2A0J+XU7nAcl8C1sQ2Bgf6mDjAnpD6r41uVxTkIptz/zft+wMxMK68RUUuv12iRd/9XZXYQBcotG3iGy5N8tiYuW7e+f+zJN9Tt8bArKfSJU1PzBrVrI8+LB2zFPa51x2xFxN/xRHKCIZ3WxrBm9BIrvdOZ2k4kpxQgJvr5hx90b4ArLQXA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amdcloud.onmicrosoft.com; s=selector2-amdcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q7r9q6OpX7ryiAdn12E2OZwAgEJNJY4ND+fmHM8QDEw=; b=zFNLOsEcYLp17df0udaEnM7U3Ex/KpPWWaPXB9vxxcieYOCkv8c9JWC8Jubzw/bowxC82ArhS+y9awY2TOa802erdlDJVvj+mBpKj7r+UzUrTzFdgSLJpt9hdIWyo+yJll2GzKNhWXfLNgZBtn/tutSBaSWYUKtHL+0546+Jogc= Authentication-Results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=amd.com; Received: from SN6PR12MB2718.namprd12.prod.outlook.com (2603:10b6:805:6f::22) by SN6PR12MB2766.namprd12.prod.outlook.com (2603:10b6:805:78::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.25; Thu, 12 Nov 2020 17:32:04 +0000 Received: from SN6PR12MB2718.namprd12.prod.outlook.com ([fe80::e5fa:93a4:6efe:9c68]) by SN6PR12MB2718.namprd12.prod.outlook.com ([fe80::e5fa:93a4:6efe:9c68%6]) with mapi id 15.20.3541.025; Thu, 12 Nov 2020 17:32:04 +0000 CC: brijesh.singh@amd.com, 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, "Dr . David Alan Gilbert" Subject: Re: [PATCH 0/4] SEV Encrypted Boot for Ovmf To: James Bottomley , devel@edk2.groups.io References: <20201112001316.11341-1-jejb@linux.ibm.com> From: Brijesh Singh Message-ID: <5cb9e43e-b22f-0ffc-3b02-1b173454de9f@amd.com> Date: Thu, 12 Nov 2020 11:32:01 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 In-Reply-To: <20201112001316.11341-1-jejb@linux.ibm.com> X-Originating-IP: [70.112.153.56] X-ClientProxiedBy: DM6PR06CA0035.namprd06.prod.outlook.com (2603:10b6:5:120::48) To SN6PR12MB2718.namprd12.prod.outlook.com (2603:10b6:805:6f::22) Return-Path: brijesh.singh@amd.com MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from Brijeshs-MacBook-Pro.local (70.112.153.56) by DM6PR06CA0035.namprd06.prod.outlook.com (2603:10b6:5:120::48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21 via Frontend Transport; Thu, 12 Nov 2020 17:32:03 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 49005620-4d6d-4dfb-ccfb-08d88730df0e X-MS-TrafficTypeDiagnostic: SN6PR12MB2766: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: uItVA3Lc2pLqJbTGZCAnAuMXLWe44JMRHMMgQj1J48XJsxV6QtRFjrPVIq/9Ov/TODrZQqOH8bi05ydUFm7jKlEHjN9YQiY8yLqKFM6F6WsuAdKzPQuJtwmjYhvT2jVoXznk1Oi493O72oH4kcrYSN0VXWY8jteVq+kFJpk4PnTa6ueTeL1Etfb380iTMk33OjO/ehWHXP0GbU/Ozj7GRzvszVj6tQeVm+8+13bJYpjQCbTmE3C/Z0aFsNzlTQa6H2LVUZlC716D+nJ6ds+ZgYruko8NhUWw/Uh/Rv8l0IPcFZFj1aSNeV8T4O6mcHb3JVHvLkvfcI7gWIP7nEM5K/UUVIGuLA3Nf1bAVDRQcsQBkZvxdbrKFayCsp0BtFToVt4vLw7IpUZ3Ix/5o0j/I0Y1psZDzDEWETfF+bwjkl7u8Nth0Iy4J9WiSvR655sgc6h3OmcT9moqRDMFASPoXg== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SN6PR12MB2718.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(346002)(376002)(396003)(366004)(136003)(39860400002)(16526019)(31686004)(66476007)(66556008)(53546011)(52116002)(316002)(8936002)(966005)(44832011)(19627235002)(956004)(26005)(2616005)(6506007)(4326008)(36756003)(83380400001)(66946007)(6512007)(45080400002)(5660300002)(86362001)(478600001)(2906002)(31696002)(8676002)(6486002)(186003)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData: DbDE6tUKmyQsmM0jeclOvFYCzmMcQVsl6WrMXpEkWHydXojoyNHlg6Y+CtEOTB0Z31XuovhK1sL6TQyV1/I9OhCxwvv36LhHDc4R5rMfAeiwHYMnKSqN4Q6kD8FOxQe0Sf/BRf5MjTaJIpAFsLIM9EhCZN/lnkXBYIW/enxSI++j/+N4GqZjAAdhRF2BcaVaQHe2kqawEcGNn3Veae3Y7xKKTMt4+qn/vH/e1fNtsNRhTJc/A9qiRkKzxidFidZSZ/i7zT1lnmD74FrKgBbh2YTMD0UNb/uaL8ewEkGruF2/RiXFkT1De9ob3Z3MD+H37RnL2ZmHJkj2kE8tPsuRkimJTJeeZ6a9PYvSjNqeySJQuQVvC18akImqZ0afWPPTLlAaKXubQBAk664FF804MDxfQgNbZ+RvZXs2/7iCkdKfJqY2fc7Av+7gr7hcfAadYkkUxQCb3iT/uhtZ3JTltkVm4aZ5i7WiivwxXQn0i6gV0IV1nu4pF5gzMtcbiIzZAjaIge6Ce7dtW3p/dODSdQg/q8YAL01C7jd/V5UzfHLP6Cyc5kPMCbSpMfTRQFcuq4rWnlsGIUVg3xrWfhSTWKJBxcsBZ8Z7C3DJGQu6v11iLOQLSWLKUQEivnUq4fRNKV2LrpvvsqsXC6a5a9763A== X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 49005620-4d6d-4dfb-ccfb-08d88730df0e X-MS-Exchange-CrossTenant-AuthSource: SN6PR12MB2718.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Nov 2020 17:32:04.6872 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: v+2FK9f9QGIqKyHOSODpM/tB7ZZRbVR7FmUUzSe1DL0tpVB7q66kzOknb5layhsdFsIj+PzjdO/vGd931BJDVg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR12MB2766 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US 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?=C2=A0 Maybe Qemu can enforce this property. 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. 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 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=3Dhttps%3A%2F%2Fgithu= b.com%2FAMDESE%2Fsev-tool%2F&data=3D04%7C01%7Cbrijesh.singh%40amd.com%7= Ceb007b21e05c4e9c05cf08d8869fc874%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C= 0%7C637407368116062086%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi= V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3DBbCtv37bH0%2B6JDL= M3afAubVN6K0Y%2FdO4TRz4ZkP1AKg%3D&reserved=3D0 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.in= f > create mode 100644 OvmfPkg/AmdSev/SevLaunchSecret/SecretPei/SecretPei.in= f > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformBo= otManagerLibGrub.inf > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/BdsPlatfor= m.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/BdsPlatfor= m.c > create mode 100644 OvmfPkg/Library/PlatformBootManagerLibGrub/PlatformDa= ta.c > create mode 100644 OvmfPkg/AmdSev/Grub/.gitignore > create mode 100644 OvmfPkg/AmdSev/Grub/grub.cfg > create mode 100644 OvmfPkg/AmdSev/Grub/grub.sh >