[PATCH v3 0/7] in-kernel resource manager

[PATCH v3 0/7] in-kernel resource manager

[Jarkko Sakkinen]

On Fri, Mar 03, 2017 at 05:19:01PM +0200, Jarkko Sakkinen wrote:
> This patch set adds support for TPM spaces that provide an isolated
> execution context for transient objects and HMAC and policy sessions. A
> space is swapped into TPM volatile memory only when it is used and
> swapped out after the use.
> 
> There's a test script for trying out TPM spaces in
> 
>   git://git.infradead.org/users/jjs/tpm2-scripts.git
> 
> A simple smoke test suite can be run by
> 
>   sudo python -m unittest -v tpm2_smoke.SpaceTest   
> 
> v3:
> * Reverted back to /dev/tpmrm0 that was actually James' original
>   proposal. It's the most pragmatic choice as it cannot be mixed
>   with other TPM 2.0 and kernel idioms easily.
> 
> v2:
> * Substitute virtual handle in ContextSave.
> * Substitute virtual handles in GetCapability.
> * Validate that the real response length and the one reported in the
>   header match in tpm_transmit().
> 
> 
> James Bottomley (3):
>   tpm: split out tpm-dev.c into tpm-dev.c and tpm-common-dev.c
>   tpm: expose spaces via a device link /dev/tpmrm<n>
>   tpm2: add session handle context saving and restoring to the space
>     code
> 
> Jarkko Sakkinen (4):
>   tpm: move length validation to tpm_transmit()
>   tpm: validate TPM 2.0 commands
>   tpm: export tpm2_flush_context_cmd
>   tpm: infrastructure for TPM spaces
> 
>  drivers/char/tpm/Makefile         |   3 +-
>  drivers/char/tpm/tpm-chip.c       |  71 ++++-
>  drivers/char/tpm/tpm-dev-common.c | 148 +++++++++++
>  drivers/char/tpm/tpm-dev.c        | 143 +---------
>  drivers/char/tpm/tpm-dev.h        |  27 ++
>  drivers/char/tpm/tpm-interface.c  | 131 +++++++---
>  drivers/char/tpm/tpm-sysfs.c      |   2 +-
>  drivers/char/tpm/tpm.h            |  49 +++-
>  drivers/char/tpm/tpm2-cmd.c       | 173 +++++++++----
>  drivers/char/tpm/tpm2-space.c     | 532 ++++++++++++++++++++++++++++++++++++++
>  drivers/char/tpm/tpmrm-dev.c      |  65 +++++
>  11 files changed, 1123 insertions(+), 221 deletions(-)
>  create mode 100644 drivers/char/tpm/tpm-dev-common.c
>  create mode 100644 drivers/char/tpm/tpm-dev.h
>  create mode 100644 drivers/char/tpm/tpm2-space.c
>  create mode 100644 drivers/char/tpm/tpmrm-dev.c
> 
> -- 
> 2.9.3
> 

These commits are now in my master and next branches. Tested-by's are
still most welcome!

/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Alexander.Steffen at infineon.com]

> 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
????{.n?+???????+%???????\x17??w??{.n?+????{??????????v?^?)????w*\x1fjg???\x1e???????j??\a??G??????\f???j:+v???w?j?m?????\x1e??\x1e?w?????f???h?????????

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

[Jason Gunthorpe]

On Fri, Mar 17, 2017 at 03:40:15PM +0000, Alexander.Steffen at infineon.com wrote:

> 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.

How non standard? Is the basic header even there? Are the lengths
and status code right?

This might be an argument to add a 'raw' ioctl or something
specifically for this special case.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Peter.Huewe at infineon.com]

> 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.

>How non standard? Is the basic header even there? Are the lengths and status code right?

>This might be an argument to add a 'raw' ioctl or something specifically for this special case.

It follows the regular TPM command syntax and looks something like 1.2 commands.

Peter


--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Alexander.Steffen at infineon.com]

>>> 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.
>>
>> How non standard? Is the basic header even there? Are the lengths and
>> status code right?
>>
>> This might be an argument to add a 'raw' ioctl or something specifically
>> for this special case.
>
> It follows the regular TPM command syntax and looks something like 1.2
> commands.

