archive mirror
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko.sakkinen-VuQAYsv1563Yd54FQh9/>
To: Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/
Cc: James.Bottomley-d9PhHud1JfjCXq6kfMZ53/,,,,
Subject: Re: [PATCH v3 2/7] tpm: validate TPM 2.0 commands
Date: Fri, 17 Mar 2017 22:42:43 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <22e8fa0caf8b4386a12cd93ee7170ed5-nFblLGNE8XKJSz+rYg/>

On Fri, Mar 17, 2017 at 03:40:15PM +0000, Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/ wrote:
> > 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:

Thank you for reporting these. This is really great feedback to get.

> 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

I think the most straight-forward way to sort this out would be to limit
validation to the resource manager. If I send a fix, would you care to
test it? If your issues get sorted, I'll squash it to the existing

Thanks again!


Check out the vibrant tech community on one of the world's most
engaging tech sites,!

  parent reply	other threads:[~2017-03-17 20:42 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-03 15:19 [PATCH v3 0/7] in-kernel resource manager Jarkko Sakkinen
     [not found] ` <20170303151912.14752-1-jarkko.sakkinen-VuQAYsv1563Yd54FQh9/>
2017-03-03 15:19   ` [PATCH v3 1/7] tpm: move length validation to tpm_transmit() Jarkko Sakkinen
2017-03-03 15:19   ` [PATCH v3 2/7] tpm: validate TPM 2.0 commands Jarkko Sakkinen
     [not found]     ` <20170303151912.14752-3-jarkko.sakkinen-VuQAYsv1563Yd54FQh9/>
2017-03-17 15:40       ` Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w
2017-03-17 16:16         ` [tpmdd-devel] " Jason Gunthorpe
     [not found]           ` <20170317161614.GA28082-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/>
2017-03-17 16:35             ` Peter.Huewe-d0qZbvYSIPpWk0Htik3J/w
2017-03-20  9:54               ` [tpmdd-devel] " Alexander.Steffen
     [not found]                 ` <12e63cdba1e34cac9b82e4bff9621ae6-nFblLGNE8XKJSz+rYg/>
2017-03-20 17:23                   ` Jason Gunthorpe
2017-03-20 19:42                   ` Ken Goldman
     [not found]                     ` <>
2017-03-21 15:44                       ` Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w
     [not found]         ` <22e8fa0caf8b4386a12cd93ee7170ed5-nFblLGNE8XKJSz+rYg/>
2017-03-17 20:42           ` Jarkko Sakkinen [this message]
     [not found]             ` <>
2017-03-20  9:56               ` Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w
     [not found]                 ` <93c74fb96fe04433ac9c910204539d84-nFblLGNE8XKJSz+rYg/>
2017-03-27  5:25                   ` Jarkko Sakkinen
2017-03-03 15:19   ` [PATCH v3 3/7] tpm: export tpm2_flush_context_cmd Jarkko Sakkinen
2017-03-03 15:19   ` [PATCH v3 4/7] tpm: infrastructure for TPM spaces Jarkko Sakkinen
     [not found]     ` <20170303151912.14752-5-jarkko.sakkinen-VuQAYsv1563Yd54FQh9/>
2017-03-17 15:41       ` Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/w
     [not found]         ` <1aa1c9d32fd446f69551a36c37f0ed16-nFblLGNE8XKJSz+rYg/>
2017-03-17 20:44           ` Jarkko Sakkinen
2017-03-03 15:19   ` [PATCH v3 5/7] tpm: split out tpm-dev.c into tpm-dev.c and tpm-common-dev.c Jarkko Sakkinen
2017-03-03 15:19   ` [PATCH v3 6/7] tpm: expose spaces via a device link /dev/tpmrm<n> Jarkko Sakkinen
2017-03-03 15:19   ` [PATCH v3 7/7] tpm2: add session handle context saving and restoring to the space code Jarkko Sakkinen
2017-03-06 21:07   ` [PATCH v3 0/7] in-kernel resource manager Jarkko Sakkinen
2017-03-11  8:55 ` Jarkko Sakkinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \
    --to=jarkko.sakkinen-vuqaysv1563yd54fqh9/ \
    --cc=Alexander.Steffen-d0qZbvYSIPpWk0Htik3J/ \
    --cc=James.Bottomley-d9PhHud1JfjCXq6kfMZ53/ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).