From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web10.4763.1630576209590396478 for ; Thu, 02 Sep 2021 02:50:09 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ZjJDYilR; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1630576208; 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: in-reply-to:in-reply-to:references:references; bh=REHR6QqxnuGghKOFLcipyvLQn5DzrrkL7YRZKiv4W9I=; b=ZjJDYilRYOl+AAwMaXbRkkS5MKkBAS0QmPxBSIOewkYFTD71lcn3kq5ssGvgLSOhuzBADo /KvOgLd70b+waHRXxpNl3akY5eT9jLWtxcRwh9YFBmhmmXZebub2WVHh1czEpDFpJLI/82 Kn8EdwZTjyySXmDLsc1o2uiG1C23iAI= 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-550-F9JT3wwZN2-oIjEIylDGaw-1; Thu, 02 Sep 2021 05:50:05 -0400 X-MC-Unique: F9JT3wwZN2-oIjEIylDGaw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D951C1854E26; Thu, 2 Sep 2021 09:50:03 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.91]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8A9C560E3A; Thu, 2 Sep 2021 09:50:03 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id C259418000AE; Thu, 2 Sep 2021 11:50:01 +0200 (CEST) Date: Thu, 2 Sep 2021 11:50:01 +0200 From: "Gerd Hoffmann" To: Brijesh Singh Cc: devel@edk2.groups.io, James Bottomley , Min Xu , Jiewen Yao , Tom Lendacky , Jordan Justen , Ard Biesheuvel , Erdem Aktas , Michael Roth Subject: Re: [PATCH v6 15/29] OvmfPkg/MemEncryptSevLib: add support to validate system RAM Message-ID: <20210902095001.butpnnnyvmi3tbnc@sirius.home.kraxel.org> References: <20210901161646.24763-1-brijesh.singh@amd.com> <20210901161646.24763-16-brijesh.singh@amd.com> MIME-Version: 1.0 In-Reply-To: <20210901161646.24763-16-brijesh.singh@amd.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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. 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. 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