Yep, so most of it already works with the current implementation.

There are a few special cases that need some thought though. For example, it is possible to use an upgrade to switch the TPM family from 1.2 to 2.0 (or vice versa). In this case it seems useful to let the kernel reinitialize the TPM driver, so it uses the correct timeouts for communication, activates the correct features (resource manager or not?), etc., without needing to reboot the system.

Another problem arises when the upgrade process is interrupted, e.g. because power is lost. Then the TPM is stuck in its non-standard upgrade mode, so the kernel does not recognize it as a valid TPM device and does not export /dev/tpm<n>. But without the device node the upgrader is unable to restart the upgrade process, leaving the TPM forever inaccessible.

I'll try to work on those problems in the coming weeks and provide the fixes. Any input is appreciated.

Alexander
????{.n?+???????+%???????\x17??w??{.n?+????{??????????v?^?)????w*\x1fjg???\x1e???????j??\a??G??????\f???j:+v???w?j?m?????\x1e??\x1e?w?????f???h?????????

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

[Jason Gunthorpe]

On Mon, Mar 20, 2017 at 09:54:41AM +0000, Alexander.Steffen at infineon.com wrote:
> >>> 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.
> >>
> >> How non standard? Is the basic header even there? Are the lengths and
> >> status code right?
> >>
> >> This might be an argument to add a 'raw' ioctl or something specifically
> >> for this special case.
> >
> > It follows the regular TPM command syntax and looks something like 1.2
> > commands.
> 
> Yep, so most of it already works with the current implementation.
> 
> There are a few special cases that need some thought though. For
> example, it is possible to use an upgrade to switch the TPM family
> from 1.2 to 2.0 (or vice versa). In this case it seems useful to let
> the kernel reinitialize the TPM driver, so it uses the correct
> timeouts for communication, activates the correct features (resource
> manager or not?), etc., without needing to reboot the system.

It would be nice to do this via plug/unplug with existing sysfs
machinery.

> Another problem arises when the upgrade process is interrupted,
> e.g. because power is lost. Then the TPM is stuck in its
> non-standard upgrade mode, so the kernel does not recognize it as a
> valid TPM device and does not export /dev/tpm<n>. But without the
> device node the upgrader is unable to restart the upgrade process,
> leaving the TPM forever inaccessible.

I guess you'd have to teach the TPM core about a new chip mode besides
1.2, 2.0 - some kind of 'upgrade' mode.

So the flow would be to send the upgrade command, unplug/replug the
driver to switch to 'upgrade' mode (which could happen if there was a
reboot?) do the upgrade, then unplug/replug to rediscover the 'new'
TPM.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Ken Goldman]

On 3/20/2017 5:54 AM, Alexander.Steffen at infineon.com wrote:
>
> There are a few special cases that need some thought though. For
> example, it is possible to use an upgrade to switch the TPM family
> from 1.2 to 2.0 (or vice versa). In this case it seems useful to let
> the kernel reinitialize the TPM driver, so it uses the correct
> timeouts for communication, activates the correct features (resource
> manager or not?), etc., without needing to reboot the system.

In practice, would a TPM upgrade from TPM 1.2 to TPM 2.0 even occur 
without a reboot?  Is it an important use case?

1 - It would leave the SHA-256 PCRs in the reset state.

2 - It's possible that this upgrade would also require a BIOS upgrade.

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Alexander.Steffen at infineon.com]

> > There are a few special cases that need some thought though. For
> > example, it is possible to use an upgrade to switch the TPM family
> > from 1.2 to 2.0 (or vice versa). In this case it seems useful to let
> > the kernel reinitialize the TPM driver, so it uses the correct
> > timeouts for communication, activates the correct features (resource
> > manager or not?), etc., without needing to reboot the system.
> 
> In practice, would a TPM upgrade from TPM 1.2 to TPM 2.0 even occur
> without a reboot?  Is it an important use case?
> 
> 1 - It would leave the SHA-256 PCRs in the reset state.
> 
> 2 - It's possible that this upgrade would also require a BIOS upgrade.

