From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.158.5]) by mx.groups.io with SMTP id smtpd.web12.9625.1634914909380591031 for ; Fri, 22 Oct 2021 08:01:49 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@ibm.com header.s=pp1 header.b=byZ0AKcZ; spf=pass (domain: linux.ibm.com, ip: 148.163.158.5, mailfrom: jejb@linux.ibm.com) Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 19MEE8G0019509; Fri, 22 Oct 2021 11:01:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : subject : from : reply-to : to : cc : date : in-reply-to : references : content-type : mime-version : content-transfer-encoding; s=pp1; bh=8eV3iBwSzLU1BLJlmHIb7Wyzn65rXK4F1GITvuxZ7dg=; b=byZ0AKcZeiroHqmwv/Iqyok8H9auA2XiAszJftCYO9XXKD5i36NrqbXtkzHyiDdUlLWz s/JsFv4fu+bJKdMcMkTmIk56c2OOi+/oWr42xopy8mmXldGmjEGtKhW5y7GBhCb5uFCX EN0xGn962UAIVbidAl7kQHADK9j/QHEEEQS6LjXZBAzAN7O6mg/ErubrrTWwsT5GPJsj bgtJ/l9MGGYPx4oV8lFunFzn9MP7rto4eZwPH0W94Qs4wSATV47WJ5iGYkNBIQzUf4OY hm/gSqvxpuei67UDdff29Ip0sXh1VhOOhoBEvrFbRkfsUJhEFB84eLymGgTCWY3x3NVj 5w== Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com with ESMTP id 3burduhnr7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Oct 2021 11:01:45 -0400 Received: from m0098419.ppops.net (m0098419.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 19MEu28D001570; Fri, 22 Oct 2021 11:01:45 -0400 Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0b-001b2d01.pphosted.com with ESMTP id 3burduhnqq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Oct 2021 11:01:44 -0400 Received: from pps.filterd (ppma01dal.us.ibm.com [127.0.0.1]) by ppma01dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 19MEwR8U012371; Fri, 22 Oct 2021 15:01:43 GMT Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by ppma01dal.us.ibm.com with ESMTP id 3bqpcek3k6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Oct 2021 15:01:43 +0000 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 19MF1HMR32244032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 22 Oct 2021 15:01:17 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 72F4A7806D; Fri, 22 Oct 2021 15:01:17 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2C60278063; Fri, 22 Oct 2021 15:01:16 +0000 (GMT) Received: from jarvis.int.hansenpartnership.com (unknown [9.211.92.132]) by b03ledav004.gho.boulder.ibm.com (Postfix) with ESMTP; Fri, 22 Oct 2021 15:01:15 +0000 (GMT) Message-ID: <5fa198e0c4df2436ebbbe01cc8ebad4062e679b5.camel@linux.ibm.com> Subject: Re: [edk2-devel] [PATCH 4/4] OvmfPkg: add TPM2_SHA1_ENABLE build option From: "James Bottomley" Reply-To: jejb@linux.ibm.com To: Stefan Berger , devel@edk2.groups.io, Gerd Hoffmann Cc: Min Xu , Jordan Justen , Erdem Aktas , Ard Biesheuvel , =?ISO-8859-1?Q?Marc-Andr=E9?= Lureau , Jiewen Yao , Tom Lendacky , Brijesh Singh Date: Fri, 22 Oct 2021 11:01:14 -0400 In-Reply-To: References: <20211021122003.2008499-1-kraxel@redhat.com> <20211021122003.2008499-5-kraxel@redhat.com> <03a75199-000f-5575-8898-6d9b113f2bee@linux.ibm.com> <20211022063948.mratwrzgponwiulg@sirius.home.kraxel.org> <46963c6b6e0eea2bf0b3629031f6f04232ea7528.camel@linux.ibm.com> <84d94886-bc85-9b98-6c7e-59207e6ea741@linux.ibm.com> User-Agent: Evolution 3.34.4 MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-Proofpoint-GUID: gPt5rLp8_kidN-f_Y8Df397Rh_WLeE8H X-Proofpoint-ORIG-GUID: 6wIjVjJu4gX5aLvGHkv4h0gTEoRLiadX X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-22_04,2021-10-22_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 phishscore=0 mlxscore=0 malwarescore=0 suspectscore=0 impostorscore=0 adultscore=0 mlxlogscore=999 clxscore=1015 spamscore=0 bulkscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110220087 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Fri, 2021-10-22 at 10:52 -0400, Stefan Berger wrote: > On 10/22/21 10:17 AM, James Bottomley wrote: > > On Fri, 2021-10-22 at 09:13 -0400, Stefan Berger wrote: > > > On 10/22/21 8:40 AM, James Bottomley wrote: > > > > > > > On Fri, 2021-10-22 at 07:57 -0400, Stefan Berger wrote: > > > > > On 10/22/21 7:49 AM, James Bottomley wrote: > > > > > > On Fri, 2021-10-22 at 06:50 -0400, Stefan Berger wrote: > > > > > > [...] > > > > > > > I see this also but when I get into Linux and run > > > > > > > tpm2_pcrread I see the SHA1 bank active but not having > > > > > > > received any PCR extensions from the firmware, which is > > > > > > > not supposed to happen. > > > > > > > > > > > > That's not entirely correct: the TCG firmware profile just > > > > > > requires us to log through at least one bank; it doesn't > > > > > > require that all active banks be logged. I've got several > > > > > > physical systems with three active banks but only one or > > > > > > two measured through. > > > > > > > > > > The problem with this is that you can then fake measured boot > > > > > on that system using it's unused SHA1 bank and extend into it > > > > > whatever you want and create a fake log along with it and the > > > > > quote is going to look alright. > > > > > > > > I don't think you can. The measured boot PCRs in unused banks > > > > should always be their default values and the measurement > > > > software should check for this. So on a system that only uses > > > > the sha256 bank, the sha1 bank PCR0-7 should be all zeros ... > > > > if they aren't this should be a measurement failure. > > > > > > > > That means that if you try to replace the sha256 agile log with > > > > one containing fake sha1 entries, the attestation still fails > > > > because the sha256 bank doesn't have default entries. > > > > > > You can still pretend that your system only has an active SHA1 > > > bank and serve the fake log. > > > > Which "You" can fake a TPM quote? The whole design of the TPM > > system is supposed to be that what goes into the TPM can't be > > erased, only updated and we can get definitive proof of the values > > using a quote. > > What I meant is the admin runs TPM2_PCR_Extend on PCRs 0-7 of the > unused sha1 bank and extends it with known good values and has a log > that goes with it and presents these to a validator Yes, I got all that. > along with the quote on the sha1 bank. The validator shouldn't accept that quote ... it should require a quote covering all banks. This is the point: you can't fake the quote and the quote should cover all banks to assure you that unextended banks really are. > > You can fake the log to be sha1 only but you can't make it match > > the quote that includes the sha256 banks. > > Yes, that's right. The client must insist that the sha256 bank, and > any other possible bank, is quoted so that the system cannot just > pretend that it only has a XYZ [sha1] bank (unlikely for TPM 2), Impossible per the TPM spec. > and ABC banks [sha256] doesn't exist there, even though the SHA256 > matches the true log. A quote by itself doesn't quote all the banks. > You have to select which banks to quote and the client needs to have > some control over that it seems to for sure see what the true > firmware did. Hey, I'm not going to disagree that the TPM system leaves many ways for people to shoot themselves in the foot. The only point I'm making is that if you use it correctly (which I fully accept is somewhat complex) you quote all banks and thus can't be tricked into accepting a fake log through a bank unextended by firmware. James