checking for TPM2.0 support

Is there some easy way to determine whether a /dev/tpm0 device supports TPM 1.2 or 2.0, using either the tpm2.0-tools or some Linux /proc or /sys information?

Or should I simply try to use the device in a non-destructive, read-only way? For example:

# TPM2TOOLS_TCTI_NAME=device tpm2_dump_capability -c commands >/dev/null && echo TPM2.0 || echo no TPM2.0
TPM2.0

@pohly

@pohly you could do something like the following:

if grep -sq 2.0 /sys/class/tpm/tpm0/device/description; then
    echo "TPM 2.0"
else
    echo "TPM 1.2"
fi

Assuming that you already checked that a TPM exist in the system (i.e: /dev/tpm? or /sys/class/tpm).

BTW. you could use the mailing list (https://lists.01.org/mailman/listinfo/tpm2) for these kind of questions. This is really not a tpm2-tools issue.

@martinezjavier

@martinezjavier I decided to file an issue because if it turns out that some work is needed in the tools (like enhancing or fixing something), then there's an issue for it right away. But I agree, this is a borderline case and the mailing list is also a good starting point.

Regarding your proposed solution: I have /sys/class/tpm/tpm0/device/ but no "description" entry in it (kernel 4.9.56), so that check won't work for me. Perhaps that was added later?

@pohly

@pohly yes, I understood your goal. Sorry if I sounded rude, what I meant is that's better to first ask questions in the mailing list and then file issues if those arose so we prevent polluting the issue tracker.

Hmm, it seems the description sysfs entry (actually all the sysfs entries under device) are ACPI specific ones. What kind of TPM2 device do you have?

No problem, it's fine to express the project's preference and guide users in the desired direction :-)

It's QEMU's TPM support, connected to swtpm via a chardev. That support landed in QEMU master recently and we've backported it to QEMU 2.10.0:

-chardev 'socket,id=chrtpm0,... -tpmdev emulator,id=tpm0,chardev=chrtpm0 -device tpm-tis,tpmdev=tpm0

Do you test with QEMU and swtpm? If so, you probably did it via the CUSE support in swtpm and QEMU's tpm pass-through mode. That requires root privileges for starting swtpm. The chardev patches make it possible to setup testing as normal user.

The kernel reports:

# dmesg | grep -i tpm
[    0.000000] ACPI: TPM2 0x000000000ECC1000 000034 (v04 BOCHS  BXPCTPM2 00000001 BXPC 00000001)
[    0.608143] tpm_tis 00:06: 2.0 TPM (device-id 0x1, rev-id 1)
[    0.615138] tpm tpm0: A TPM error (256) occurred continue selftest

The "A TPM error (256) occurred" looks suspicious :-/

@pohly

@pohly ah, great. I was following the swtpm development for QEMU but I didn't know that it already landed in master (last time I saw QEMU only supported the host TPM pass-through backend). So is nice to know that we finally have an emulated solution for QEMU without out-of-tree patches.

I test it with a "real" TPM2, actually an Intel ME based firmware TPM2. I also have access to machines with a hardware TPM2 chip.

I'm not that familiar with QEMU to know if the problem is on how the ACPI information is propagated from the host to the guest and so that's why you don't have that description sysfs entry. IIRC most of the TPM support in QEMU was done for TPM 1.2, so maybe that's part of the issue.

Regarding your kernel error, that seems to be from the tpm_transmit_cmd function:

ssize_t tpm_transmit_cmd(struct tpm_chip *chip, const void *cmd,
			 int len, unsigned int flags, const char *desc)
{
	const struct tpm_output_header *header;
	int err;

	len = tpm_transmit(chip, (const u8 *)cmd, len, flags);
	if (len <  0)
		return len;
	else if (len < TPM_HEADER_SIZE)
		return -EFAULT;

	header = cmd;

	err = be32_to_cpu(header->return_code);
	if (err != 0 && desc)
		dev_err(&chip->dev, "A TPM error (%d) occurred %s\n", err,
			desc);

	return err;
}

So is the transmission seems to be successful (otherwise tpm_transmit would had failed) but the TPM is returning an error...

The error seems to be TPM_RC_INITIALIZE which by looking at the error codes in https://github.com/01org/tpm2-tss/blob/master/include/sapi/tss2_tpm2_types.h:

#define	RC_VER1	(0x100 )	 /* set for all format 0 response codes  */
#define	TPM_RC_INITIALIZE	(RC_VER1 + 0x000 )	 /* TPM not initialized by TPM2_Startup or already initialized   */

Is there some easy way to determine whether a /dev/tpm0 device supports TPM 1.2 or 2.0, using either the tpm2.0-tools or some Linux /proc or /sys information?

You could check for the existence of /sys/class/tpm/tpm0/caps, which will currently only exist for TPM 1.2. I am not sure whether there is any intention to add this file for TPM 2.0 in the future, but as long as the format is kept it also specifies the TPM version (in my case it contains a line "TCG version: 1.2").

The "A TPM error (256) occurred" looks suspicious :-/

Yeah, those messages are confusing if you are not used to them, maybe I get to clean that up at some point.

In this case, the kernel assumes that the platform has started the TPM, but as RC_INITIALIZE shows this is not the case. So the kernel will happily start the TPM and retry the action, but you do not get any success message for that. But you should get your /dev/tpm* if everything works.

I think I'll stick with just calling tpm2_dump_capability. That seems more reliable than relying on potentially changing kernel interfaces.

If you think that this is something that tpm2.0-tools should support directly (tpm2_is_tpm2? Probably needs a better name), then feel free to use this issue as enhancement request for that. If not, let's close it.

If you think that this is something that tpm2.0-tools should support directly (tpm2_is_tpm2? Probably needs a better name), then feel free to use this issue as enhancement request for that.

As the name implies, the tools are meant to work only with a TPM 2.0, not a TPM 1.2, so in my opinion this might not be necessary. But we should ensure that the tools fail nicely when accidentially used with a TPM 1.2. Has anybody ever checked that?

I checked that tpm2_dump_capability fails when invoked with swtpm running in TPM 1.2 mode. I don't remember the exact error, but it wasn't particularly obvious that it was because of the wrong standard.

The goal for me was to detect TPM 1.2 vs. 2.0 reliably in a script. Detecting that by inspecting the error output of the tools doesn't work well. Special return codes could be defined perhaps, but does that make sense for all commands? I'm not sure, which is why I brought up writing a dedicated tool.

I don't remember the exact error, but it wasn't particularly obvious that it was because of the wrong standard.

That definitely needs to be fixed then. And maybe whatever fix gets implemented will be sufficient for you to distinguish a TPM 1.2 from a TPM 2.0 in your scripts (a nice error message perhaps?).

That would work, but then the exact error message would have to be well-defined and guaranteed to be the same regardless of any future localization of the tools.

I would prefer having well-defined return codes:

1 = general error
2 = tried to use tool against TPM 1.2

refkit: support whole-disk encryption with TPM 2.0

Navigation Menu

Repository navigation

checking for TPM2.0 support #604

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

checking for TPM2.0 support #604

Description

Activity

martinezjavier commented on Nov 8, 2017

martinezjavier commented on Nov 8, 2017

pohly commented on Nov 8, 2017

martinezjavier commented on Nov 8, 2017

pohly commented on Nov 8, 2017

martinezjavier commented on Nov 8, 2017

webmeister commented on Nov 8, 2017

pohly commented on Nov 8, 2017

webmeister commented on Nov 8, 2017

pohly commented on Nov 8, 2017

webmeister commented on Nov 9, 2017

pohly commented on Nov 9, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions