Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1603429

RE: [tpmdd-devel] [PATCH v3 2/7] tpm: validate TPM 2.0 commands

From <Alexander.Steffen@infineon.com>
Newsgroups linux.kernel
Subject RE: [tpmdd-devel] [PATCH v3 2/7] tpm: validate TPM 2.0 commands
Date 2017-03-17 17:00 +0100
Message-ID <tm2si-kO-33@gated-at.bofh.it> (permalink)
References <tgXjz-35T-3@gated-at.bofh.it> <tgXjA-35T-31@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


> Check for every TPM 2.0 command that the command code is supported and
> the command buffer has at least the length that can contain the header
> and the handle area.

This breaks several use cases for me:

1. I've got a TPM that implements vendor-specific command codes. Those cannot be send to the TPM anymore, but are rejected with EINVAL.

2. When upgrading the firmware on my TPM, it switches to a non-standard communication mode for the upgrade process and does not communicate using TPM2.0 commands during this time. Rejecting non-TPM2.0 commands means upgrading won't be possible anymore.

3. I'd like to use the kernel driver to test my TPM implementation. So for example, I send an invalid command code to the TPM and expect TPM_RC_COMMAND_CODE in response, but now I get EINVAL instead and the TPM never sees the command.

From my point of view, the kernel driver should provide a transparent communication channel to the TPM. Whatever I write to /dev/tpm<n> should arrive at the TPM device, so that the TPM can handle it and return the appropriate response. Otherwise, you'll end up reimplementing all the command handling logic, that is already part of the TPM's job, and as soon as you miss one case and behave differently than the TPM, something relying on this behavior will break.

I see two possible solutions:

1. When the driver does not know a command code, it passes through the command unmodified. This bears the risk of unknown side effects though, so TPM spaces might not be as independent as they should be.

2. Since the command code lookup is only really necessary for TPM spaces, it only gets activated when space != NULL. So the change will not affect /dev/tpm<n>, but only the new /dev/tpmrm<n>. As /dev/tpmrm<n> is not meant to be a transparent interface anyway, rejecting unknown commands is acceptable.

Alexander

Back to linux.kernel | Previous | NextNext in thread | Find similar | Unroll thread


Thread

RE: [tpmdd-devel] [PATCH v3 2/7] tpm: validate TPM 2.0 commands <Alexander.Steffen@infineon.com> - 2017-03-17 17:00 +0100
  Re: [tpmdd-devel] [PATCH v3 2/7] tpm: validate TPM 2.0 commands Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2017-03-17 17:20 +0100
    RE: [tpmdd-devel] [PATCH v3 2/7] tpm: validate TPM 2.0 commands <Peter.Huewe@infineon.com> - 2017-03-17 17:40 +0100
      RE: [tpmdd-devel] [PATCH v3 2/7] tpm: validate TPM 2.0 commands <Alexander.Steffen@infineon.com> - 2017-03-20 11:00 +0100
        Re: [tpmdd-devel] [PATCH v3 2/7] tpm: validate TPM 2.0 commands Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2017-03-20 18:30 +0100
        Re: [tpmdd-devel] [PATCH v3 2/7] tpm: validate TPM 2.0 commands Ken Goldman <kgold@linux.vnet.ibm.com> - 2017-03-20 23:50 +0100
          RE: [tpmdd-devel] [PATCH v3 2/7] tpm: validate TPM 2.0 commands <Alexander.Steffen@infineon.com> - 2017-03-21 17:00 +0100
  Re: [tpmdd-devel] [PATCH v3 2/7] tpm: validate TPM 2.0 commands Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2017-03-17 21:50 +0100
    RE: [tpmdd-devel] [PATCH v3 2/7] tpm: validate TPM 2.0 commands <Alexander.Steffen@infineon.com> - 2017-03-20 11:00 +0100
      Re: [tpmdd-devel] [PATCH v3 2/7] tpm: validate TPM 2.0 commands Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2017-03-27 07:30 +0200

csiph-web