From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1iPP40-0007EH-6c for mharc-grub-devel@gnu.org; Tue, 29 Oct 2019 06:49:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33242) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iPP3t-0007DX-O2 for grub-devel@gnu.org; Tue, 29 Oct 2019 06:49:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iPP3q-0005nb-A5 for grub-devel@gnu.org; Tue, 29 Oct 2019 06:49:15 -0400 Received: from mx0a-00190b01.pphosted.com ([2620:100:9001:583::1]:63462) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iPP3p-0005jp-NJ for grub-devel@gnu.org; Tue, 29 Oct 2019 06:49:14 -0400 Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x9TAks8U007245; Tue, 29 Oct 2019 10:49:06 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=muG1MVrF0MB8BeaN2w1X/wnsplwWmutLEHONL9X8NFw=; b=HhKNCOCpY/0GSvYchLfdzQwltb+xRQO6LqXGbV7DyIeckz/WUDD983g2Q0e9OTMYLR0o uyP8AtTyZThdQu+sft2uFC+uAezySp0UZph0lSq1mSfEtFGwgqpqznlPTVZG0Kq6i365 Lu9p/Scsl5bduCcJdhvd/ebCEARluUJz/YYYyHHV4wUcgvnyi4DdFTpawSj4zByC3f9S xW8lMULm52A5avxLdvpJuYJ67qs8V7uXAa+z41bJSpDYiuBQnO96x6gFP4q38ZE3PJm8 hNcdQc2hN0Ks9yHvP/FD+fe4vsYnyxbCgAKeGY23zCSUkDl8wDpGkwTpdg6d9NTHslkb 1A== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2vvddpxx4r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 Oct 2019 10:49:06 +0000 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9TAkunP025055; Tue, 29 Oct 2019 03:49:05 -0700 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint5.akamai.com with ESMTP id 2vvm48c5dt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 29 Oct 2019 03:49:04 -0700 Received: from USMA1EX-CAS3.msg.corp.akamai.com (172.27.123.32) by usma1ex-dag3mb6.msg.corp.akamai.com (172.27.123.54) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 29 Oct 2019 06:49:03 -0400 Received: from lon-lp55b.london.corp.akamai.com (172.29.67.77) by USMA1EX-CAS3.msg.corp.akamai.com (172.27.123.32) with Microsoft SMTP Server id 15.0.1473.3 via Frontend Transport; Tue, 29 Oct 2019 06:49:03 -0400 Received: by lon-lp55b.london.corp.akamai.com (Postfix, from userid 37336) id 90E7FDFCE7; Tue, 29 Oct 2019 10:49:03 +0000 (GMT) Date: Tue, 29 Oct 2019 10:49:03 +0000 From: Max Tottenham To: The development of GNU GRUB CC: Mathieu Trudel-Lapierre , Mathieu Trudel-Lapierre Subject: Re: [PATCH] tpm: Pass unknown error as non-fatal, but debug print the error we got Message-ID: <20191029104903.GD11778@akamai.com> References: <20191025142754.1514-1-mathieu.trudel-lapierre@canonical.com> <7bc13635-52bd-9caa-14f5-312bffe682e2@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <7bc13635-52bd-9caa-14f5-312bffe682e2@redhat.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-29_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910290113 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-29_03:2019-10-28,2019-10-29 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 mlxlogscore=999 impostorscore=0 spamscore=0 bulkscore=0 lowpriorityscore=0 malwarescore=0 phishscore=0 priorityscore=1501 suspectscore=0 clxscore=1011 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910290113 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 2620:100:9001:583::1 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2019 10:49:21 -0000 On 10/25, Javier Martinez Canillas wrote: > Hello Mathieu, > > On 10/25/19 4:48 PM, Mathieu Trudel-Lapierre wrote: > > On Fri, Oct 25, 2019 at 10:28 AM Mathieu Trudel-Lapierre > > wrote: > >> > >> Signed-off-by: Mathieu Trudel-Lapierre > >> Patch-Name: ubuntu-tpm-unknown-error-non-fatal.patch > >> --- > >> grub-core/commands/efi/tpm.c | 12 ++++++++---- > >> 1 file changed, 8 insertions(+), 4 deletions(-) > >> > > > > I see I omitted to explain why I'm proposing this. > > > > I've seen a couple of reports so far of issues with booting with TPM > > measurement enabled, when the firmware has TPM enabled, on some > > hardware. > > > > In particular, this has happened on a Dell laptop at Plumbers this > > year (an older model XPS15 IIRC), and a few different models of > > laptops/motherboards. Some report having a TPM, and some do not: > > > > HP EliteBook 820 G4 (Infineon SLB9670?) > > ASUS M32CD4-K motherboard (unknown) > > ASUS ROG GL553VE Laptop (unknown) > > ASUS ZenBook 3 UX390UA (unknown) > > ASUS Zenbook UX305FA (unspecified TPM) > > ASUS ZenBook UX303UA (unknown) > > ASUS 2O7HSV6 ?? > > > > See https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1848892. > > > > Yes, we also got similar reports for Fedora, i.e: > > https://bugzilla.redhat.com/show_bug.cgi?id=1645903 > > > Unfortunately the reports are not of great quality, but I'm starting > > to worry about what exactly is wrong, if it's really a firmware / TPM > > issue or a bug in the TPM code. > > > > For now, it seems like the best is to get more information as to what > > exactly the failure is (hence grub_dprintf()), and treating these > > Agreed. It would be good to get know the exact EFI status code returned by > the firmware in the case of a failure. > > > errors as non-fatal so people can still boot. > > > > I think that we should go even further and make all the TPM measurement > errors to be non-fatal. For example something like the following patch [0]. > This poses a slight problem. For folks who rely on TPM sealed values this would potentially make the issue harder to address. Maybe a compile time (or install time) option that allows a strictness policy to be set - those who don't care about TPM capability can let it default to printing warnings, those who rely on keying material sealed to TPM state can explicitly configure GRUB to halt the boot process on error? > > After briefly discussing this with others, it's not clear whether all > > the affected systems really do have a TPM, but they might still report > > in firmware that they do. Are we running into a case where the > > firmware wrongly reports there is a TPM, but fails to do any > > measurements? > > > > That's interesting. I see that EFI_TCG2_PROTOCOL.GetCapability() is called > and the EFI_TCG2_BOOT_SERVICE_CAPABILITY.TPMPresentFlag checked to know if > a TPM is present or not. So would be very weird that the firmware reported > that a TPM is present but that's not the case. > > Maybe the machines did have a TPM but the reporter just didn't know? > It's possible that they do have a TPM but measurements are failing for a different reason, I see that the TPM patches use HashLogExtendEvent - Looking at the EDKII source it looks like this could succeed in extending a PCR but fail to record the event in the event log (for example if the structure is full). This would provide a different return code (EFI_VOLUME_FULL), to any of the return codes that are being checked currently. In line with the above about allowing configurable policy around fatal measurement errors, it might be an idea to allow said flexibility to extend to which errors are deemed fatal (e.g. Measurement failure could be fatal but a failure to log the subsequent event could be dealt with a simple warning). -- Max Tottenham | mtottenh@akamai.com Senior Software Engineer, Server Platform Engineering /(* Akamai Technologies