[PATCH 2/2] efi_selftest: add selftest for EFI_TCG2_PROTOCOL and Measured Boot

Masahisa Kojima masahisa.kojima at linaro.org
Mon Nov 1 10:38:20 CET 2021


Hi Heinrich, Ilias,

On Sat, 30 Oct 2021 at 15:18, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
>
>
> Am 30. Oktober 2021 08:02:02 MESZ schrieb Ilias Apalodimas <ilias.apalodimas at linaro.org>:
> >Hi Heinrich
> >
> >[...]
> >
> >> >>> +$(obj)/efi_selftest_tcg2.o: $(obj)/efi_miniapp_file_image_measuredboot.h
> >> >>> diff --git a/lib/efi_selftest/efi_selftest_miniapp_measuredboot.c b/lib/efi_selftest/efi_selftest_miniapp_measuredboot.c
> >> >>
> >> >> Thank you for going the extra mile and adding the test.
> >> >>
> >> >> Which image is actually loaded seems to be irrelevant for the test. Can
> >> >> we reuse an existing one, e.g. efi_miniapp_file_image_return.h?
> >> >>
> >> >> I guess the PCR related to the loaded image is not checked as it will
> >> >> depend on the build tools and date.
> >> >
> >> > Sorry, I'm doing wrong.
> >> > Actually this selftest verifies the PE/COFF image measurement, so measuremt
> >> > will be different depending on the build tools and date.
> >> >   # In my build environment, timestamp is set to all zero.
> >> >
> >> > To test the PE/COFF image measurement, I must prepare the
> >> > static PE/COFF image. I plan to add efi_miniapp_file_image_measuredboot.h
> >> > as a pre-compiled small static PE/COFF image for the measurement test,
> >> > instead of adding efi_selftest_miniapp_measuredboot.c or reusing existing one.
> >>
> >> You will need one image per UEFI architecture (ia32, x64, arm, aa64,
> >> riscv32, riscv64). You could present the image via the
> >> EFI_LOAD_FILE2_PROTOCOL, see lib/efi_selftest/efi_selftest_load_file.c.
> >
> >The EFI TCG2 is governed by a spec.  What it basically does is extend
> >a number of hardware PCRs with a sha1/256/384/512 for a given image.
> >Wouldn't performing the selftest for arm/arm64 be enough?  What am I
> >missing?
>
> People on other architectures should be able to run the selftest on a real device (not QEMU). If you have trouble building for RISC-V, I can help.

I am encountering errors in x86_64, riscv32 and riscv64.

[x86_64]
 - swtpm does not work on x86_64 qemu, It is probably U-Boot side issue
   but I could not run tcg2 efi_selftest for x86_64.
=====
U-Boot 2021.10-00965-g2c308dc11a (Nov 01 2021 - 14:24:18 +0900)

CPU:   QEMU Virtual CPU version 2.5+
DRAM:  128 MiB
Loading Environment from nowhere... OK
Incorrect expansion ROM header signature 4daa
Model: QEMU x86 (I440FX)
Net:   e1000: 52:54:00:12:34:56
       eth0: e1000#0
Hit any key to stop autoboot:  0
=>
=> tpm2 startup TPM2_SU_CLEAR
Couldn't set TPM 0 (rc = 1)
=====

[riscv32/riscv64]
 - riscv32/riscv64 QEMU seems not to support TPM device, qemu-system-riscv32 and
qemu-system-riscv64 ends with the error "No TPM backend types are available".
 - The available backend types are "passthrough" or "emulator",
"emulator" must be
   used for swtpm.
=====
ubuntu at ubuntu-W331AU:~/src/test/u-boot$ qemu-system-riscv32 -nographic
-machine virt -bios u-boot -chardev
socket,id=chrtpm,path=/tmp/mytpm1/swtpm-sock -tpmdev
emulator,id=tpm0,chardev=chrtpm -device tpm-tis,tpmdev=tpm0
qemu-system-riscv32: -tpmdev emulator,id=tpm0,chardev=chrtpm:
Parameter 'type' expects a TPM backend type
No TPM backend types are available
=====
=====
ubuntu at ubuntu-W331AU:~/src/test/u-boot$ qemu-system-riscv64 -nographic
-machine virt -bios u-boot -chardev
socket,id=chrtpm,path=/tmp/mytpm1/swtpm-sock -tpmdev
emulator,id=tpm0,chardev=chrtpm -device tpm-tis,tpmdev=tpm0
qemu-system-riscv64: -tpmdev emulator,id=tpm0,chardev=chrtpm:
Parameter 'type' expects a TPM backend type
No TPM backend types are available
=====

Is it OK if I add the tcg2 efi_selftest for arm/arm64 for now?

Thanks,
Masahisa Kojima




>
> Regards
>
> Heinrich
>
> >
> >[...]
> >
> >Regards
> >/Ilias


More information about the U-Boot mailing list