From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM04-DM6-obe.outbound.protection.outlook.com (NAM04-DM6-obe.outbound.protection.outlook.com [40.107.102.77]) by mx.groups.io with SMTP id smtpd.web10.7006.1630589663370475665 for ; Thu, 02 Sep 2021 06:34:23 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@amd.com header.s=selector1 header.b=xaLwwS0L; spf=permerror, err=parse error for token &{10 18 %{i}._ip.%{h}._ehlo.%{d}._spf.vali.email}: invalid domain name (domain: amd.com, ip: 40.107.102.77, mailfrom: brijesh.singh@amd.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DeZmcghdFr2Mua++7guyHmqJ8Cmckebcn0TwxAYC9jB98oEn1vobeqVrKdV2p9lQ7Y2qnM2up1tXyZ8aqyLS3V8ek5z9MnMT2zQP7KdR1ibHCbQfZm96f2JbYPFba/P35dk+ixelE3icsWf4KF8u+EuxTJjVteB+HVqjsOSwq3wUo/VoRXKC07bnTZ9YDRirJlCjqJkR155L0DIE1bjsI8WS/AvzwAqeRTLCmKOQKXyyFSAKUHKBelvBjmOGRSxXsV3EfVihXmHpLF1TpO2A0q5jjLhCI75ltf1dh+Cx3pol6kjUn2mcwUwlxXX7DSEYXunU7+pS6lArqMPKPAtdow== 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; bh=CZX/6STflhtMv51EIR1cX85T5tEeMoQXEEQM1ybc6Cg=; b=UBywH8c2W1d0gYHtOZ9+aN6SEhbZDpQlggmamSrPQbOpbSeKrwGHEY4iMYTekywwe/uEbl7BpAhWI6DEiXH8BlB2Pqkm36U5wu0v5U5s8MO4bYMXbMg81SD+nXd4ETvzWUYSb4wcfKvdk3ONy/B1tqkeeovY4e6qqIPLwNz2ACkRNJhLK8ERfopMDOFa8IZzyhodsid2ajfWO/kta20MX1zgnuVQo11+FvEgTaBIvCKMhHgiEO4T57ftxRuIqE6vgT63DCCU0vtVVXUGu7XD/2WDufFQc1TzuRtsgCdEiGV51FHTH1GCohCKrX1BPjXoRvEPFvhBOytFzwQfkBHErw== 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=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CZX/6STflhtMv51EIR1cX85T5tEeMoQXEEQM1ybc6Cg=; b=xaLwwS0LcykOMETsKQiFHWFtVNy1JriIXoHQ7K0abxEZJ0WRpfSRqDn890ToB8rrapUMrFIGWxQxbLP+LptCss8VaiD4Bh+3kdtIZ/82xtXSzGo+vpcnCh4tN30XmjcSWAiAAmeoUM6dBD4GbRGlcLpNnWzVGfT3Cs3xqfDlDD8= Authentication-Results: amd.com; dkim=none (message not signed) header.d=none;amd.com; dmarc=none action=none header.from=amd.com; Received: from SN6PR12MB2718.namprd12.prod.outlook.com (2603:10b6:805:6f::22) by SA0PR12MB4415.namprd12.prod.outlook.com (2603:10b6:806:70::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.17; Thu, 2 Sep 2021 13:34:21 +0000 Received: from SN6PR12MB2718.namprd12.prod.outlook.com ([fe80::78b7:7336:d363:9be3]) by SN6PR12MB2718.namprd12.prod.outlook.com ([fe80::78b7:7336:d363:9be3%6]) with mapi id 15.20.4478.021; Thu, 2 Sep 2021 13:34:21 +0000 Subject: Re: [PATCH v6 15/29] OvmfPkg/MemEncryptSevLib: add support to validate system RAM To: Gerd Hoffmann Cc: devel@edk2.groups.io, James Bottomley , Min Xu , Jiewen Yao , Tom Lendacky , Jordan Justen , Ard Biesheuvel , Erdem Aktas , Michael Roth References: <20210901161646.24763-1-brijesh.singh@amd.com> <20210901161646.24763-16-brijesh.singh@amd.com> <20210902095001.butpnnnyvmi3tbnc@sirius.home.kraxel.org> From: "Brijesh Singh" Message-ID: <19ba1918-7c3b-04d7-f415-8c5b1a9e64c8@amd.com> Date: Thu, 2 Sep 2021 08:34:19 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 In-Reply-To: <20210902095001.butpnnnyvmi3tbnc@sirius.home.kraxel.org> X-ClientProxiedBy: SA0PR11CA0192.namprd11.prod.outlook.com (2603:10b6:806:1bc::17) To SN6PR12MB2718.namprd12.prod.outlook.com (2603:10b6:805:6f::22) Return-Path: brijesh.singh@amd.com MIME-Version: 1.0 Received: from Brijeshs-MacBook-Pro.local (70.112.153.56) by SA0PR11CA0192.namprd11.prod.outlook.com (2603:10b6:806:1bc::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.20 via Frontend Transport; Thu, 2 Sep 2021 13:34:20 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ef6d6ed7-5c39-4a13-ff2e-08d96e165efa X-MS-TrafficTypeDiagnostic: SA0PR12MB4415: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: JqQHgw5ZknuMk+t3Ory0G+OAAtoURfjamGiHIN5WamH1+bKYk3qrAF2TGRpr/7T0LFz9c/jYXM+bjGcur8H1iOAzl+I98tcUm9CK5M/IGldCFn0lAnmu64lUkSEEorugQV0ssbFyqQD1CIPKhqaj+5Juk4D46K0YOGDHcGj4EzMnGWj9HKf0WTKZNxCx3FO8b9/85EAmSMDl/7Njpja9zpwIMsgnZYFE/ua+w+yQfkdEJ9s1jYY4++VoIqy2pYs5wcrEMVwdImbS2a+Pmry6QmyBvsHXGMyXvQfuytFODk6BJQ1TzOE5RHp2CH3GwTb08BY5Dk0xB1S6tbf1ojeABezmtP/2GrE5Rm+hOm9fDXYQmQY+He9ScvLWdYuBHifNF5vWQHarZjSWW4u8mqFO666j4Hf7l+YiG90X1Cfq15COzxd0XffDHvx9h9tntwozWYupQkHWapjDSKIJ7GEuosoul/jmOAGJUbifRu2qBFZ8kLxPwffPlJ6H4LCbNoAvoLqzR0AwP4wr2xkM/Dcx55wv8q3j7E+BwB73JpAILOE/2yS2B05XGgZRw2IAh5EepiY0aq4dGG0Myjig5feCxQjRj/ekhJ+wADriX8yNpBRidqMb9TQCb4z2q/Af3cB+X82IokS8VA4fELQgOr7+wzcT9egTYLyMl4zQ1pMQEUMsSDtZdDpzcvLQGU1RieQdsq32oKe1Jp7HxBY4pXzvVtZ8BYeSO6jD8rqaCZT1BuNSm+tgfkItBkEmO0PzXNXfdeJ2K+bOGKOWddHsGvmyXA== 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)(396003)(366004)(346002)(136003)(39860400002)(376002)(5660300002)(36756003)(6486002)(44832011)(54906003)(316002)(2616005)(66556008)(956004)(478600001)(31686004)(38100700002)(38350700002)(31696002)(86362001)(4326008)(52116002)(6512007)(2906002)(6916009)(53546011)(83380400001)(6506007)(66476007)(8936002)(66946007)(15650500001)(26005)(8676002)(186003)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UVYyRURiZmhVRW9NV1h0NzJ6VlNOSU9UU0RtTjAzd1E1MldJOTdzbytUTnFj?= =?utf-8?B?cXd1Y1NVSGxiRUgzUU5XU3diaU5zTXN3dU9lWXluaWF4RkU4SXBYYllrYWZo?= =?utf-8?B?b3ZrWm5XcklGMUV6UmdlMnlzeUFUWi9Ya3dhQzh6anhnSzY4dlN4VCtQczNm?= =?utf-8?B?bk5VNGIrL0c5WlFmL1RWb0VvNHo5bWdzWE4wOThMY2JrSnRYQkxOM3MrWW5p?= =?utf-8?B?UG1XODBQdERBMXgzSW12NWwzZnFFOUVnU2FmVEtmK2hSajBLYUVyWFZjdzhv?= =?utf-8?B?d1NTU1FrbG82RGw5NG45REEzYlV6ZTI2eHdIMGM5dWwyVE5mNFJ4UmdYL1dI?= =?utf-8?B?TEx0aHcyYnI0TWQ0N1hnb0xZR2tmM3RZUzRJSkxnQXdJSnB0YWVqL3ZIZ1E0?= =?utf-8?B?ZzJLaVVZMWxzUnhvM00zNDAwWkRoVEhWYmZtNU1hZkNtZXBGM01XRnFEcW94?= =?utf-8?B?S1FHdncrN0QwYndDSm1Wc3pMMkphellGemxYc3pWTHZrNmlCZHdIR1VXOUdp?= =?utf-8?B?ckNna1ZRZ2lwei9GSVRLYjBJZERNTG81QWtQZmo4SnZCbjJqWGJaT2M0blFV?= =?utf-8?B?SVZGUW9zMjFEN1lsWHB4RDFNOUFPd3ROcW1pM1ZtMEVyYlpMbWxSY2srRVJ6?= =?utf-8?B?OXlaZk1oU2NjVjFIWmtwUWd5WlN5ZGpwdzhKRmtJcjZBN2VvNkRLb0lPS2xI?= =?utf-8?B?cTNvMlZrOFdFcXN5YXI4MnBnaGtGNmZpSXJxQTNYYVNyTmtwNTB4Q0NkUGFL?= =?utf-8?B?cGlKV2tyMG9EWlV2dmo3b1hVN3BVL0Zpd25kRmNvR1BKL1dUTjh6aWI0N1h1?= =?utf-8?B?Vm1WeUlHY204QTdKUkswaHREWDUrTEFKKytRekRHWlJncXVNdUltSVFBZ1Zl?= =?utf-8?B?dlh4cW8vaWk1anUyZjFIQkJjMW04TUlhSmpaQVhGd2MrY1QrVjNCUjByVVRa?= =?utf-8?B?OUx2dzlKTDB6NG9uYnh2U2llMzZONUZKZk40SVhMVGF3ZVRhMVQzUWFabHV2?= =?utf-8?B?amJ1N0tLL3RrbXlDbWJUVlVxakFhbmt5eE52YWpLSExtdGR1ZG1HMDRNQVEv?= =?utf-8?B?SFE3Qktqbi9nQ3NpbWlYUTM1a3NhWFB0a2hyOUV2dC96TUl6MkpPNElxc3ln?= =?utf-8?B?SHVGOGVKazE4YlMrUnl0UFYzUDl6WXR3OUdLUXNVbmJlQ3o0MnFtQWhWUnc3?= =?utf-8?B?dWE5VURYcVFScnJQOCtObXUzMTFSOXI4TTByU3ExMzE3VTRmTjcvamxLNkNq?= =?utf-8?B?bWFuRGRrSDdXcFMzQ0xQemQwd1FjNW0ya0srNVZKdTQwTHlqN2FsTzJ2L1Nu?= =?utf-8?B?NlEvVUkwM1QzeGROR0M5a1ZML1pZdmhRTTFSbXpIODRqcVZneW1IUGdhdUVP?= =?utf-8?B?WENYZ1JrcEJsZkxYOEMvNHVsallobHFNQTNaR3NpV2xmY3FmZW4ya29mZTZu?= =?utf-8?B?Y1d1V0t1Y2plOG5GaEtoQzFodElWVjJ4SkhHZFpnTGtGOFkwUnZlRS9HTXBV?= =?utf-8?B?MVMrSUd6TGNUeEF2enlrSkNsaHhBYjhrN1Q0VzhyRS9PS1I2MEZuVFB6dzND?= =?utf-8?B?LzlCNkF1aS9rZmFrUGRYS3dKTXZMRGEzYVR0SW1JRFFGbHpqSVIzakdUcWRN?= =?utf-8?B?L282THJxUmg5VU1RbE9wUVNtb1ZXL0p5RkdRc294K0lPeW42NVVsZmVjMnhl?= =?utf-8?B?blhiMzZTL1dSbFgxeG1MenQ4ZE8xMm16RlpFVEJET0pHaTIwWlE1VDVSN2t3?= =?utf-8?Q?J6qq4ihazHRFFdtVsmYPS4hWHrtZSwAQ0T0gYj6?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: ef6d6ed7-5c39-4a13-ff2e-08d96e165efa X-MS-Exchange-CrossTenant-AuthSource: SN6PR12MB2718.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Sep 2021 13:34:21.3088 (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: 8L9QvUf4EKnJt1GBaT5w1OShUqcP/iNiN8gpYjNjgzyfF9HDqr2h1RCMPMUmHojtF2UDJLykDBV7w2pxUkloNQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB4415 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US On 9/2/21 4:50 AM, Gerd Hoffmann wrote: > Hi, > >> During the guest creation, the boot ROM memory is pre-validated by the >> AMD-SEV firmware. The MemEncryptSevSnpValidateSystemRam() can be called >> during the SEC and PEI phase to validate the detected system RAM. > [ for this and the following few patches ] > > So, sev-snp and tdx have the same fundamental requirement here. Both > must track what the state of page ranges is. Both must talk to the vmm > before they can actually use pages. snp calls this "validate", tdx > "accept", but the underlying concept should be roughly comparable. Yes, both the technologies need to accept/validate the pages before access. Both the hypervisor and guest implementation will be different. e.g., in SNP, communication to the hypervisor is done through the VMGEXIT defined in the GHCB spec, whereas TDX will follow a separate exit on how it reaches the hypervisor calls the TDX shim, etc. All the platform-specific details on how the validation is executed should live inside the vendor-specific libraries. That is why I added all the validation flow in MemEncryptSevLib (which is AMD SEV specification library that provides routines to change the page state etc). The Intel TDX patches add a similar flow in the TDX specific library and Ovmf core calls it. Once both the libraries are in, we can develop a shared library that OVMF can use. IIRC, in the TDX proposal, I got the impression that TDX implementation will skip the PEI phase, and it jumps from SEC->DXE. The SEC phase somehow will know the guest memory range and validate it. For SEV-SNP, we are trying to stick to the existing boot flow and validate the memory as soon as its discovered during the PEI phase. As explained in the commit, there are multiple options we can take to validate the guest memory. 1) The OVMF PEI validates the entire RAM while its discovers it. 2) The OVMF memory probe routine marks the discovered system RAM as "Unaccepted". 3) The OVMF memory probe routine does nothing during the discovery phase. Each of these approaches have advantages and disadvantage Approach #1 The main advantage is that EDK2 core and guest OS can accept the memory without any validation step. It will be slower because validation will require the hypervisor to exist and also touch the memory. For SNP, a new VMGEXIT was added in the GHCB spec that can be used to batch multiple validation requests. e.g. one PSC (Page State Change) can contain up to 253 entries, and each entry can cover up to 2MB. In other words, we can validate up to 500MB in one VMGEXIT. Approach #2 The main advantage of this approach is that it can support lazy validation, and it can undoubtedly help reduce boot time. But to support this, the EDK2 core memory management needs to be enhanced to know the unaccepted memory type and validate it before access. The EDK2 core should also build the EFI memory map to communicate to the guest OS on validated so that guest OS does not double validation. For this to work, the guest OS needs to know how to deal with the unaccepted EFI memory range. Approach #3 Validate memory on demand. In SNP hardware, access to the unvalidated page causes a #VC. The guest BIOS and OS can use the #VC (page-not-validated) exception and validate the range from exception handler itself. It looks attractive until we run into a situation where the guest is doing a memset() of significant memory, and each access is causing the #VC and thus making the boot or run slow on the first access. This patch series implements #1. And we will be looking at approach #2 after the base is enabled. Approach #2 builds upon #1. As you highlighted below that we have not seen the patches for the Lazy validation here so its hard to comment but I am hopeful that it will integrated just fine with the SNP. > The vmm part obviously needs to be different. I can't see any good > reason why the state tracking and the state hand over from one boot > stage to the next (vmm -> sec -> pei -> dxe -> os) should be different > though. Having a common workflow makes long-term maintenance and > testing easier. > > So, can you all look at each others patches and find common ground > here? It worked out well for the WorkArea, so *please* continue > that way. > > This series seems to side-step most of this by validating all memory in > the pei stage, so there is nothing to hand over to dxe and os. Only the > range where the compressed code gets uncompressed to must be passed from > sec to pei. And there is the memory range registered for pre-validation > by the vmm. Yes, I am taking phased approach. Making the Lazy validation work will require changes in both the edk2 and guest OS core memory management. > Intels (long-term?) plan seems to be to do lazily validate/accept > memory, triggered by memory allocations, to reduce boot time. Which > implies the dxe memory management core needs to be aware of page state > and invoke an vmm-specific protocol to handle validation/acceptance. > Concept posted to the list earlier this week. Slides only so far, no > patches yet. > take care, > Gerd >