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.52605.1638802667457660743 for ; Mon, 06 Dec 2021 06:57:47 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Wv64Roxc; 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=1638802666; 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=W1U3Vn5FIQpOoNDyRfNd27CGmOAHRbosj98/y3GsTnQ=; b=Wv64RoxcUgz/cW4HtiDolRR7GH45JNQn643Ylm9CMRmCCU7RnTE2v5RsUOTqjYiJj6RzUN tzS1114lYWIYmzCQGrM+o8Hp/qkS3Xqf5ySgeUDgHf+kgd0ESXWBr6ke940wWlQUjNAe/2 0bWF42ne8/AcbVh6ezIq6bHTVCgc+ig= 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-384-aiw6cVk9MyOuI5yHbQt0cg-1; Mon, 06 Dec 2021 09:57:41 -0500 X-MC-Unique: aiw6cVk9MyOuI5yHbQt0cg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 09A0964145; Mon, 6 Dec 2021 14:57:40 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.5]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7281345D75; Mon, 6 Dec 2021 14:57:39 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 9A06F18003B3; Mon, 6 Dec 2021 15:57:37 +0100 (CET) Date: Mon, 6 Dec 2021 15:57:37 +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: <20211206145737.e3bh6fl65j6qw62f@sirius.home.kraxel.org> References: <20211124081204.ortxlgwgp2c5dlhw@sirius.home.kraxel.org> <5d39c546fe66fc945e9687f187ed9892b6a6a00c.camel@linux.ibm.com> <20211125083219.uiqbg7fsoervmdkq@sirius.home.kraxel.org> <20211201135506.bwxpo5h4fr5lcbni@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 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, > [Jiewen] Again, I feel lost. > > Would you please clarify what is your purpose for this discussion? > > Yes, Security related stuff in PEI, that is not a problem. For > example, we moved flash lock from DXE to PEI. (I already describe that > in my previous email.) Well, you tried to make the point that PEI shouldn't do anything beyond memory initialization. Which might have been correct for the initial design, but meanwhile it is not true any more. > The key is *privilege*. If you don't need PEI privilege, you don't need move to PEI. > 2) "SMM" support is in DXE today. What do you mean SMM support in PEI ? ovmf has a pei module for smm support (see OvmfPkg/SmmAccess/SmmAccessPei.inf). > But I don't see how the examples support your statement on "exposure". Well, lets stick to the flash lock example. Moving it from DXE to PEI makes it less exposed. It'll run before DXE starts processing externally controlled input (efi vars, kbd input, disk reads, option roms, ...). So trying trick it into not actually locking the flash is much harder. Or, to put it into another way, it reduces the attack surface for the code with higher privilege. (it's of course also need to make sure you can't unlock flash with a suspend-resume cycle). > > 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. > > [Jiewen] This is the long-term solution. > Lazy accept and MP accept are two required feature. > > "Lazy accept" just mean you can do things later, but you still need do it. > "MP accept" means you can do things much quicker. > > I don't think we can remove MP accept just because we have lazy accept. I don't want remove it. But with lazy accept you have more options to implement it. No need to go for assembler code in SEC, you can use MP service with standard C code in PEI or DXE. > [Jiewen] the "barely enough memory" is 64M and it takes long time to > accept if you don't use MP. If I remember the numbers correctly (roughly 4 seconds for 2G on a single processor) that "long time" would be roughly 12 ms for 64M. > > 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. > > [Jiewen] I think I have stated it clearly that this is due to TDX > architecture, we have to rendezvous all APs in SEC. So the MP code > SEC is unavoidable. We have to reinvent the wheel in some way. Well, adding TDX rendezvous support isn't re-inventing the wheel, you surely need that, no question. But then you go create your own job scheduler (also accept job implementation), all in assembler, instead of using standard edk2 MP services with more readable C code. *That* is where you re-invent the wheel. > > > 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? > > [Jiewen] These are initial memory for PEI Core and DXE Core to initialize the content. > If you don't have initial memory, the core will fail. Where does the 50% increase for GPAW=52 comes from? take care, Gerd