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.10307.1637334701792545449 for ; Fri, 19 Nov 2021 07:11:42 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=PhDblgPF; 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=1637334700; 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=q5pDhfMvqTBMtU32y7uF1fGeQd1Wi93EjYaBsJKVov8=; b=PhDblgPFIu2epzYvAKnXHSHw7Rer2iCAU11H4NEP354mfeffk4rcDj8nYZhKZzg0WICmLr ovxy0t14ph3cUBE52SeadSDunqkDP9lDJaTleJijS3MJRgrTeDTUNXGyIMG2eeVXAYQto+ F2pNo+LOT119gRKPfs7dzguApIfcOOI= 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-181-cT5zjoXAN0ClhV0duL865g-1; Fri, 19 Nov 2021 10:11:35 -0500 X-MC-Unique: cT5zjoXAN0ClhV0duL865g-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 868AA100E325; Fri, 19 Nov 2021 15:11:33 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.193.245]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D1E2360622; Fri, 19 Nov 2021 15:11:32 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id C691C18009DA; Fri, 19 Nov 2021 16:11:30 +0100 (CET) Date: Fri, 19 Nov 2021 16:11:30 +0100 From: "Gerd Hoffmann" To: "Yao, Jiewen" Cc: "Xu, Min M" , "devel@edk2.groups.io" , Ard Biesheuvel , "Justen, Jordan L" , Brijesh Singh , Erdem Aktas , James Bottomley , Tom Lendacky Subject: Re: [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to support Tdx Message-ID: <20211119151130.g2wcnuhivt3lxvzi@sirius.home.kraxel.org> References: <867e8a2aaf28c308b20a659057217453c6e38e00.1635769996.git.min.m.xu@intel.com> <20211103063045.kmttoxyluifwo2bq@sirius.home.kraxel.org> <20211117151942.iqow75zq2lrn5xlc@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, > Comment on config-B. > > I'm sure I've asked this before: Why skip the PEI phase? So far > > I have not seen any convincing argument for it. > > Skipping PEI phase is valid architecture design. Sure. > Second, the confidential computing changes the threat model > completely. One of our goal is to simplify the design for CC-firmware > (TDVF) - remove unnecessary modules, remove unnecessary interface, > make the image smaller and faster. That will reduce the validation > effort, too. > > That is the main motivation. That totally makes sense. I expect TDVF Config-B will look alot like the existing AmdSev configuration variant which is stripped down too. No SMM support, no network stack, ... There wouldn't be left much in PEI beside PeiCore and OvmfPkg/PlatformPei. But I don't see how dropping the PEI phase altogether helps much in stripping down the firmware image. The initialization currently handled by OvmfPkg/PlatformPei must happen somewhere else instead. Given SEC is a very restricted environment I don't expect the code can be shared easily, so we will probably end up with code duplication. Also two different boot workflows which I fear can easily introduce subtle bugs due to differences like a initialization order changes. This is what I see as maintenance problem. > Config-A is to keep current architecture, to maximum compatible with > OVMF. And we don't remove VMM out of TCB. > Config-B is to have a new TDVF design, to maximum satisfy the security > requirement. And we remove VMM out of TCB. Sure. config-a is ovmf with tdx support added, all uefi features present, only basic tdx/sev support (basically support memory encryption). config-b is simliar to AmdSev (maybe we'll merge them some day), stripped down uefi feature set (no network etc), full tdx support including attestation etc. I don't want question all that. I still don't see the point in dropping the PEI phase and make config-b work different that all other ovmf variants though. > > Jiewen argued this is a simplification. Which is not completely wrong, > > but it's also only half the truth. Switching all OVMF builds over to > > PEI-less boot doesn't work because some features supported by OVMF > > depend on PEI Modules. Therefore TDX Config-B skipping the PEI phase > > means we would have to maintain two boot work flows (with and without > > PEI phase) for OVMF. Which in turn would imply more work for > > maintenance, testing and so on. > > [Jiewen] I am not asking your to OVMF build to PEI-less. > But if you want to do, I will not object. s3, smm, tpm and maybe more depends on pei modules, so dropping the PEi phase is not an option for a full-featured OVMF build. So I'd very much prefer all ovmf variants (including tdvf) use the PEI phase. > On contrast, if we keep PEI for config B, it adds extra burden from > security assurance perspective. That means, every issue in PEI may be > exposed to TDVF. Same for all other modules used by tdvf. The list of affected PEI modules is rather short though. I think it's only PeiCore and DxeIpl. PlatformPei doesn't count as the code wouldn't go away but would be moved to SEC (and maybe parts of it to DXE). > Comparing the effort to maintain the work flow and the effort to > handle potential security issue, I would choose to maintain the work > flow. I have experience to wait for 1 year embargo to fix EDKII > security issue, it is very painful and brings huge burden. The security workflow is a serious problem indeed. Not only for TDVF, also for OVMF in general, and other platforms too. We should certainly try to improve it. I'm not going to open that discussion in this thread. But let me drop two links two links to osfc talk and workshop (Not 30th + Dec 1st), titled "The firmware supply-chain security is broken: can we fix it?" https://talks.osfc.io/osfc2021/talk/D9X39Z/ https://talks.osfc.io/osfc2021/talk/E9YYJF/ > > I want TDVF be consistent with the rest of OVMF. Makes long-term > > maintenance easier. Building a single binary for both SEV and TDX with > > full confidential computing support (including config-b features) will > > be easier too. > > [Jiewen] I am not convinced that TDVF be consist with rest of OVMF. > The goal of project is different. The choice can be different. > I don't see a reason that one platform must be in this way, just because other platform does in this way. Hmm? Seeing TDVF as "other platform" is a rather strange view given that we are integrating tdx support into OVMF right now ... > I think a PEI-less TDVF is much easier to maintain, comparing with > complicated OVMF flow, at least from security perspective. The less > code we have, the less issue we have. Well, we will have TDX support in the normal OVMF workflow anyway, because we need that for config-a. Why use and maintain something different for config-b? That looks rather pointless to me ... take care, Gerd