On Mon, Mar 20, 2017 at 09:56:17AM +, alexander.stef...@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.
>
>
On Mon, Mar 20, 2017 at 09:56:17AM +, alexander.stef...@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.
>
>
> > 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
> > 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
On 3/20/2017 5:54 AM, alexander.stef...@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
On 3/20/2017 5:54 AM, alexander.stef...@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
On Mon, Mar 20, 2017 at 09:54:41AM +, alexander.stef...@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
> >>>
On Mon, Mar 20, 2017 at 09:54:41AM +, alexander.stef...@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
> >>>
> 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 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
>>> 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
>>> 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
On Fri, Mar 17, 2017 at 03:40:15PM +, alexander.stef...@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:
On Fri, Mar 17, 2017 at 03:40:15PM +, alexander.stef...@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:
> 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
> 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
On Fri, Mar 17, 2017 at 03:40:15PM +, alexander.stef...@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
>
On Fri, Mar 17, 2017 at 03:40:15PM +, alexander.stef...@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
>
> 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
> 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
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.
For ContextSave and FlushContext we mark the body to be part of the
handle area. This gives validation for these commands at zero
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.
For ContextSave and FlushContext we mark the body to be part of the
handle area. This gives validation for these commands at zero
22 matches
Mail list logo
