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.web12.9636.1637829148325619704 for ; Thu, 25 Nov 2021 00:32:28 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=eL6w0Q8+; 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=1637829147; 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=lVrrScuWx94UWOrNzhSpuzfBohsAxUzg3oim68V12+k=; b=eL6w0Q8+lcrtPYdcXKFSv/SK66btri01qdPJGOy0FjyspsCmb5e9sXNEn4Fg6xTf4xmNqh aDbCAhRSP2j6Rnp9GXGoiWRMej2gb5Az8mStP/9RpB2f3O9rTJaPlRYpizNx7fvWQRFgS8 QjpOr+P9ONPXpYdf9ewdQxh3SS1utfw= 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-496-0qTOqtZfOVCEWaMwZhz7UA-1; Thu, 25 Nov 2021 03:32:24 -0500 X-MC-Unique: 0qTOqtZfOVCEWaMwZhz7UA-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 807BB1800D41; Thu, 25 Nov 2021 08:32:22 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.79]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BBD8660C05; Thu, 25 Nov 2021 08:32:21 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id F178F18003BF; Thu, 25 Nov 2021 09:32:19 +0100 (CET) Date: Thu, 25 Nov 2021 09:32:19 +0100 From: "Gerd Hoffmann" To: "Yao, Jiewen" Cc: "devel@edk2.groups.io" , "jejb@linux.ibm.com" , "Xu, Min M" , Ard Biesheuvel , "Justen, Jordan L" , Brijesh Singh , Erdem Aktas , Tom Lendacky Subject: Re: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to support Tdx Message-ID: <20211125083219.uiqbg7fsoervmdkq@sirius.home.kraxel.org> References: <1DF0C062-BF78-44E2-BE96-2C8727C36845@intel.com> <5ec6897681e46fe181193651164f0f17d5d1205d.camel@linux.ibm.com> <20211124081204.ortxlgwgp2c5dlhw@sirius.home.kraxel.org> <5d39c546fe66fc945e9687f187ed9892b6a6a00c.camel@linux.ibm.com> MIME-Version: 1.0 In-Reply-To: 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, > So, my judgement is by removing PEI, we can reduce the risk introduce > by PEI Core + PEI Arch PEIM*. Reducing code == Reducing Security Risk. Yes, PEI Core goes away. No, PEI Arch PEIM (aka OvmfPkg/PlatformPei) wouldn't go away, you would only move the code to SEC or DXE phase, the platform initialization has to happen somewhere. Moving code to DXE has its problems as outlines by James at length. Moving code to SEC has its problems too. SEC is a much more restricted environment. A direct consequence is that you have re-invented multiprocessor job scheduling (using tdx mailbox) instead of using standard mp service for parallel accept. I do not account that as "reducing complexity". And I've not yet seen the other changes you have done for pei-less tdvf ... take care, Gerd