From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by mx.groups.io with SMTP id smtpd.web12.12139.1631293446015441730 for ; Fri, 10 Sep 2021 10:04:06 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@google.com header.s=20210112 header.b=Jm2Y19Nc; spf=pass (domain: google.com, ip: 209.85.214.182, mailfrom: erdemaktas@google.com) Received: by mail-pl1-f182.google.com with SMTP id n4so1536981plh.9 for ; Fri, 10 Sep 2021 10:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=u3SD222f6URPxnz5V9EssY7wqrJB99irC/gFanfgr2A=; b=Jm2Y19NcKOSMtsqr6RdeZTU+zUEeV2eqrUvxP61mzEZryYXYnzb/eVjPZoBdDLq1xc FK0vQl7wa2FumBNGfflxWuIYGc5PUXMMQsJ9VSpmMUkotUC+cmFZ4zaOivy2F6weI3tw 3Ap/rOo5hD0eYClQxtyGEzFxYtJV6A5aPBMyEP8udS2KlBlgYNDJ1JppkzzBBqvsetpE pdprDfDBdhwJ4QIg5wC9EdpWy1F9E1ZQc9hyPiuLRv8LDuvMCF2J2mDqav16kXkxn1z/ JTuMC88l3empL2exR/Puu/EQFTYvZr+aqdC87G0KodnXHy7yrkHlBZFArggj8GyrTgbF lFFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=u3SD222f6URPxnz5V9EssY7wqrJB99irC/gFanfgr2A=; b=03G8ymvhTaJfJi2i+lB4ak/CqXi1I5nqjTR4HAkRAv+6zwvp/C+1HIWYny5zDTLx92 hIPMuzIEQri0xR+DdW8BAz+LS227KfD0JsB1QjkNxmzBzH1m4qdrKNdv6an2O3gWHIe6 6rfZRF4+YlEYk2Jhsi5yRKxmc9lWCMremg5eD6IjjXZsb5+j+C0h4b7D47P1y/UK+U2V LeETqWBuh1FpL5okk39t3yfped64hOVqizKAVxqDpmzRJ5V1XPcwzxWz14i3QIOMR563 nlpItPcdCy23okiCi4XTA7W99fdSvf6zr1mtz9Zc9yVc8RQM6ov9GRQoqa9CMNIXwCys LwiQ== X-Gm-Message-State: AOAM533YvR3YgiaY0gWkldMfAUmZ3xu3Km+zQZDpLqDOvyr8gjm4sFE6 Lzv9nJ2ziju3Vsj4LIa2F+lg12ZBHV5Hv5Weje3aqg== X-Google-Smtp-Source: ABdhPJyyIjcFrdsvYLQqCOndrifSDwFWXokdxbjjWIS99bB7hv9VYQJlRnlqf+wZlbA+pSjwTY6p/Z6BFskphjNMn3s= X-Received: by 2002:a17:90a:1b2a:: with SMTP id q39mr10660507pjq.219.1631293444381; Fri, 10 Sep 2021 10:04:04 -0700 (PDT) MIME-Version: 1.0 References: <77440edd1e175207dffcaaa052ce26ae71e6c66c.1630289827.git.min.m.xu@intel.com> <20210830070339.u47qq3g7hb4rq3xc@sirius.home.kraxel.org> <20210831051305.dhqvsh4jzqekmjly@sirius.home.kraxel.org> <20210831102120.kh2b6boorxets75j@sirius.home.kraxel.org> <20210901061033.auj6v3nnofmcawxc@sirius.home.kraxel.org> <08185e00b379d70f3420e8c099c26ae5d62c18bc.camel@linux.ibm.com> <269131DD-C918-40F0-81D2-2151C177F407@apple.com> In-Reply-To: <269131DD-C918-40F0-81D2-2151C177F407@apple.com> From: "Erdem Aktas" Date: Fri, 10 Sep 2021 20:03:53 +0300 Message-ID: Subject: Re: [edk2-devel] [PATCH V5 1/2] OvmfPkg: Introduce Tdx BFV/CFV PCDs and PcdOvmfImageSizeInKb To: Andrew Fish Cc: edk2-devel-groups-io , James Bottomley , "Yao, Jiewen" , "Xu, Min M" , Ard Biesheuvel , "kraxel@redhat.com" , Ard Biesheuvel , Jordan Justen , Brijesh Singh , Tom Lendacky Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have few naive questions. Sorry if the answers were obvious. >>TDVF also include a configuration firmware volume (CFV) that is separated >>from the BFV. The reason is because the CFV is measured in RTMR, while >>the BFV is measured in MRTD. If I understand correctly, this means that the BFV is encrypted and measured during TD build time. Since CFV is not included in the MRTD, CFV region is not encrypted with the guest key, is it? >> The measurement value of the CFV (provisioned configuration data) is ext= ended to >> RTMR registers (similar to TPM PCRs). At the same time it is recorded in= the TD Event >> log. Even if it is measured at runtime, the content needs to be copied to somewhere else, otherwise what stops VMM to change the content after it is being measured (assuming that it is not encrypted). >> As to the spare part in varstore, it is not external input, is it? It's = produced and consumed >> by code itself. From this perspective it should not be measured. If the = spare part >> is included in the measurement, then the *good* measurement is not known= anymore. >> Because no one knows about the content of spare part in advance. I am confused about how this memory is initialized. If it is encrypted, then no need to measure it but also it becomes useless as the key will change in the next boot. If it is not encrypted, VMM can always modify the content and might cause unexpected behavior at runtime, right? I might be missing something here but if this region is not encrypted: - CFV content needs to be copied into an encrypted buffer after being measured and should never be used again. - Allowing variables to be stored in SPARE part seems like opening an attack surface as no one knows what will be stored in that region. Is this correct understanding? -Erdem On Wed, Sep 1, 2021 at 10:20 PM Andrew Fish wrote: > > > > On Sep 1, 2021, at 9:53 AM, James Bottomley wrote: > > > > On Wed, 2021-09-01 at 08:59 +0000, Yao, Jiewen wrote: > >> Hi Min > >> I agree with Gerd and Ard in this case. > >> > >> It is NOT so obvious that the FTW is produced then consumed in the > >> code. What if the attacker prepares some special configuration to > >> trigger the FTW process at the first boot, the code will do *read* > >> before *write*? That is a potential attack surface. > > > > It's not just that: even if you can ensure nothing in the host changed > > the variables, how do you know *your* code inside the guest is updating > > them? In ordinary OVMF we try to ensure that by having the variables > > SMM protected so the only update path available to the kernel is via > > the setVariable interface, but we can't do that in the confidential > > computing case because SMM isn't supported. That means a random kernel > > attacker in the guest can potentially write to the var store too. > > > > At least for the first SEV prototype I had to make the var store part > > of the first firmware volume firstly so it got measured but secondly so > > it couldn't be used as a source of configuration attacks. > > > > I have a nasty feeling that configuration attacks are going to be the > > bane of all confidential computing solutions because they give the > > untrusted VMM a wide attack surface. > > > > James, > > If we take a big step back the requirement for an EFI Runtime Service, li= ke the variable API, is just exclusive access to hardware at OS runtime. Th= e variable store needs to be on a hardware device that has a persistent rel= iable store. The FTW is really about maintaining the consistency of the sto= re if the power gets yanked at the wrong moment. So the fact that the UEFI = Variable Store is in NOR FLASH is a historical artifact more than architect= ure. Also on physical devices hardware cost money, and you need the NOR FLA= SH for the firmware so why change it. Thus conceptually the variable store = could be backed by a virtual hardware device that was designed with securit= y in mind. Maybe more of message passing interface and the reliability of u= pdates is maintained by the hardware device not the UEFI code. It would als= o be possible for the hardware device to enforce security policy. You could= even have EFI send a one shot message per 1st boot to the hardware to defi= ne a security policy. If you wanted the hardware device could even implemen= t the UEFI Secure Boot infrastructure so the UEFI Variable Driver could be = untrusted. I guess this hypothetical variable store virtual hardware device= could also have hardware access to other security hardware resources (like= a TPM) and implement security policies based on that. > > FYI on Macs with a T2 (security chip) the UEFI variable store lives on th= e T2. > > Thanks, > > Andrew Fish > > > > James > > > > > > > > > >=20 > > > > >