Great to see this coming along so well. Thanks a lot to Jarkko !
I just wanted to point out a few things I deem important at this point:
- Number of virtual handles:
>From what I see there are currently 14 slots for virtual objects in the RFC
>(if I'm mistaking, please correct me).
I'd advice to
Great to see this coming along so well. Thanks a lot to Jarkko !
I just wanted to point out a few things I deem important at this point:
- Number of virtual handles:
>From what I see there are currently 14 slots for virtual objects in the RFC
>(if I'm mistaking, please correct me).
I'd advice to
>
> From: Jarkko Sakkinen [jarkko.sakki...@linux.intel.com]
> Sent: Tuesday, November 17, 2015 17:27
>
> Support for sealing with a authorization policy.
>
> Two new options for trusted keys:
>
> * 'policydigest=': provide an auth policy digest for
>
> From: Jarkko Sakkinen [jarkko.sakki...@linux.intel.com]
> Sent: Tuesday, November 17, 2015 17:27
>
> Support for sealing with a authorization policy.
>
> Two new options for trusted keys:
>
> * 'policydigest=': provide an auth policy digest for
> > > > > > I looked at Patch 3/4 and it seems you default to -EPERM on
> > > > > > TPM2_Create()-
> > > > > > and TPM2_Load()-failures ?
> > > > > > You might want to test against rc == TPM_RC_OBJECT_MEMORY and
> > > > > > return -EBUSY
> > > > > > in those cases. Would you agree ?
> > > > > >
> > > > I looked at Patch 3/4 and it seems you default to -EPERM on
> > > > TPM2_Create()-
> > > > and TPM2_Load()-failures ?
> > > > You might want to test against rc == TPM_RC_OBJECT_MEMORY and return
> > > > -EBUSY
> > > > in those cases. Would you agree ?
> > > > (P.S. I can cross-post there
> > > > > > I looked at Patch 3/4 and it seems you default to -EPERM on
> > > > > > TPM2_Create()-
> > > > > > and TPM2_Load()-failures ?
> > > > > > You might want to test against rc == TPM_RC_OBJECT_MEMORY and
> > > > > > return -EBUSY
> > > > > > in those cases. Would you agree ?
> > > > > >
> > > > I looked at Patch 3/4 and it seems you default to -EPERM on
> > > > TPM2_Create()-
> > > > and TPM2_Load()-failures ?
> > > > You might want to test against rc == TPM_RC_OBJECT_MEMORY and return
> > > > -EBUSY
> > > > in those cases. Would you agree ?
> > > > (P.S. I can cross-post there
> > I was just trying to point out that the concept is not too difficult, since
> > kernel-space (minimal) resource-manager makes a lot of people go "oh god,
> > never ever, way too big, way too complicated", which IMHO it is not.
> > Until then, I think that the call should just return -EBUSY
> > OK, I guess we got stuck in the follow-up discussions and missed the points.
>
> Yup, don't get me wrong here. I like this discussion and am willing to
> listen to reasonable arguments.
We could not agree more. I'm always up for a good discussion... ;-)
> > My 1st point is:
> >
> > TPM1.2's
> > OK, I guess we got stuck in the follow-up discussions and missed the points.
>
> Yup, don't get me wrong here. I like this discussion and am willing to
> listen to reasonable arguments.
We could not agree more. I'm always up for a good discussion... ;-)
> > My 1st point is:
> >
> > TPM1.2's
> > I was just trying to point out that the concept is not too difficult, since
> > kernel-space (minimal) resource-manager makes a lot of people go "oh god,
> > never ever, way too big, way too complicated", which IMHO it is not.
> > Until then, I think that the call should just return -EBUSY
> > I was just pointing out, that the proposed patch will not fit in with
> > the current approach in TSS2.0, before this user-facing kernel API is
> > set in stone and _corrected_ new syscalls need to be added later.
>
> Why you would want new system calls? Do you know how hard it is to get
>
> > Regarding the in-kernel "minimal resource manager": AFAIK there is
> > already a tpm-mutex inside the kernel. We could use that mutex and
> > then have the algorithm:
> >
> > [SNIP]
>
> I don't care about one purpose hacks. Second, I don't care about pseudo
> code (at least not for "too big
ight ?
I don't know about 2.0 though...
Cheers,
Andreas
From: Jarkko Sakkinen [jarkko.sakki...@linux.intel.com]
Sent: Monday, October 05, 2015 13:56
To: Fuchs, Andreas
Cc: tpmdd-de...@lists.sourceforge.net; linux-kernel@vger.kernel.org; David
Howells; gre...@linuxfoundation.org
rkko.sakki...@linux.intel.com]
Sent: Monday, October 05, 2015 10:37
To: Fuchs, Andreas
Cc: tpmdd-de...@lists.sourceforge.net; linux-kernel@vger.kernel.org; David
Howells; gre...@linuxfoundation.org; open list:KEYS-TRUSTED; open
list:KEYS-TRUSTED; James Morris; David Safford; a...@linux-foundation.org
rkko.sakki...@linux.intel.com]
Sent: Monday, October 05, 2015 10:37
To: Fuchs, Andreas
Cc: tpmdd-de...@lists.sourceforge.net; linux-kernel@vger.kernel.org; David
Howells; gre...@linuxfoundation.org; open list:KEYS-TRUSTED; open
list:KEYS-TRUSTED; James Morris; David Safford; a...@linux-foundation.org
ight ?
I don't know about 2.0 though...
Cheers,
Andreas
From: Jarkko Sakkinen [jarkko.sakki...@linux.intel.com]
Sent: Monday, October 05, 2015 13:56
To: Fuchs, Andreas
Cc: tpmdd-de...@lists.sourceforge.net; linux-kernel@vger.kernel.org; David
Howells; gre...@linuxfoundation.org
> > I was just pointing out, that the proposed patch will not fit in with
> > the current approach in TSS2.0, before this user-facing kernel API is
> > set in stone and _corrected_ new syscalls need to be added later.
>
> Why you would want new system calls? Do you know how hard it is to get
>
> > Regarding the in-kernel "minimal resource manager": AFAIK there is
> > already a tpm-mutex inside the kernel. We could use that mutex and
> > then have the algorithm:
> >
> > [SNIP]
>
> I don't care about one purpose hacks. Second, I don't care about pseudo
> code (at least not for "too big
: seal/unseal with TPM
2.0 chips
On Sat, Oct 03, 2015 at 10:00:59AM +, Fuchs, Andreas wrote:
> Hi Jarkko,
>
> [snip]
>
> diff --git a/security/keys/trusted.h b/security/keys/trusted.h
> index ff001a5..fc32c47 100644
> --- a/security/keys/trusted.h
> +++ b/security/keys/tru
: seal/unseal with TPM
2.0 chips
On Sat, Oct 03, 2015 at 10:00:59AM +, Fuchs, Andreas wrote:
> Hi Jarkko,
>
> [snip]
>
> diff --git a/security/keys/trusted.h b/security/keys/trusted.h
> index ff001a5..fc32c47 100644
> --- a/security/keys/trusted.h
> +++ b/security/keys/tru
Hi Jarkko,
[snip]
diff --git a/security/keys/trusted.h b/security/keys/trusted.h
index ff001a5..fc32c47 100644
--- a/security/keys/trusted.h
+++ b/security/keys/trusted.h
@@ -12,6 +12,13 @@
#define TPM_RETURN_OFFSET 6
#define TPM_DATA_OFFSET10
+/*
Hi Jarkko,
[snip]
diff --git a/security/keys/trusted.h b/security/keys/trusted.h
index ff001a5..fc32c47 100644
--- a/security/keys/trusted.h
+++ b/security/keys/trusted.h
@@ -12,6 +12,13 @@
#define TPM_RETURN_OFFSET 6
#define TPM_DATA_OFFSET10
+/*
Von: Jason Gunthorpe [jguntho...@obsidianresearch.com]
Gesendet: Mittwoch, 9. Oktober 2013 19:38
On Tue, Oct 08, 2013 at 09:15:55AM +0000, Fuchs, Andreas wrote:
> Rather than an ioctl, why not provide a different tpm-device per
> locality. This way, the access to the different localities can be
Gunthorpe [jguntho...@obsidianresearch.com]
Gesendet: Mittwoch, 9. Oktober 2013 19:38
On Tue, Oct 08, 2013 at 09:15:55AM +, Fuchs, Andreas wrote:
Rather than an ioctl, why not provide a different tpm-device per
locality. This way, the access to the different localities can be
restricted via
Some thoughts on those two questions:
1. Yes, userspace could be interested in setting TPM Localities specifically
for uses of PCR_Reset. For example a Browser could be interested in scheduling
Tabs in a PCR. For this it would reset the PCR and replay the old Extends when
switching a tab. Then
Some thoughts on those two questions:
1. Yes, userspace could be interested in setting TPM Localities specifically
for uses of PCR_Reset. For example a Browser could be interested in scheduling
Tabs in a PCR. For this it would reset the PCR and replay the old Extends when
switching a tab. Then
28 matches
Mail list logo
