From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web12.4223.1630476639768539855 for ; Tue, 31 Aug 2021 23:10:40 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=KaFf6/25; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1630476638; 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=b7do6BIunDEMaOUeg05pg0PTSz5HGSZEDqY7ubZf4bk=; b=KaFf6/25l/jyM0onZWS2OuGuXuE/KJSbrG1V0XGLJM6Y7XvEdgLqPs/gbjaZ+k2wrjiLrT YC2se3v7OlvxfJ04j626Ir2Gy7YNaKEhnKKfR+pDOOBc4B/w16vpMUAQ6XAhS8BzBRneon /s+FHCtxGqc1Ysn4V98YKWFBFako8Gg= 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-295-rZbu-9DPOzqpxKn7U7Xnyw-1; Wed, 01 Sep 2021 02:10:36 -0400 X-MC-Unique: rZbu-9DPOzqpxKn7U7Xnyw-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 4F49E107ACCA; Wed, 1 Sep 2021 06:10:35 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.91]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A69176A8F6; Wed, 1 Sep 2021 06:10:34 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 0B3A4180038E; Wed, 1 Sep 2021 08:10:33 +0200 (CEST) Date: Wed, 1 Sep 2021 08:10:33 +0200 From: "Gerd Hoffmann" To: "Xu, Min M" Cc: "devel@edk2.groups.io" , Ard Biesheuvel , "Justen, Jordan L" , Brijesh Singh , Erdem Aktas , James Bottomley , "Yao, Jiewen" , Tom Lendacky Subject: Re: [edk2-devel] [PATCH V5 1/2] OvmfPkg: Introduce Tdx BFV/CFV PCDs and PcdOvmfImageSizeInKb Message-ID: <20210901061033.auj6v3nnofmcawxc@sirius.home.kraxel.org> 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> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 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, > > I didn't fully investigate what kind of attacks one can do. I'm pretty sure simply > > making the variable store larger and the spare smaller works, so parts of the > > variable store are outside the area you are measuring. Not fully sure whenever > > one can actually reorder the sections to move the varstore completely into the > > unmeasured area. Or play out other attacks with the same effect, like bloating > > some header struct. > > > > Simply measuring everything (including the spare) will stop all that. > > Changes wouldn't go unnoticed, period. No ifs and buts. So I'm wondering why > > you not doing that? Performance? Wouldn't be the first time a performance > > optimization pokes a hole into a security concept ... > > > The measurement value of the CFV (provisioned configuration data) is extended to > RTMR registers (similar to TPM PCRs). At the same time it is recorded in the TD Event > log. > These information will be used by the Attestation server (This is the so-called Attestation). > In other words there is a known *good* CFV measurement value. Any changes to > the CFV, for example the layout, the order of the variables, the content of the variables > will produce a *bad* CFV measurement. Yes. The attacker would need a varstore with a modified layout being approved by the attestation server as first step, then he would be able to modify variables unnoticed in a second step. So, assuming an attacker isn't able to carry out the first step it should be all fine in theory. When it comes to security it never hurts to have another line of defense though, so I would still strongly recommend to measure the complete varstore (including spare). At the end of the day it is your call, I'm not going to veto the patch. But I'll reserve the right to pull a "told you so" in case someone manages to exploit that some day. take care, Gerd