qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v7 0/3] Add support for TPM devices over I2C bus


From: Joel Stanley
Subject: Re: [PATCH v7 0/3] Add support for TPM devices over I2C bus
Date: Mon, 27 Mar 2023 08:04:00 +0000

On Mon, 27 Mar 2023 at 03:52, Ninad Palsule <ninad@linux.vnet.ibm.com> wrote:
>
> Hi Joel,
>
> On 3/26/23 8:05 PM, Joel Stanley wrote:
> > Hi Ninad,
> >
> > On Sun, 26 Mar 2023 at 22:44, Ninad Palsule <ninad@linux.ibm.com> wrote:
> >> Hello,
> >>
> >> I have incorporated review comments from Stefan. Please review.
> >>
> >> This drop adds support for the TPM devices attached to the I2C bus. It
> >> only supports the TPM2 protocol. You need to run it with the external
> >> TPM emulator like swtpm. I have tested it with swtpm.
> > Nice work. I tested these stop cedric's aspeed-8.0 qemu tree, using
> > the rainier machine and the openbmc dev-6.1 kernel.
> >
> > We get this message when booting from a kernel:
> >
> > [    0.582699] tpm_tis_i2c 12-002e: 2.0 TPM (device-id 0x1, rev-id 1)
> > [    0.586361] tpm tpm0: A TPM error (256) occurred attempting the self test
> > [    0.586623] tpm tpm0: starting up the TPM manually
> >
> > Do we understand why the error appears?
>
>
> Yes, As per kernel code this is an expected error for some emulators.
>
> On swtpm emulator, It returns TPM2_RC_INITIALIZE if emulator is not
> initialized. I searched it in swtpm and it indicated that selftest
> requested before it is initialized. I meant to ask Stefan but busy with
> the review comments.

The swtpm man page mentions some flags we can set. Perhaps they would help?

       --flags [not-need-init]
[,startup-clear|startup-state|startup-deactivated|startup-none]


>
> This function comment in the driver mentioned below indicate that this
> case possible with emulators.
>
> /**
>   * tpm2_startup - turn on the TPM
>   * @chip: TPM chip to use
>   *
>   * Normally the firmware should start the TPM. This function is
> provided as a
>   * workaround if this does not happen. A legal case for this could be for
>   * example when a TPM emulator is used.
>   *
>   * Return: same as tpm_transmit_cmd()
>   */
>
> static int tpm2_startup(struct tpm_chip *chip)
>

> > However on a clean boot into the TPM, the u-boot tpm commands fail:
> >
> > ast# tpm info
> > tpm@2e v2.0: VendorID 0x1014, DeviceID 0x0001, RevisionID 0x01 [closed]
> > ast# tpINTERRUPT>
> > ast# tpm init
> > ast# tpm info
> > tpm@2e v2.0: VendorID 0x1014, DeviceID 0x0001, RevisionID 0x01 [open]
> > ast# tpm pcr_read 0 0x81000000
> > Error: 256
> > ast# md.l 0x81000000 16
> > 81000000: 00000000 00000000 00000000 00000000    ................
> > 81000010: 00000000 00000000 00000000 00000000    ................
> > 81000020: 00000000 00000000 00000000 00000000    ................
> > 81000030: 00000000 00000000 00000000 00000000    ................
> > 81000040: 00000000 00000000 00000000 00000000    ................
> > 81000050: 00000000 00000000                      ........
> >
> > This doesn't need to block merging into qemu, as the model works fine
> > for pcr measurement and accessing under Linux. However it would be
> > good to work though these issues in case there's a modelling
> > discrepancy.
>
>
> Yes, Please provide me details on how to reproduce it. I will take a look.

This is the buildroot tree I've been using for testing:

https://github.com/shenki/buildroot/commits/ast2600-tpm

git clone https://github.com/shenki/buildroot -b ast2600-tpm
cd buildroot
make O=ast2600evb aspeed_ast2600evb_defconfig

I launch it with this qemu commandline:

swtpm socket --tpmstate dir=$XDG_RUNTIME_DIR --ctrl
type=unixio,path=$XDG_RUNTIME_DIR/swtpm-socket --tpm2

qemu-system-arm -M ast2600-evb -nographic -drive
file=ast2600evb/images/flash.img,if=mtd,format=raw -chardev
socket,id=chrtpm,path=$XDG_RUNTIME_DIR/swtpm-socket -tpmdev
emulator,id=tpm0,chardev=chrtpm -device
tpm-tis-i2c,tpmdev=tpm0,bus=aspeed.i2c.bus.12,address=0x2e

If you want to reproduce the u-boot behaviour, press any key to
interrupt the boot.

Booting this way, you can also test the u-boot behaviour. Once you're
in userspace:

# echo tpm_tis_i2c 0x2e > /sys/bus/i2c/devices/i2c-12/new_device
[   13.637081] tpm_tis_i2c 12-002e: 2.0 TPM (device-id 0x1, rev-id 1)
[   13.665239] i2c i2c-12: new_device: Instantiated device tpm_tis_i2c at 0x2e

# cat /sys/class/tpm/tpm0/pcr-sha256/0
FE9A732EAA7842D77DEECFC1DC610EBEA9414BFC39BEEBC8D2F071CF030FA592



reply via email to

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