For a traditional PC and when your goal is platform integrity, a reboot is probably the way to go. But in an embedded environment where there is no BIOS or if you use the TPM more like a smartcard just to store some keys (or generate random numbers), a reboot is unnecessary and it is more comfortable to avoid it.

We probably should inform the kernel before the upgrade anyway, so that it can shut down the TPM gracefully (and maybe switch to the upgrade mode, as Jason suggested). With that infrastructure in place, it does not seem like a lot of effort to also let it switch the TPM back to normal operation mode once the upgrade is complete.

Alexander
????{.n?+???????+%???????\x17??w??{.n?+????{??????????v?^?)????w*\x1fjg???\x1e???????j??\a??G??????\f???j:+v???w?j?m?????\x1e??\x1e?w?????f???h?????????

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

[Jarkko Sakkinen]

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

Thanks again!

/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Alexander.Steffen at infineon.com]

> I think the most straight-forward way to sort this out would be to limit
> validation to the resource manager.

Sounds good to me.

> If I send a fix, would you care to test it?

Sure, will do.

Alexander
????{.n?+???????+%???????\x17??w??{.n?+????{??????????v?^?)????w*\x1fjg???\x1e???????j??\a??G??????\f???j:+v???w?j?m?????\x1e??\x1e?w?????f???h?????????

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

[Jarkko Sakkinen]

On Mon, Mar 20, 2017 at 09:56:17AM +0000, Alexander.Steffen at infineon.com wrote:
> > I think the most straight-forward way to sort this out would be to limit
> > validation to the resource manager.
> 
> Sounds good to me.
> 
> > If I send a fix, would you care to test it?
> 
> Sure, will do.
> 
> Alexander

I sent the patch. Please check it out.

/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[tpmdd-devel] [PATCH v3 4/7] tpm: infrastructure for TPM spaces

[Alexander.Steffen at infineon.com]

> diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-
> interface.c
> index 20b1fe3..db5ffe9 100644
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -376,11 +376,12 @@ static bool tpm_validate_command(struct
> tpm_chip *chip, const u8 *cmd,
>   *     0 when the operation is successful.
>   *     A negative number for system errors (errno).
>   */
> -ssize_t tpm_transmit(struct tpm_chip *chip, const u8 *buf, size_t bufsiz,
> -		     unsigned int flags)
> +ssize_t tpm_transmit(struct tpm_chip *chip, struct tpm_space *space,
> +		     u8 *buf, size_t bufsiz, unsigned int flags)

When adding parameters, please also update the parameter documentation at the top of the function. It is missing for the new parameter "space" here.

Alexander
????{.n?+???????+%???????\x17??w??{.n?+????{??????????v?^?)????w*\x1fjg???\x1e???????j??\a??G??????\f???j:+v???w?j?m?????\x1e??\x1e?w?????f???h?????????

[tpmdd-devel] [PATCH v3 4/7] tpm: infrastructure for TPM spaces

[Jarkko Sakkinen]

On Fri, Mar 17, 2017 at 03:41:38PM +0000, Alexander.Steffen at infineon.com wrote:
> > diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-
> > interface.c
> > index 20b1fe3..db5ffe9 100644
> > --- a/drivers/char/tpm/tpm-interface.c
> > +++ b/drivers/char/tpm/tpm-interface.c
> > @@ -376,11 +376,12 @@ static bool tpm_validate_command(struct
> > tpm_chip *chip, const u8 *cmd,
> >   *     0 when the operation is successful.
> >   *     A negative number for system errors (errno).
> >   */
> > -ssize_t tpm_transmit(struct tpm_chip *chip, const u8 *buf, size_t bufsiz,
> > -		     unsigned int flags)
> > +ssize_t tpm_transmit(struct tpm_chip *chip, struct tpm_space *space,
> > +		     u8 *buf, size_t bufsiz, unsigned int flags)
> 
> When adding parameters, please also update the parameter documentation
> at the top of the function. It is missing for the new parameter
> "space" here.

I missed that. I'll update the commits with the proper documentation.

> Alexander

/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html