From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1gj2wE-0006pg-1B for mharc-grub-devel@gnu.org; Mon, 14 Jan 2019 09:10:02 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50441) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gj2w8-0006nQ-Ia for grub-devel@gnu.org; Mon, 14 Jan 2019 09:09:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gj2w7-0001ui-Kz for grub-devel@gnu.org; Mon, 14 Jan 2019 09:09:56 -0500 Received: from mx0b-00190b01.pphosted.com ([2620:100:9005:57f::1]:42624) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gj2w7-0001t2-85 for grub-devel@gnu.org; Mon, 14 Jan 2019 09:09:55 -0500 Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x0EDo1Ux005536; Mon, 14 Jan 2019 14:09:50 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=c4Go5PxdT/jsFC/q5+Kw1PU9kjCMmjP+YUT30CFFC24=; b=TCK33sNOksDPlzT3qd6DxQEpEqlOTQgIOdEQ0qMdb+mhPDQ9rmzU3mgKXANULR5H0IeA 3Klnr6nhfisuWPj9ERUd06wU+2rdjlYrmoOhkf/hlocpUXes8XJWyN13g6C/plhC/e+r zcn5SilH6wwAy3MJtv/+3sVAAQ1peIyuB3j46ziPXSMpQsGc4IJ8zLAKZL9zQBoYr5rt Z2S7QzRoBUgGPP2vGCveSWATo9h1Y/e+65Mej/3ZXjQ57gxWR0PfD+ecvYMoFGa12d5d uNi1Gn3/S97IeLs1ZWnStGuryeL8XR1ajAFqpwz/z4OaHfiu2Y6631ttE/IQMQ9pHYb4 ag== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050102.ppops.net-00190b01. with ESMTP id 2q0sf2rt45-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Jan 2019 14:09:50 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x0EE2B0q008433; Mon, 14 Jan 2019 09:09:49 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2pycf0jpra-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 14 Jan 2019 09:09:48 -0500 Received: from USMA1EX-CAS2.msg.corp.akamai.com (172.27.123.31) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 14 Jan 2019 09:09:48 -0500 Received: from lon-lp55b.london.corp.akamai.com (172.29.67.66) by USMA1EX-CAS2.msg.corp.akamai.com (172.27.123.31) with Microsoft SMTP Server id 15.0.1365.1 via Frontend Transport; Mon, 14 Jan 2019 09:09:47 -0500 Received: by lon-lp55b.london.corp.akamai.com (Postfix, from userid 37336) id 6F6F6E0CB9; Mon, 14 Jan 2019 14:09:45 +0000 (GMT) Date: Mon, 14 Jan 2019 14:09:45 +0000 From: Max Tottenham To: Daniel Kiper CC: , Subject: Re: TPM/Verifiers testing bug? Message-ID: <20190114140944.GE30574@akamai.com> References: <20190109141616.GC4954@akamai.com> <20190114111305.nzguqe5yyu4ujnb7@tomti.i.net-space.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20190114111305.nzguqe5yyu4ujnb7@tomti.i.net-space.pl> User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-14_07:, , 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-1810050000 definitions=main-1901140116 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-14_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901140110 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 2620:100:9005:57f::1 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 14:09:57 -0000 On 01/14, Daniel Kiper wrote: > On Wed, Jan 09, 2019 at 02:16:16PM +0000, Max Tottenham wrote: > > Hi Folks > > > > I was curious about the upstream work on the verifiers framework (and > > the TPM patches). I have both a TPM 2.0 based system and a QEMU + swtpm > > setup with which to test. I compiled the head of the master branch, if I > > boot into the grub shell and run the following commands: > > > > grub> insmod verifiers > > grub> insmod tpm > > grub> normal > > > > I get a machine crash: > > > > qemu-system-x86_64: Trying to execute code outside RAM or ROM at > > 0x00000000000b0000 > > This usually means one of the following happened: > > > > (1) You told QEMU to execute a kernel for the wrong machine type, and it > > crashed on startup (eg trying to run a raspberry pi kernel on a > > versatilepb QEMU machine) > > (2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU > > executed a ROM full of no-op instructions until it fell off the end > > (3) Your guest kernel has a bug and crashed by jumping off into nowhere > > > > This is almost always one of the first two, so check your command line > > and that you are using the right type of kernel for this machine. > > If you think option (3) is likely then you can try debugging your guest > > with the -d debug options; in particular -d guest_errors will cause the > > log to include a dump of the guest register state at this point. > > > > Execution cannot continue; stopping here. > > > > > > Software versions: > > Qemu version: v2.11.0 (0a0dc59) > > OVMF git tag: edk2-stable201811 (8558838) > > swtpm git tag: tpm2-preview.v2 (f98592c) > > > > > > Running the same on real hardware also produces a crash, any thoughts? > > Adding Matthew who is the author of the patch series. > > Daniel I went ahead and did some debugging. Below is a patch that seems to fix my problem. Although those calls to grub_efi_open_protocol() in the tpm module should probably check their return value and do something sane if 0x0 is returned. -- Max Tottenham | mtottenh@akamai.com Senior Software Engineer, Server Platform Engineering /(* Akamai Technologies >From 023be8fe8a4f77dbcbf94015bef81385a7681679 Mon Sep 17 00:00:00 2001 From: Max Tottenham Date: Mon, 14 Jan 2019 14:03:29 +0000 Subject: [PATCH] Fix bug in GRUB2 TPM module The value of tpm_handle changes between successive calls to tpm_handle_find(), as instead of simply copying the stored pointer we end up taking the address of said pointer when using the cached value of grub_tpm_handle. This causes grub_efi_open_protocol() to return a nullptr in grub_tpm2_execute() and grub_tpm2_log_event(). Said nullptr goes unchecked and efi_call_5(tpm->hash_log_extend_event,...) ends up jumping to 0x0, Qemu crashes once video ROM is reached at 0xb0000. This patch seems to do the trick of fixing that bug, but we should also ensure that all calls to grub_efi_open_protocol() are checked so that we don't start executing low memory. --- grub-core/commands/efi/tpm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/grub-core/commands/efi/tpm.c b/grub-core/commands/efi/tpm.c index 563ceba7a..7475fd87b 100644 --- a/grub-core/commands/efi/tpm.c +++ b/grub-core/commands/efi/tpm.c @@ -89,7 +89,7 @@ grub_tpm_handle_find (grub_efi_handle_t *tpm_handle, if (grub_tpm_handle != NULL) { - *tpm_handle = &grub_tpm_handle; + *tpm_handle = grub_tpm_handle; *protocol_version = grub_tpm_version; return 1; } -- 2.17.0