[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] tpm: Pass unknown error as non-fatal, but debug print the er
From: |
Daniel Kiper |
Subject: |
Re: [PATCH] tpm: Pass unknown error as non-fatal, but debug print the error we got |
Date: |
Mon, 28 Oct 2019 17:53:07 +0100 |
User-agent: |
NeoMutt/20170113 (1.7.2) |
Adding Matthew...
Matthew, whole thread is at [1].
Daniel
[1] https://lists.gnu.org/archive/html/grub-devel/2019-10/msg00103.html
On Fri, Oct 25, 2019 at 10:48:43AM -0400, Mathieu Trudel-Lapierre wrote:
> On Fri, Oct 25, 2019 at 10:28 AM Mathieu Trudel-Lapierre
> <address@hidden> wrote:
> >
> > Signed-off-by: Mathieu Trudel-Lapierre <address@hidden>
> > 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.
>
> 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
> errors as non-fatal so people can still boot.
>
> 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?
>
> Kindly,
>
> --
>
> Mathieu Trudel-Lapierre <address@hidden>
> Freenode: cyphermox, Jabber: address@hidden
> 4096R/65B58DA1 818A D123 0992 275B 23C2 CF89 C67B B4D6 65B5 8DA1