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.5214.1650442623306925543 for ; Wed, 20 Apr 2022 01:17:03 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=AMN8MxqA; 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=1650442622; 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=SB6QzJHp3/UU5ttCVCilOOATg1ZnJCTT1ZqDbkITlCs=; b=AMN8MxqAUW89yY0Q1W6LgTvjP13hNUv2RREtrTSA1afoY/AUblmLuNc08KWS7VD+CEfxzr phLCrg1GDoKhkmx3/Ts0ikc86xzJXF6UwTIz7xWeWA5CS8G8ts/+G3v4uImMpG+4lGoxKP Y239z/LejR77Vxnx8RcmvgQsJ3Gy6v8= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-658-gvzB4PJsM521IlMmLV0_Zw-1; Wed, 20 Apr 2022 04:16:59 -0400 X-MC-Unique: gvzB4PJsM521IlMmLV0_Zw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 73F958047D6; Wed, 20 Apr 2022 08:16:58 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.9]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 38D8F40CFD08; Wed, 20 Apr 2022 08:16:58 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 828F6180009C; Wed, 20 Apr 2022 10:16:56 +0200 (CEST) Date: Wed, 20 Apr 2022 10:16:56 +0200 From: "Gerd Hoffmann" To: "Yao, Jiewen" Cc: "devel@edk2.groups.io" , "Xu, Min M" , Ard Biesheuvel , "Justen, Jordan L" , Brijesh Singh , "Aktas, Erdem" , James Bottomley , Tom Lendacky Subject: Re: [edk2-devel] [PATCH V3 5/9] OvmfPkg/IntelTdx: Measure Td HobList and Configuration FV Message-ID: <20220420081656.nl4sykhnwzugynm5@sirius.home.kraxel.org> References: <1992c4538efeb3cd3d2e53bd02f2dd24663e9825.1650239544.git.min.m.xu@intel.com> <20220419065851.mwjpm6jaeu3zudjk@sirius.home.kraxel.org> <20220419124901.idh7zaff3os6532f@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.11.54.1 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, > > Yes for validation (aka sanity-checking the fields, etc). > > But for measurement I don't see why the ordering matters. > > Whenever you do that before or after consuming the TdHob > > should not make a difference. > > [Jiewen] I disagree. The order matters from security perspective. > If you use it, there is risk that the buggy code will compromise the system before you have chance to measure it. Measurement will only record hashes for verification later on. It will not prevent running possibly buggy/compromised code. So, no matter what the order is, you'll figure the system got compromised after the fact, when checking the hashes later, and in turn take actions like refusing to hand out secrets to the compromised system. > There was already known attacks: The measurement was in wrong place, > which caused the attack can forge the measurement. Do you have a link or CVE number for me? thanks, Gerd