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.web12.91864.1638366918865878612 for ; Wed, 01 Dec 2021 05:55:19 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=FcnAf31j; 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=1638366916; 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=Y4FFcdJld0RbaoNo6wBYZOy+iaTHuWYCfCQtfvRcS6U=; b=FcnAf31j6iaXDJhd+yVMQ6BAHyTSfHutxiwsGLDOSbcmnyau+HdvfDCk3vg8sSmqmpsZD1 ZHKdaIloyzI0Ftv3jlcuhM13705m1mo9dSF2ZdP2uVb3eM2kk1bO5tadQpgkRI4Rgd3X1I nNzgeRI3x5xzKjpGrLarVN2AqjWLr8w= 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-559-m948ljDlPoqsqeHHg-Gh2Q-1; Wed, 01 Dec 2021 08:55:11 -0500 X-MC-Unique: m948ljDlPoqsqeHHg-Gh2Q-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 793488010C7; Wed, 1 Dec 2021 13:55:08 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.79]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CE3FE60843; Wed, 1 Dec 2021 13:55:07 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 547631800922; Wed, 1 Dec 2021 14:55:06 +0100 (CET) Date: Wed, 1 Dec 2021 14:55:06 +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: <20211201135506.bwxpo5h4fr5lcbni@sirius.home.kraxel.org> References: <5ec6897681e46fe181193651164f0f17d5d1205d.camel@linux.ibm.com> <20211124081204.ortxlgwgp2c5dlhw@sirius.home.kraxel.org> <5d39c546fe66fc945e9687f187ed9892b6a6a00c.camel@linux.ibm.com> <20211125083219.uiqbg7fsoervmdkq@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 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, > Please refer to PI specification 1.7A (https://uefi.org/sites/default/files/resources/PI_Spec_1_7_A_final_May1.pdf) > Section 2.1 - Introduction. > "Philosophically, the PEI phase is intended to be the thinnest amount > of code to achieve the ends listed above. As such, any more > sophisticated algorithms or processing should be deferred to the DXE > phase of execution." Well, that might have been the original intention. Reality is that a bunch of security-related stuff ended up in PEI too. Support for TPM, SMM, suspend. And I think the motivation for that is exactly what James described: Given that most communication with external entities happens in the DXE phase it is much harder to trick PEI code because there are simply less attack vectors available. > I am not convinced that "exposure (external interface)" is a good > reason to decide where the module should be. Thinking of this, if you > prefer to put a module to the PEI because PEI has *less* exposure, > then PEI will have *more* exposure after that. If you move half of > DXE features to PEI, then PEI has same exposure as DXE. What benefit > we can get? Why is TPM and SMM and suspend support in PEI not DXE today? > > 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". > > [Jiewen] OK. Let me explain multiprocessor related topic. > > I don't think we intent to "reduce" complexity in this area. I would > say, it is same with or without PEI. > > TDX (also SEV) has special requirement to *accept* memory, before use > it. The accepting is time consuming process. So the motivation is to > use multiprocessor to accelerate the process. > > We have at least three architecture places to accept the memory - SEC, > PEI and DXE. Well, I want focus on how all this will look like long-term, i.e. once we have lazy accept implemented. I don't think it makes sense to put much effort into optimizing a workflow which will only be temporary anyway. The lazy accept concept pretty much implies that the vast majority of memory will either be accepted in the DXE phase, or will not be accepted by the firmware at all and the linux kernel will handle that instead. I expect in the future SEC and/or PEI will accept barely enough memory that the firmware is able to enter the DXE phase and initialize core memory management. Then lazy accept takes over. > A) Accept in SEC > We need write multiprocessor code in SEC. This is already mandatory, > even without accepting memory. The TDX architecture already changes > the reset vector flow - ALL processors jumps to the reset vector at > same time. Having multiprocessor code in SEC is unavoidable. We have > to do it, to rendez-vous APs and initialize mailbox. Sure. > The code is written because of TDX architecture change, not because > memory accepting. So I won't treat it as a burden to add additional > feature to memory accept in SEC. That is the point where you start re-inventing the wheel though. You add logic to distribute memory acceptance jobs to the APs. I'd suggest to add full MP service support to TDX (probably also using the mailbox), then use MP service to distribute memory acceptance jobs to the APs. I think you will need that anyway for lazy accept, to do parallel accept in DXE phase. > B) Accept in PEI > PEI has MP_PPI, that is TRUE. But the problem is: MP_PPI starts *later*. > MP_PPI starts *after* the memory discovery (https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/CpuMpPei/CpuMpPei.c#L706), which mean the process will be: > Step 1: TdxPeim accepts PEI required memory without MP_PPI > Step 2: PlatformPei installs PEI required memory. > Step 3: MP_PPI starts. > Step 4: TdxPeim accepts additional memory with MP_PPI Yes. Or just don't initialize MP in PEI and do that in DXE only. Lazy accept will need that anyway. > Now, you can see the benefit to accept PEI memory is not there. > NOTE: PEI memory is ~64M if GPAW is 48, it is ~98M if GPAW is 52, which is a big number. What is all this memory needed for? Why do you need 32M additional memory for 5-level paging? Is that page table memory? If so, how does lazy accept change the picture? > As such, we conclude that doing memory accept in SEC is the best > choice for TDX architecture. Not convinced this is still the case with lazy accept on the horizon. > For config-B, Min is working on it and doing clean up. > You are welcome to provide feedback after we send out patch for config-B. Will do for sure. take care, Gerd