From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1iPQMe-0004l1-40 for mharc-grub-devel@gnu.org; Tue, 29 Oct 2019 08:12:44 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44670) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iPQMb-0004gD-3C for grub-devel@gnu.org; Tue, 29 Oct 2019 08:12:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iPQMZ-0004eP-TG for grub-devel@gnu.org; Tue, 29 Oct 2019 08:12:40 -0400 Received: from us-smtp-2.mimecast.com ([207.211.31.81]:21340 helo=us-smtp-delivery-1.mimecast.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iPQMZ-0004eD-PC for grub-devel@gnu.org; Tue, 29 Oct 2019 08:12:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1572351159; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TH8oue4Ymn2YjKZpb+hMHuvpaQyPkdzTARLVQ+sMpAQ=; b=ArH6j+iP9UCSKfSnYrLRiY7hUjI6Dk3C76EpBw7TL6XFdemu3w/KBz85lpX2aF/DEO4IWH SvDuYJQo0kR3qABWH4vg+1mGgYRmDOzr57vUoUOmyNuyANLfeUTyTNTjve8u2GVE3QSEoA yNkIhaBOVSEjuv6FQLWBfkUkSYOdaFI= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-251-vCEkyRJKM7agzf9f4mSIfw-1; Tue, 29 Oct 2019 08:12:37 -0400 Received: by mail-wr1-f69.google.com with SMTP id b4so846208wrn.8 for ; Tue, 29 Oct 2019 05:12:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=PNhI73DcB1nNs8wZsPPj1oZeI5FdKrZOewFy9f69FJc=; b=MlMcvoL+zJnesUlXk/Gjc08QQwBtH1sQ+PLezbmgRYBSf9OLFmeRnPSF9VmukNTN52 cahOlKpm3rn+yoab7gaOfl2+u9Nc3JiTxIwJoHsOxp11hQZTcwUAJUQNulkhhx+JoGgs wpj0Bnwo9lCayA0zj7ZY/CY+EbOf9SCzzFzq2UVzoliXpNC3QNN9kqd7avrJKrtPvBn4 AVtCWhB1NVwBxwFnVvuOxwpexb9gbuSi7NZ0aean0NW8apSWFKA5VfuBDeHd4T06/ADM oTZwzmscf5qNSWOsS6HNWPEnLH6fnOnuP3XGbkQc2Hl4s6o9sysr7ylntVQa4I2KjI5L 17qQ== X-Gm-Message-State: APjAAAUoUGrezMF5ahntfcPFKMReAoEcTIkpKPstXotdn+5tYSX4fqAc vNnI6zwAg7ANjJlLQaahjWbKs69vh9pZo6+mKgE0PkmXnrTd130vou6VXhlKu62HWdvbjnP6LX+ kNzQSXnStU+4= X-Received: by 2002:adf:f2d1:: with SMTP id d17mr18876946wrp.353.1572351156782; Tue, 29 Oct 2019 05:12:36 -0700 (PDT) X-Google-Smtp-Source: APXvYqyltqkTkTfXpUUaURQ7NRgb+dFcf0c0A1HTdn/WOMzzwyj5r/YG1q3NYrL5b33P7i6G2ZwvJg== X-Received: by 2002:adf:f2d1:: with SMTP id d17mr18876921wrp.353.1572351156481; Tue, 29 Oct 2019 05:12:36 -0700 (PDT) Received: from [192.168.1.13] ([90.168.169.92]) by smtp.gmail.com with ESMTPSA id q14sm17965201wre.27.2019.10.29.05.12.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Oct 2019 05:12:35 -0700 (PDT) Subject: Re: [PATCH] tpm: Pass unknown error as non-fatal, but debug print the error we got To: The development of GNU GRUB Cc: Max Tottenham , Mathieu Trudel-Lapierre , Mathieu Trudel-Lapierre References: <20191025142754.1514-1-mathieu.trudel-lapierre@canonical.com> <7bc13635-52bd-9caa-14f5-312bffe682e2@redhat.com> <20191029104903.GD11778@akamai.com> From: Javier Martinez Canillas Message-ID: <9e889498-9c31-fd92-eaeb-9b107d440fce@redhat.com> Date: Tue, 29 Oct 2019 13:12:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.0 MIME-Version: 1.0 In-Reply-To: <20191029104903.GD11778@akamai.com> Content-Language: en-US X-MC-Unique: vCEkyRJKM7agzf9f4mSIfw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 207.211.31.81 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 12:12:42 -0000 Hello Max, On 10/29/19 11:49 AM, Max Tottenham via Grub-devel wrote: > On 10/25, Javier Martinez Canillas wrote: [snip] >>> >> >> 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]. >> >=20 > This poses a slight problem. For folks who rely on TPM sealed values > this would potentially make the issue harder to address.=20 > I fail to see how making it a non-fatal error would make this harder for us= ers that rely on TPM sealed values. If the HashLogExtendEvent failed and the PCR were not extended, then the se= aled values won't be unsealed by the TPM. So it won't be less secure for users w= hile still allowing the system to boot for users that aren't relying on PCR valu= es. And even for users that rely on it, I think that halting the boot is too ex= treme. For example a user could have a LUKS volume key sealed with a TPM but still= have another key slot with a passphrase as fallback in case the PCR measurements= fail. Even for the case you mentioned that EFI firmware could return an EFI_VOLUM= E_FULL meaning that the extend operation occurred but the event could not be writt= en to the event log, then attestation software that not only check the PCR values= but also the event logs will determine that the logs are not correct and report= that the system is not healthy. Then you could reboot your machine enabling debug logs for grub and check i= f the call to HashLogExtendEvent is failing and what error code is returning to a= ddress the issue and troubleshoot. In other words, preventing the system from booting should be the last optio= n in my opinion and only for situations where there is really no other choice. > 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? > Yes, having a compile time or runtime option to choose this could work. But I'm still not convinced that halting the boot process due a TPM measurement failure is the correct thing to do. Best regards, --=20 Javier Martinez Canillas Software Engineer - Desktop Hardware Enablement Red Hat