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.129.124]) by mx.groups.io with SMTP id smtpd.web09.25306.1641196951291876591 for ; Mon, 03 Jan 2022 00:02:31 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=cTIXFlhu; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1641196950; 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=Y4ZGA5yOXHUbQZGyv6+d3Y0TRIBrKBWWE8CzWSTfzZg=; b=cTIXFlhupD8Y+HhDE0v+FTIzHpBR34IKScigfUSGDfaVNcYMWbhaZsPo6upsc5rcXgMitN g+OIrmzh1R38d7GO4bLJ3hhAEzMwPn8NesgAgVbY7sHzkOPFY1igMSrJgay6JXdbeU5w+U 5SGCXJprZ/3U6xXABYWQCfOa6x6xtd8= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-425-MDiQ-p6LMv2h-5gAGQk_0Q-1; Mon, 03 Jan 2022 03:02:22 -0500 X-MC-Unique: MDiQ-p6LMv2h-5gAGQk_0Q-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 72A71802C94; Mon, 3 Jan 2022 08:02:20 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.193.24]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2BD8476E3D; Mon, 3 Jan 2022 08:02:20 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id A9DFE180039F; Mon, 3 Jan 2022 09:02:18 +0100 (CET) Date: Mon, 3 Jan 2022 09:02:18 +0100 From: "Gerd Hoffmann" To: "Xu, Min M" Cc: "devel@edk2.groups.io" , "Kinney, Michael D" , Brijesh Singh , "Aktas, Erdem" , James Bottomley , "Yao, Jiewen" , Tom Lendacky Subject: Re: [edk2-devel] [PATCH 08/10] OvmfPkg: Update Sec to support Tdvf Config-B Message-ID: <20220103080218.ap7tktgh4fuvw6sf@sirius.home.kraxel.org> References: <20211214134126.869-1-min.m.xu@intel.com> <20211214134126.869-9-min.m.xu@intel.com> <20211215102753.m4bp56bdxzgmdzkr@sirius.home.kraxel.org> <20211216142525.pkaxszwaevlpg4ap@sirius.home.kraxel.org> <20211220121145.aiqcqs6vd2hb2sb4@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 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, > PCDs cannot be set in SEC phase, so the values should be saved in a > Hob (for example, PLATFORM_INFO_HOB). In early DXE phase these values > are set to the PCDs. This is how TdxDxe does today. > > Other tasks can be done in SEC phase. I think there should be a lib > (for example, PlatformPeiLib) to wrap these functions so that they can > be re-used by OvmfPkg/PlatformPei. Yes, I think we need a PlatformLib for the platform initialization code. With PEI we would simply link the lib into PlatformPei, without PEI we would link parts of the lib into SEC and parts of the lib into DXE. > PEI-less booting up legacy guest doesn't support TPM. > > So to boot up legacy guest without PEI phase, there will be below changes. > 1. OvmfStartupLib: (like TdxStartupLib) > - Decompress DxeFv, locate DxeCore, create IdentityMappingPageTables, then jump to DxeCore. Yes. Basically rename TdxStartupLib to OvmfStartupLib and add some IfTdx() checks. > 2. PlatformPeiLib: > - Wrap the functions to do memory initialization, etc. (see tasks 1-5) Yes. Move code from PlatformPei to PlatformLib. Might also need some reorganization due to SEC restrictions. > 3. OvmfLegacyDxe > - Set the PCDs (see task 6) Well, in Tdx mode you have to set some PCDs too ... Also not sure we actually need a new Dxe. Can't we just handle that in PlatformDxe in case of a PEI-less boot? > I know there are many discussions in above options. Can we follow below road map so that we can discuss 3 (How to achieve ONE Binary) in more details? > 1. Basic Config-B (PEI-less and only Tdx guest) > 2. Advanced Config-B (RTMR based measurement) > 3. One Binary Config-B (support legacy guest) IMHO step #1 must be reorganizing the platform initialization code for PEI-less boot (create PlatformLib as discussed above). This patch series side-steps that by simply duplicating the code. PCI initialization for example. Also setting the tdx PCDs. Having two (or even more) copies of the same code in the tree is a bad idea though. It makes long-term maintenance harder for various reasons. > > ... and given that TDX-capable > > hardware is not yet production ready I find it rather important that testing > > the PEI-less boot workflow does not require TDX. > > > > It'll also make it much easier to add CI coverage. > I am thinking if SEV features are covered in CI? > Because I want to make sure our changes don't impact SEV. AmdSevX64.dsc has build-test coverage. There is no qemu boot test because FlashRomImage() (in OvmfPkg/PlatformCI/PlatformBuildLib.py) is not flexible enough for that. Fixing that and adding a boot test (in non-sev mode) shouldn't be that difficult though. Same for IntelTdx.dsc: adding a CI boot test (in non-tdx mode) should be easy, and it should help preventing regressions in PEI-less boot flow. take care, Gerd