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.4845.1641892995398800335 for ; Tue, 11 Jan 2022 01:23:15 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=F4So9ePs; 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=1641892994; 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=gQoVwsvbkN24m/TtBORuVUKlrELq5rbYB8nb8f+RIcQ=; b=F4So9ePstwcOSxCxMeTj/J3oyLvqbkjJLhj0fWg27W+m29+TUDJDijwlmGASKYfC5Qs284 OlnRrXeZldFw23mwKtCpnSzFlvOG5ohBRC6rd6Wyev+QHGjfJxnbF2KNg08Td9W7Hrvlew PsKHzaup90FCGGBylT5m6Q7JDQ22LFY= 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-75-PUAlJdPmP7uZdnQ0pkjv0Q-1; Tue, 11 Jan 2022 04:23:07 -0500 X-MC-Unique: PUAlJdPmP7uZdnQ0pkjv0Q-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4C5D61937FC0; Tue, 11 Jan 2022 09:23:06 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.193.24]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 05B3F1057FDE; Tue, 11 Jan 2022 09:23:06 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 21DCA180009C; Tue, 11 Jan 2022 10:23:04 +0100 (CET) Date: Tue, 11 Jan 2022 10:23:04 +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: <20220111092304.2n72req6ocdkqfub@sirius.home.kraxel.org> References: <20211215102753.m4bp56bdxzgmdzkr@sirius.home.kraxel.org> <20211216142525.pkaxszwaevlpg4ap@sirius.home.kraxel.org> <20211220121145.aiqcqs6vd2hb2sb4@sirius.home.kraxel.org> <20220103080218.ap7tktgh4fuvw6sf@sirius.home.kraxel.org> <20220110075537.2dxghysjlz5rmwhm@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 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, > > Well, if you want avoid the refactoring because of the risk there is still the > > option to have tdx config-b use the normal PEI boot flow. > > Then revisit refactoring and adding support for PEI-less boot later. > > > I think it still makes sense (Adding a basic PlatformInitLib which > brings up tdx guest and legacy guest in Pei-less boot, but not touch > PlatformPei). > 1. The goal of TDVF-Config-B is to bring up tdx guest and legacy guest > without PEI. So that attack surface can be reduced. Hmm? Isn't the main goal of config-b to support the advanced tdx features (attestation etc)? I don't see that PEI-less boot is required for that. Sure, when stripping down the build and removing all the features which require PEIMs there isn't much left to do for the PEI phase. So it makes sense to look into dropping PEI altogether. But it's more a "nice to have" than a hard requirement, no? > 2. There are common functions when bring up tdx guest and legacy guest > in Config-B. So PlatformInitLib is necessary. Sure. > 3. As I explained there are many if-else checks in PlatformPei and the > logics are rather complicated (because PlatformPei serves > S3/SMM/SEV/TDX/Legacy/Microvm/CloudHypervisor, etc). To be honest I > have not so much confidence to abstract PlatformPei's common function > to PlatformInitLib. What is the problem with moving code? After some preparing steps (add platform info hob, move global variables to the hob) it should be possible to move the code needed by config-b (memory detection via fw_cfg or tdx hob, pci init, ...) from PlatformPei to PlatformInitLib and (also) use it in the SEC phase. Likewise for code which runs in DXE in PEI-less mode (setting PCDs). The code not needed by config-b (smm, s3, ...) can stay in PlatformPei. > 4. But a basic version of PlatformInitLib is a good start. Yes. Having initially only the functions needed by config-b in PlatformInitLib is perfectly fine, but this should be a code *move* not a copy. > During the development and community review, we can understand better > what functions should be wrapped into PlatformInitLib. After that > PlatformInitLib can be evolved for OvmfPkg/PlatformPei, > Bhyve/PlatformPei, XenPlatformPei. Yes, most likely there are a number of opportunities to reduce code duplication in the three PlatformPei variants we have by moving code to the (shared) PlatformInitLib. That can be looked at later. take care, Gerd