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.6135.1623235865078633575 for ; Wed, 09 Jun 2021 03:51:05 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=RnHqdPox; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1623235864; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rd1LRWEQyV7BnvJY28wkMeIY9ggMHT+PcN4IjUCCJ1c=; b=RnHqdPoxiLthw19lznVB3+nU61qSPXVROShTf5nnM+p6429Va8kBI08OKTspKiCVmHLqii WKxcOW8ZE6Wna/x6/D63gJF0dvrceIumOJ3qJzbNInD0n5JnDh970jGm3pBCYNM5mrSHbR LaXN+nY4BN9JKN/c365+Lo8vJReS9bw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-108-US_P7r1lNCasTLPa6oVkSg-1; Wed, 09 Jun 2021 06:51:01 -0400 X-MC-Unique: US_P7r1lNCasTLPa6oVkSg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 73E2A8015A4; Wed, 9 Jun 2021 10:50:59 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-249.ams2.redhat.com [10.36.113.249]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B51235D719; Wed, 9 Jun 2021 10:50:56 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH RFC v3 04/22] OvmfPkg/MemEncryptSevLib: extend Es Workarea to include hv features To: Tom Lendacky , Brijesh Singh Cc: devel@edk2.groups.io, James Bottomley , Min Xu , Jiewen Yao , Jordan Justen , Erdem Aktas , Eric Dong , Ray Ni , Rahul Kumar , Ard Biesheuvel References: <20210526231118.12946-1-brijesh.singh@amd.com> <20210526231118.12946-5-brijesh.singh@amd.com> <0744c84d-ca70-1fe6-a1c0-b97bb87affc5@redhat.com> <504f5362-c849-d6e7-5980-4410b84155d9@amd.com> From: "Laszlo Ersek" Message-ID: <29640fb8-4ac6-89f1-0f14-f943f52b7095@redhat.com> Date: Wed, 9 Jun 2021 12:50:55 +0200 MIME-Version: 1.0 In-Reply-To: <504f5362-c849-d6e7-5980-4410b84155d9@amd.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 06/08/21 23:36, Tom Lendacky wrote: > On 6/8/21 3:49 AM, Laszlo Ersek wrote: >> On 06/07/21 15:37, Brijesh Singh wrote: >> >> > ... > >> ... But maybe I just need to accept that we have to repurpose >> SEC_SEV_ES_WORK_AREA, considering it a super-early "HOB list" of sorts. >> Same as the PEI phase is considered the "HOB producer phase", outputting >> a bunch of disparate bits of info, we could consider the SEV-ES parts of >> the Reset Vector such an "early info bits" producer phase. I think this >> is a very big conceptual step away from the original purpose of >> SEC_SEV_ES_WORK_AREA (note the *name* of the structure: "work area"! >> HOBs are not "work areas", they are effectively read-only, once >> produced). But perhaps this is what we need (and then with proper >> documentation). >> >> NB however that HOBs have types, GUIDed HOBs have GUIDs, the HOB types >> are specified in PI, and GUIDs are expressly declared to stand for >> various purposes at least in edk2 DEC files. All that helps with >> discerning the information flow. So... I'd still prefer keeping >> SEC_SEV_ES_WORK_AREA as minimal as possible. >> >> Tom, any comments? > > The purpose of the work area was originally two-fold. It is used in the > reset vector code to set the SevEsEnabled bit so that we could keep the > original behavior in SecCoreStartupWithStack() - no initialization of the > exception handlers or early enabling of processor cache. The second use is > for initial AP startup, where we had a known memory address at build time > that could be used to set the initial CS:IP of APs for the first boot. > > We expanded the use for the security mitigations, used by the reset vector > code and again in SEC. At the start of PEI, PCDs are then set. > > So, yes, if the information can be obtained later, and in this case we're > not talking about CPUID information which would need re-validation, then > there's no need to keep it in the work area and we can keep the size and > information stored in the work area to a minimum. Thank you very much! Laszlo