grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TPM/Verifiers testing bug?


From: Daniel Kiper
Subject: Re: TPM/Verifiers testing bug?
Date: Mon, 21 Jan 2019 13:06:40 +0100
User-agent: NeoMutt/20170113 (1.7.2)

On Mon, Jan 14, 2019 at 02:09:45PM +0000, Max Tottenham wrote:
> 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       | address@hidden
> Senior Software Engineer, Server Platform Engineering
> /(* Akamai Technologies
>
> >From 023be8fe8a4f77dbcbf94015bef81385a7681679 Mon Sep 17 00:00:00 2001
> From: Max Tottenham <address@hidden>
> 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.

I have added your SOB and pushed. I hope that you do not mind.

Daniel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]