This series of patches extends the TPM2 code to extend the BIOS related
PCRs 0-7 in all available banks. This prevents that these PCRs remain
untouched and filled with bogus values by applications. For example, the
SHA1 hash is extended into the SHA256 bank. The value that is extended
into this bank is essentially a SHA1 with zero bytes used for filling it to
the size of a sha256 hash. This is done for all PCR banks of the TPM2
where these PCRs are available.
In v2 of this series I also extended the log functions for logging the
additional hashes. So there are more patches now.
Stefan Berger (6):
tpm: Retrieve the PCR Bank configuration
tpm: Restructure tpm20_extend to use buffer and take hash as parameter
tpm: Extend tpm20_extend to support extending to multiple PCR banks
tpm: Move tpm_log_init to a later point
tpm: Adjust the TPM2 log header to show all hashes
tpm: Append to TPM2 log the hashes used for PCR extension
src/std/tcg.h | 78 +++++++++++--
src/tcgbios.c | 348 ++++++++++++++++++++++++++++++++++++++++++++++++++--------
2 files changed, 371 insertions(+), 55 deletions(-)
On Tue, Aug 02, 2016 at 04:18:30AM +0000, Xulei (Stone) wrote:
> >On Fri, Jul 29, 2016 at 04:04:59AM +0000, Xulei (Stone) wrote:
> >> After one day, the vm is stuck. Looking from the following seabios log,
> >> it seems seabios stops at "PCI: Using 00:02.0 for primary VGA", and can
> >> not execute handle_smp() any more.
> >> What may be the reason?
> >More debugging info would be necessary to find this problem. You
> >could try reproducing and attaching gdb (
> >http://www.seabios.org/Debugging#Debugging_with_gdb_on_QEMU ).
> >Alternatively, a kvm trace log may help.
> kvm trace (seems useful) indicates that cpu 0 keeps always to access 0x00b3 ioport.
> 0x00b3 is PORT_SMI_STATUS, so i guess my bios is stuck in the function
> /* wait until SMM code executed */
> while (inb(PORT_SMI_STATUS) != 0x00)
I'd try adding dprintf() statements around all the code at the top of
smm_relocate_and_restore() and enable the dprintf() at the top of
It would also be useful if you can extract the log from the last
two working reboots to compare it to the failed case.
I'm currently working on coreboot but I stumbled on a strange SeaBIOS
After executing a payload and returning control to the caller SeaBIOS
The problem is currently solved by rebooting before the payload returns
but doing so also makes chaining multiple payloads impossible so I'm
trying to look into a solution.
I tried to increment the debug level to 8 to get more information and
the attached log is what I got.
I also attached a build of coreboot with this problem if someone wants
to try it in QEMU.
I'm not terribly knowledgeable about SeaBIOS so I'm a bit lost.
Could anyone point me where the problem could be originating from?
Thanks in advance,
On Fri, Jul 29, 2016 at 04:04:59AM +0000, Xulei (Stone) wrote:
> Hi, all:
> Recently when i try to reset a vm, I find it may be stuck in SeaBIOS.
> I use a shell script to continuously reset a vm to see what may happen.
> virsh reset VMNAME
> sleep 1
> After one day, the vm is stuck. Looking from the following seabios log,
> it seems seabios stops at "PCI: Using 00:02.0 for primary VGA", and can
> not execute handle_smp() any more.
> What may be the reason?
More debugging info would be necessary to find this problem. You
could try reproducing and attaching gdb (
Alternatively, a kvm trace log may help.