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.web11.7581.1634906425094829553 for ; Fri, 22 Oct 2021 05:40:25 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@ibm.com header.s=pp1 header.b=ds+VDfL0; spf=pass (domain: linux.ibm.com, ip: 148.163.156.1, mailfrom: jejb@linux.ibm.com) Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 19MCLv9c002561; Fri, 22 Oct 2021 08:40:20 -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=+yHSeIBIiBYLLL2cvyILkt+bZ1rSxxKdzMr96kFvAF4=; b=ds+VDfL0rz0eYIV+fKKM6UhcmqnNMNJCe8LnALgcc/hsjFKz+KfVTLRwp1YtIwuGyPKJ GV/6cuGrk/o2pA0gI8tju8Pn4YzZhp3s7wwn7adsLqN0+YF196ILhQWMY/Ij/DaxJCTf rTUUXunnAl1N3xk39Ehd7f1QI+aYGO7cg9u2czCQ1/3meogoaHhJL6aMCbYD8sjeOsiG u1CXgnAgHY6oSrl25ssGn+kk1m6I7ZadiHYehRkwNzs0DZF0fnNsy4gKo90lMViDx5Ch wqNNcRk+RDxuMVbFtVFK0cJe/27FOOiMWYlfUzT+5moqu59APBsf/bdlV1VeIrsb4/Xy Lw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3butj3bqqn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Oct 2021 08:40:20 -0400 Received: from m0098396.ppops.net (m0098396.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 19MBWmIl022377; Fri, 22 Oct 2021 08:40:20 -0400 Received: from ppma03dal.us.ibm.com (b.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.11]) by mx0a-001b2d01.pphosted.com with ESMTP id 3butj3bqqb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Oct 2021 08:40:19 -0400 Received: from pps.filterd (ppma03dal.us.ibm.com [127.0.0.1]) by ppma03dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 19MCbbAG022881; Fri, 22 Oct 2021 12:40:19 GMT Received: from b03cxnp07027.gho.boulder.ibm.com (b03cxnp07027.gho.boulder.ibm.com [9.17.130.14]) by ppma03dal.us.ibm.com with ESMTP id 3bqpcdrc8p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Oct 2021 12:40:18 +0000 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp07027.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 19MCeHfI27656594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 22 Oct 2021 12:40:17 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A38F478063; Fri, 22 Oct 2021 12:40:17 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 42D2F7805C; Fri, 22 Oct 2021 12:40: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 12:40:16 +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 08:40:15 -0400 In-Reply-To: <84d94886-bc85-9b98-6c7e-59207e6ea741@linux.ibm.com> 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: UuDLliauPPuquXTKtOnku_tF1xFlXRZX X-Proofpoint-ORIG-GUID: wGezUJdqx0ntOLf9T1b_EP-Ht0ByXoH0 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_03,2021-10-22_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 lowpriorityscore=0 spamscore=0 priorityscore=1501 bulkscore=0 mlxlogscore=999 phishscore=0 clxscore=1015 adultscore=0 suspectscore=0 malwarescore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110220070 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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. > > The knock on problem the linux kernel is going to have is that we > > do tend to expect the sha1 bank to be extended into if any others > > are, so someone is going to have to update expectations ... we > > should have this in hand already as sha1 is deprecated. > > > > > 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. James