On 11/26/2017 03:21 PM, Jarkko Sakkinen wrote:
> On Wed, Nov 22, 2017 at 08:25:29PM +0100, Javier Martinez Canillas wrote:
>> That was my interpretation as well and what I was arguing about. I'm glad to
>> know that you also think the same.
>
> It could be that this rationale has been your
On 11/26/2017 03:21 PM, Jarkko Sakkinen wrote:
> On Wed, Nov 22, 2017 at 08:25:29PM +0100, Javier Martinez Canillas wrote:
>> That was my interpretation as well and what I was arguing about. I'm glad to
>> know that you also think the same.
>
> It could be that this rationale has been your
On 11/26/2017 03:18 PM, Jarkko Sakkinen wrote:
> On Wed, Nov 22, 2017 at 09:16:25AM -0800, flihp wrote:
>> The intent of this "mostly transparent" stuff is to convey that the RM
>> should be as transparent as possible while acknowledging that there are
>> some cases where it's not / can't be. I
On 11/26/2017 03:18 PM, Jarkko Sakkinen wrote:
> On Wed, Nov 22, 2017 at 09:16:25AM -0800, flihp wrote:
>> The intent of this "mostly transparent" stuff is to convey that the RM
>> should be as transparent as possible while acknowledging that there are
>> some cases where it's not / can't be. I
On 11/26/2017 03:12 PM, Jarkko Sakkinen wrote:
> On Wed, Nov 22, 2017 at 10:26:24AM +0100, Javier Martinez Canillas wrote:
>> On 11/21/2017 09:29 PM, Roberts, William C wrote:
>>
>> [snip]
>>
>
> Do you agree with Jason's suggestion to send a synthesized TPM command
> in the that the
On 11/26/2017 03:12 PM, Jarkko Sakkinen wrote:
> On Wed, Nov 22, 2017 at 10:26:24AM +0100, Javier Martinez Canillas wrote:
>> On 11/21/2017 09:29 PM, Roberts, William C wrote:
>>
>> [snip]
>>
>
> Do you agree with Jason's suggestion to send a synthesized TPM command
> in the that the
On Wed, Nov 22, 2017 at 08:25:29PM +0100, Javier Martinez Canillas wrote:
> That was my interpretation as well and what I was arguing about. I'm glad to
> know that you also think the same.
It could be that this rationale has been your earlier emails but
I just haven't recognized it :-) I think
On Wed, Nov 22, 2017 at 08:25:29PM +0100, Javier Martinez Canillas wrote:
> That was my interpretation as well and what I was arguing about. I'm glad to
> know that you also think the same.
It could be that this rationale has been your earlier emails but
I just haven't recognized it :-) I think
On Wed, Nov 22, 2017 at 09:16:25AM -0800, flihp wrote:
> The intent of this "mostly transparent" stuff is to convey that the RM
> should be as transparent as possible while acknowledging that there are
> some cases where it's not / can't be. I can't say why the original
> author phrased it in this
On Wed, Nov 22, 2017 at 09:16:25AM -0800, flihp wrote:
> The intent of this "mostly transparent" stuff is to convey that the RM
> should be as transparent as possible while acknowledging that there are
> some cases where it's not / can't be. I can't say why the original
> author phrased it in this
On Tue, Nov 21, 2017 at 01:49:23PM +0100, Javier Martinez Canillas wrote:
> Ok. Thanks a lot for your feedback. I already had that patch but didn't want
> to post it before knowing your opinion, I'll drop it now.
>
> Philip,
>
> I think this means that we can now fix this in user-space then?
On Tue, Nov 21, 2017 at 01:49:23PM +0100, Javier Martinez Canillas wrote:
> Ok. Thanks a lot for your feedback. I already had that patch but didn't want
> to post it before knowing your opinion, I'll drop it now.
>
> Philip,
>
> I think this means that we can now fix this in user-space then?
On Wed, Nov 22, 2017 at 10:26:24AM +0100, Javier Martinez Canillas wrote:
> On 11/21/2017 09:29 PM, Roberts, William C wrote:
>
> [snip]
>
> >>>
> >>> Do you agree with Jason's suggestion to send a synthesized TPM command
> >>> in the that the command isn't supported?
> >>
> >> Nope.
> >
> > We
On Wed, Nov 22, 2017 at 10:26:24AM +0100, Javier Martinez Canillas wrote:
> On 11/21/2017 09:29 PM, Roberts, William C wrote:
>
> [snip]
>
> >>>
> >>> Do you agree with Jason's suggestion to send a synthesized TPM command
> >>> in the that the command isn't supported?
> >>
> >> Nope.
> >
> > We
On Tue, Nov 21, 2017 at 08:29:07PM +, Roberts, William C wrote:
> > TPM specification is not a formal specification AFAIK.
>
> The published parts are, granted many things are changing.
Yes, how it defines the protocol, you are correct. It does not have a
formal definition of RM behavior or
On Tue, Nov 21, 2017 at 08:29:07PM +, Roberts, William C wrote:
> > TPM specification is not a formal specification AFAIK.
>
> The published parts are, granted many things are changing.
Yes, how it defines the protocol, you are correct. It does not have a
formal definition of RM behavior or
On Wed, Nov 22, 2017 at 09:16:25AM -0800, flihp wrote:
> We can work around quirks in the kernel RM in user space if we must
> (short term?) but I'm hesitant to do so in this case. Would feel better
> about a short term work-around knowing it's only going to be short term.
Pedantically, the
On Wed, Nov 22, 2017 at 09:16:25AM -0800, flihp wrote:
> We can work around quirks in the kernel RM in user space if we must
> (short term?) but I'm hesitant to do so in this case. Would feel better
> about a short term work-around knowing it's only going to be short term.
Pedantically, the
Hello Philip,
On 11/22/2017 06:16 PM, flihp wrote:
> Apologies for the slow response. I didn't get switched over from
> tpmdd-devel to linux-integrity till just now.
>
No worries, thanks a lot for your feedback.
>> On 11/21/2017 01:30 PM, Jarkko Sakkinen wrote:
>>> On Tue, Nov 21, 2017 at
Hello Philip,
On 11/22/2017 06:16 PM, flihp wrote:
> Apologies for the slow response. I didn't get switched over from
> tpmdd-devel to linux-integrity till just now.
>
No worries, thanks a lot for your feedback.
>> On 11/21/2017 01:30 PM, Jarkko Sakkinen wrote:
>>> On Tue, Nov 21, 2017 at
Apologies for the slow response. I didn't get switched over from
tpmdd-devel to linux-integrity till just now.
> On 11/21/2017 01:30 PM, Jarkko Sakkinen wrote:
>> On Tue, Nov 21, 2017 at 10:07:34AM +0100, Javier Martinez Canillas
>> wrote:
>>> As mentioned, I think this should be documented. I
Apologies for the slow response. I didn't get switched over from
tpmdd-devel to linux-integrity till just now.
> On 11/21/2017 01:30 PM, Jarkko Sakkinen wrote:
>> On Tue, Nov 21, 2017 at 10:07:34AM +0100, Javier Martinez Canillas
>> wrote:
>>> As mentioned, I think this should be documented. I
On 11/21/2017 09:29 PM, Roberts, William C wrote:
[snip]
>>>
>>> Do you agree with Jason's suggestion to send a synthesized TPM command
>>> in the that the command isn't supported?
>>
>> Nope.
>
> We should update the elf loader to make sure that ELF files don't contain
> Incorrect
On 11/21/2017 09:29 PM, Roberts, William C wrote:
[snip]
>>>
>>> Do you agree with Jason's suggestion to send a synthesized TPM command
>>> in the that the command isn't supported?
>>
>> Nope.
>
> We should update the elf loader to make sure that ELF files don't contain
> Incorrect
a,
> Philip B <philip.b.tri...@intel.com>; Jason Gunthorpe
> <jguntho...@obsidianresearch.com>; linux-integr...@vger.kernel.org; Roberts,
> William C <william.c.robe...@intel.com>
> Subject: Re: [RFC PATCH] tpm: don't return -EINVAL if TPM command validation
> fails
&g
gr...@vger.kernel.org; Roberts,
> William C
> Subject: Re: [RFC PATCH] tpm: don't return -EINVAL if TPM command validation
> fails
>
> On Tue, Nov 21, 2017 at 10:07:34AM +0100, Javier Martinez Canillas wrote:
> > As mentioned, I think this should be documented. I guess most p
On 11/21/2017 01:30 PM, Jarkko Sakkinen wrote:
> On Tue, Nov 21, 2017 at 10:07:34AM +0100, Javier Martinez Canillas wrote:
>> As mentioned, I think this should be documented. I guess most people
>> would see the in-kernel resource manager as a virtualized TPM, since
>> the "TSS TAB and Resource
On 11/21/2017 01:30 PM, Jarkko Sakkinen wrote:
> On Tue, Nov 21, 2017 at 10:07:34AM +0100, Javier Martinez Canillas wrote:
>> As mentioned, I think this should be documented. I guess most people
>> would see the in-kernel resource manager as a virtualized TPM, since
>> the "TSS TAB and Resource
On Tue, Nov 21, 2017 at 10:07:34AM +0100, Javier Martinez Canillas wrote:
> As mentioned, I think this should be documented. I guess most people
> would see the in-kernel resource manager as a virtualized TPM, since
> the "TSS TAB and Resource Manager Specification" [0] explains the RM
> making an
On Tue, Nov 21, 2017 at 10:07:34AM +0100, Javier Martinez Canillas wrote:
> As mentioned, I think this should be documented. I guess most people
> would see the in-kernel resource manager as a virtualized TPM, since
> the "TSS TAB and Resource Manager Specification" [0] explains the RM
> making an
On 11/21/2017 10:07 AM, Javier Martinez Canillas wrote:
> On 11/21/2017 12:15 AM, Jarkko Sakkinen wrote:
>
>> matters less than breaking the sandbox.
>>
>
> Yes, sorry for that. It wasn't clear to me that there was a sandbox and my
> lack of familiarity with the code was the reason why I posted
On 11/21/2017 10:07 AM, Javier Martinez Canillas wrote:
> On 11/21/2017 12:15 AM, Jarkko Sakkinen wrote:
>
>> matters less than breaking the sandbox.
>>
>
> Yes, sorry for that. It wasn't clear to me that there was a sandbox and my
> lack of familiarity with the code was the reason why I posted
Hello Jarkko,
On 11/21/2017 12:15 AM, Jarkko Sakkinen wrote:
> On Fri, Nov 17, 2017 at 11:07:24AM +0100, Javier Martinez Canillas wrote:
>> According to the TPM Library Specification, a TPM device must do a command
>> header validation before processing and return a TPM_RC_COMMAND_CODE code
>> if
Hello Jarkko,
On 11/21/2017 12:15 AM, Jarkko Sakkinen wrote:
> On Fri, Nov 17, 2017 at 11:07:24AM +0100, Javier Martinez Canillas wrote:
>> According to the TPM Library Specification, a TPM device must do a command
>> header validation before processing and return a TPM_RC_COMMAND_CODE code
>> if
On Fri, Nov 17, 2017 at 11:07:24AM +0100, Javier Martinez Canillas wrote:
> According to the TPM Library Specification, a TPM device must do a command
> header validation before processing and return a TPM_RC_COMMAND_CODE code
> if the command is not implemented and the TPM_RC_COMMAND_SIZE code if
On Fri, Nov 17, 2017 at 11:07:24AM +0100, Javier Martinez Canillas wrote:
> According to the TPM Library Specification, a TPM device must do a command
> header validation before processing and return a TPM_RC_COMMAND_CODE code
> if the command is not implemented and the TPM_RC_COMMAND_SIZE code if
On Mon, Nov 20, 2017 at 10:26:01AM +0100, Javier Martinez Canillas wrote:
> I thought the TPM spaces was about exposing a virtualized TPM that didn't
> have the limitation of only allowing to store a small set of transient
> objects (so user-space didn't have to deal with the handles flushing and
On Mon, Nov 20, 2017 at 10:26:01AM +0100, Javier Martinez Canillas wrote:
> I thought the TPM spaces was about exposing a virtualized TPM that didn't
> have the limitation of only allowing to store a small set of transient
> objects (so user-space didn't have to deal with the handles flushing and
On Mon, Nov 20, 2017 at 04:14:41PM +, Roberts, William C wrote:
> That's policy, and shouldn't be hardcoded in the kernel. Let the DAC
> permission model And LSMs sort that out.
Of course this is what was done, there are two cdevs, one with full
access to the TPM and one that runs through
On Mon, Nov 20, 2017 at 04:14:41PM +, Roberts, William C wrote:
> That's policy, and shouldn't be hardcoded in the kernel. Let the DAC
> permission model And LSMs sort that out.
Of course this is what was done, there are two cdevs, one with full
access to the TPM and one that runs through
Jarkko Sakkinen <jarkko.sakki...@linux.intel.com>;
> Peter Huewe <peterhu...@gmx.de>; Tricca, Philip B
> <philip.b.tri...@intel.com>; linux-integr...@vger.kernel.org
> Subject: Re: [RFC PATCH] tpm: don't return -EINVAL if TPM command validation
> fails
>
> On 11/19/20
ip B
> ; linux-integr...@vger.kernel.org
> Subject: Re: [RFC PATCH] tpm: don't return -EINVAL if TPM command validation
> fails
>
> On 11/19/2017 04:27 PM, Jason Gunthorpe wrote:
> > On Sat, Nov 18, 2017 at 01:53:49AM +0100, Javier Martinez Canillas wrote:
> >
> >> What I fa
On 11/19/2017 04:27 PM, Jason Gunthorpe wrote:
> On Sat, Nov 18, 2017 at 01:53:49AM +0100, Javier Martinez Canillas wrote:
>
>> What I fail to understand is why that's not a problem when the TPM spaces
>> infrastructure isn't used, tpm_validate_command() function just returns
>> true if space is
On 11/19/2017 04:27 PM, Jason Gunthorpe wrote:
> On Sat, Nov 18, 2017 at 01:53:49AM +0100, Javier Martinez Canillas wrote:
>
>> What I fail to understand is why that's not a problem when the TPM spaces
>> infrastructure isn't used, tpm_validate_command() function just returns
>> true if space is
On Sat, Nov 18, 2017 at 01:53:49AM +0100, Javier Martinez Canillas wrote:
> What I fail to understand is why that's not a problem when the TPM spaces
> infrastructure isn't used, tpm_validate_command() function just returns
> true if space is NULL. So when sending command to /dev/tpm0 directly, a
On Sat, Nov 18, 2017 at 01:53:49AM +0100, Javier Martinez Canillas wrote:
> What I fail to understand is why that's not a problem when the TPM spaces
> infrastructure isn't used, tpm_validate_command() function just returns
> true if space is NULL. So when sending command to /dev/tpm0 directly, a
On 11/18/2017 12:55 AM, Jason Gunthorpe wrote:
> On Fri, Nov 17, 2017 at 07:14:21PM +, Roberts, William C wrote:
>
>> I don't know why spaces would filter by command code. But it does
>> seem to be loaded By getting the command codes from the tpm in
>> tpm2_get_tpm_pt().
>
> Ah, I forgot. So
On 11/18/2017 12:55 AM, Jason Gunthorpe wrote:
> On Fri, Nov 17, 2017 at 07:14:21PM +, Roberts, William C wrote:
>
>> I don't know why spaces would filter by command code. But it does
>> seem to be loaded By getting the command codes from the tpm in
>> tpm2_get_tpm_pt().
>
> Ah, I forgot. So
On Fri, Nov 17, 2017 at 07:14:21PM +, Roberts, William C wrote:
> I don't know why spaces would filter by command code. But it does
> seem to be loaded By getting the command codes from the tpm in
> tpm2_get_tpm_pt().
Ah, I forgot. So my remark is not quite right :\
> I don't think that
On Fri, Nov 17, 2017 at 07:14:21PM +, Roberts, William C wrote:
> I don't know why spaces would filter by command code. But it does
> seem to be loaded By getting the command codes from the tpm in
> tpm2_get_tpm_pt().
Ah, I forgot. So my remark is not quite right :\
> I don't think that
Peter Huewe <peterhu...@gmx.de>;
> Tricca, Philip B <philip.b.tri...@intel.com>; linux-integr...@vger.kernel.org;
> Roberts, William C <william.c.robe...@intel.com>
> Subject: Re: [RFC PATCH] tpm: don't return -EINVAL if TPM command validation
> fails
>
> On 11/17/20
kernel.org;
> Roberts, William C
> Subject: Re: [RFC PATCH] tpm: don't return -EINVAL if TPM command validation
> fails
>
> On 11/17/2017 07:17 PM, Jason Gunthorpe wrote:
> > On Fri, Nov 17, 2017 at 07:10:09PM +0100, Javier Martinez Canillas wrote:
> >
> >> Rig
On 11/17/2017 07:17 PM, Jason Gunthorpe wrote:
> On Fri, Nov 17, 2017 at 07:10:09PM +0100, Javier Martinez Canillas wrote:
>
>> Right, that's what I understood indeed but wanted to be sure. The problem
>> with
>> that approach is that would not scale.
>>
>> Since this particular TPM2 doesn't
On 11/17/2017 07:17 PM, Jason Gunthorpe wrote:
> On Fri, Nov 17, 2017 at 07:10:09PM +0100, Javier Martinez Canillas wrote:
>
>> Right, that's what I understood indeed but wanted to be sure. The problem
>> with
>> that approach is that would not scale.
>>
>> Since this particular TPM2 doesn't
On Fri, Nov 17, 2017 at 07:10:09PM +0100, Javier Martinez Canillas wrote:
> Right, that's what I understood indeed but wanted to be sure. The problem with
> that approach is that would not scale.
>
> Since this particular TPM2 doesn't have support for the TPM2_EncryptDecrypt2
> command, but some
On Fri, Nov 17, 2017 at 07:10:09PM +0100, Javier Martinez Canillas wrote:
> Right, that's what I understood indeed but wanted to be sure. The problem with
> that approach is that would not scale.
>
> Since this particular TPM2 doesn't have support for the TPM2_EncryptDecrypt2
> command, but some
On 11/17/2017 06:58 PM, Jason Gunthorpe wrote:
> On Fri, Nov 17, 2017 at 06:56:09PM +0100, Javier Martinez Canillas wrote:
>
>> Yes, the problem with that is user-space not having enough information about
>> what went wrong. Right now the TCTI layer just reports TSS2_BASE_RC_IO_ERROR
>> in this
On 11/17/2017 06:58 PM, Jason Gunthorpe wrote:
> On Fri, Nov 17, 2017 at 06:56:09PM +0100, Javier Martinez Canillas wrote:
>
>> Yes, the problem with that is user-space not having enough information about
>> what went wrong. Right now the TCTI layer just reports TSS2_BASE_RC_IO_ERROR
>> in this
On Fri, Nov 17, 2017 at 06:56:09PM +0100, Javier Martinez Canillas wrote:
> Yes, the problem with that is user-space not having enough information about
> what went wrong. Right now the TCTI layer just reports TSS2_BASE_RC_IO_ERROR
> in this case and can't be blamed.
Well, if you care about the
On Fri, Nov 17, 2017 at 06:56:09PM +0100, Javier Martinez Canillas wrote:
> Yes, the problem with that is user-space not having enough information about
> what went wrong. Right now the TCTI layer just reports TSS2_BASE_RC_IO_ERROR
> in this case and can't be blamed.
Well, if you care about the
Hello Jason,
Thanks a lot for your feedback.
On 11/17/2017 05:57 PM, Jason Gunthorpe wrote:
> On Fri, Nov 17, 2017 at 11:07:24AM +0100, Javier Martinez Canillas wrote:
>
>> This patch is an RFC because I'm not sure if this is the correct way to fix
>> this
>> issue. I'm not that familiar with
Hello Jason,
Thanks a lot for your feedback.
On 11/17/2017 05:57 PM, Jason Gunthorpe wrote:
> On Fri, Nov 17, 2017 at 11:07:24AM +0100, Javier Martinez Canillas wrote:
>
>> This patch is an RFC because I'm not sure if this is the correct way to fix
>> this
>> issue. I'm not that familiar with
On Fri, Nov 17, 2017 at 11:07:24AM +0100, Javier Martinez Canillas wrote:
> This patch is an RFC because I'm not sure if this is the correct way to fix
> this
> issue. I'm not that familiar with the TPM driver so may had missed some
> details.
>
> And example of user-space getting confused by
On Fri, Nov 17, 2017 at 11:07:24AM +0100, Javier Martinez Canillas wrote:
> This patch is an RFC because I'm not sure if this is the correct way to fix
> this
> issue. I'm not that familiar with the TPM driver so may had missed some
> details.
>
> And example of user-space getting confused by
According to the TPM Library Specification, a TPM device must do a command
header validation before processing and return a TPM_RC_COMMAND_CODE code
if the command is not implemented and the TPM_RC_COMMAND_SIZE code if the
command buffer size is not correct.
So user-space will expect to handle
According to the TPM Library Specification, a TPM device must do a command
header validation before processing and return a TPM_RC_COMMAND_CODE code
if the command is not implemented and the TPM_RC_COMMAND_SIZE code if the
command buffer size is not correct.
So user-space will expect to handle
66 matches
Mail list logo
