From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by mx.groups.io with SMTP id smtpd.web08.9048.1634912241131689931 for ; Fri, 22 Oct 2021 07:17:21 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@ibm.com header.s=pp1 header.b=l9Cg55YK; spf=pass (domain: linux.ibm.com, ip: 148.163.156.1, mailfrom: jejb@linux.ibm.com) Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 19MDljCH016548; Fri, 22 Oct 2021 10:17:19 -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=mRfT3u6g6qKTIVtEySI7P8COJmMaLZ+A+iObekRv8Qo=; b=l9Cg55YKxwhPgqlVbpJCXMO5J1BGrbbQhsfVFEkZlfFsLNrrk137Rw4khlmiA5/ywpGu AcdywUVC2S4CR0Ut0Q2WKjv7Nr4Cy9qndyrw6tLmTnUf054pIKJQh7boFTzrB1UD7DNN EsIgj+iRCld0pUvVh2uBl6/BZCni4dzxP/UMmhmFzNGKrlpQgizRcfo5amZZ+eR+vl33 oqJGSfqp9yflcyDUBy7KmRx1TPJ6qXhzDwgZ1/OO4zgsplVLcjGRxU/OjW91J9WD53IP njrBa+GoyN99kiErTlafa9naHqKnpZbvweaDCFDmx9iLie0vS1q8OeIKAFLDDVb3AcUR dQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3buxgf8nq2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Oct 2021 10:17:19 -0400 Received: from m0098404.ppops.net (m0098404.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 19ME1iq1009001; Fri, 22 Oct 2021 10:17:18 -0400 Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0a-001b2d01.pphosted.com with ESMTP id 3buxgf8np3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Oct 2021 10:17:18 -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 19MECSLR032603; Fri, 22 Oct 2021 14:17:17 GMT Received: from b03cxnp07029.gho.boulder.ibm.com (b03cxnp07029.gho.boulder.ibm.com [9.17.130.16]) by ppma01dal.us.ibm.com with ESMTP id 3bqpcej4js-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Oct 2021 14:17:17 +0000 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp07029.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 19MEHFJg28705136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 22 Oct 2021 14:17:15 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 158B678060; Fri, 22 Oct 2021 14:17:15 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 57E9678063; Fri, 22 Oct 2021 14:17:13 +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 14:17:13 +0000 (GMT) Message-ID: Subject: Re: [PATCH 4/4] OvmfPkg: add TPM2_SHA1_ENABLE build option From: "James Bottomley" Reply-To: jejb@linux.ibm.com To: Stefan Berger , Gerd Hoffmann Cc: devel@edk2.groups.io, 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 10:17:11 -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: _GT0fWhLZM2e-nCg0lLmnIVtlQNW34sT X-Proofpoint-ORIG-GUID: 5q8JtcCgr_dPGnn67Bfb-Vv1NoRE6mfV 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 malwarescore=0 bulkscore=0 clxscore=1015 mlxlogscore=999 impostorscore=0 suspectscore=0 lowpriorityscore=0 phishscore=0 mlxscore=0 spamscore=0 priorityscore=1501 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110220081 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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. You can fake the log to be sha1 only but you can't make it match the quote that includes the sha256 banks. > at that trusted boot log, SHA1 PCR 0-7 state, and quote then? You don't just quote the bank you think is being logged ... you should quote all banks of the TPM; that way you can't be duped in this fashion. > > > > > So I think you should drop this patch and I'll change the > > > > > set of active PCR banks on the swtpm_setup level. > > > > > > > > Even if the firmware deactivated the sha1 bank, the kernel > > > > expectation problem is still going to exist. > > > > > > Is that older Linux kernels or which part still requires sha1? A > > > pointer would be good. I would have to revert the change to not > > > activat ethe SHA1 bank from swtpm_setup if that's going to create > > > headaches. I thought some hardware TPM 2's today are only > > > providing a SHA256 bank and so it shouldn't be a problem. > > > > The problem is IMA: it's hash is a kernel config parameter which > > defaults to sha1. It then tries to calculate the boot aggregate > > over the configured hash bank and doesn't check if it's unused. > > > > What IMA should probably be doing is working out which bank the > > bios is logging through and using that as the hash instead of > > having it as a Kconfig parameter. > > I think IMA is doing the right thing and extending into SHA1 and > SHA256 PCRs if the banks are active and with the boot aggregate puts > a lid on top of the PCRs 0-7(,8-9). IMA may help raise the suspicion > about abuse of an unused PCR bank by the firmware but looking at the > measured boot log etc. alone I think is not enough. The problem is not where IMA extends, it's where it gets the boot aggregate from. If the IMA hash is sha1 and a sha1 bank exists, it will use it alone for the boot aggregate. > At least a test with a recent kernel seems to work out alright when > only the SHA256 bank is active. Well, yes, if IMA is configured as sha1 and no sha1 bank exists, it will fall back to sha256, but that doesn't cover the boot aggregate problem above. James