On Wed, 2015-10-07 at 10:32 +, Fuchs, Andreas wrote:
> > > > > > > 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
> > > > > > 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 ?
> > > > > >
On Wed, Oct 07, 2015 at 10:04:40AM +, Fuchs, Andreas wrote:
> > > > > 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
> >
> > > > 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 ?
> > > > > >
On Wed, 2015-10-07 at 10:32 +, Fuchs, Andreas wrote:
> > > > > > > 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
> > > > 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
On Wed, Oct 07, 2015 at 10:04:40AM +, Fuchs, Andreas wrote:
> > > > > 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
> >
On Tue, Oct 06, 2015 at 01:16:02PM +, Fuchs, Andreas wrote:
> > > 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
> > 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
On Tue, Oct 06, 2015 at 06:22:29AM +, Fuchs, Andreas wrote:
> > > 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
> > 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
On Tue, Oct 06, 2015 at 01:16:02PM +, Fuchs, Andreas wrote:
> > > 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
> > 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
On Tue, Oct 06, 2015 at 06:22:29AM +, Fuchs, Andreas wrote:
> > > 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
> > 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
...@joshtripplet.org; Maliszewski, Richard L
; Wiseman, Monty ;
Arthur, Will C
Subject: Re: [tpmdd-devel] [PATCH 4/4] keys, trusted: seal/unseal with TPM 2.0
chips
On Mon, Oct 05, 2015 at 02:13:15PM +, Fuchs, Andreas wrote:
> > > I was just pointing out, that the proposed patch wil
On Mon, Oct 05, 2015 at 02:13:15PM +, Fuchs, Andreas wrote:
> > > 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.
> >
> >
> > 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
>
On Mon, Oct 05, 2015 at 01:36:18PM +, Fuchs, Andreas wrote:
> > It's still unnecessary functionality and increases the kernel image size
> > and every hack requires maintenance. It would probably end up needing
> > compilation flag as there exists efforts like:
> >
> >
> > 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
I don't mean to be impolite but could line up your replies properly
and avoid top-posting. I'd recommend 72 chars per line. Thanks.
On Mon, Oct 05, 2015 at 12:20:47PM +, Fuchs, Andreas wrote:
> That's why I propose to give the context-save-blob into the kernel. It
> does not require any
; open list:KEYS-TRUSTED; open
list:KEYS-TRUSTED; James Morris; David Safford; a...@linux-foundation.org;
Serge E. Hallyn
Subject: Re: [tpmdd-devel] [PATCH 4/4] keys,trusted: seal/unseal with TPM
2.0 chips
On Mon, Oct 05, 2015 at 09:00:48AM +, Fuchs, Andreas wrote:
> Hi Jarkko,
>
&g
o: 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;
> Serge E. Hallyn
> Subject: Re: [tpmdd-dev
;
Serge E. Hallyn
Subject: Re: [tpmdd-devel] [PATCH 4/4] keys, trusted: seal/unseal with TPM
2.0 chips
On Sun, Oct 04, 2015 at 06:57:42PM +, Fuchs, Andreas wrote:
> Hi Jarkko,
>
> thanks for the clearification...
>
> However, I'd recommend against doing so.
>
> Furt
-foundation.org;
> Serge E. Hallyn
> Subject: Re: [tpmdd-devel] [PATCH 4/4] keys,trusted: 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/
-foundation.org;
> Serge E. Hallyn
> Subject: Re: [tpmdd-devel] [PATCH 4/4] keys,trusted: 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/
;
Serge E. Hallyn
Subject: Re: [tpmdd-devel] [PATCH 4/4] keys, trusted: seal/unseal with TPM
2.0 chips
On Sun, Oct 04, 2015 at 06:57:42PM +, Fuchs, Andreas wrote:
> Hi Jarkko,
>
> thanks for the clearification...
>
> However, I'd recommend against doing so.
>
> Furt
o: 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;
> Serge E. Hallyn
> Subject: Re: [tpmdd-dev
I don't mean to be impolite but could line up your replies properly
and avoid top-posting. I'd recommend 72 chars per line. Thanks.
On Mon, Oct 05, 2015 at 12:20:47PM +, Fuchs, Andreas wrote:
> That's why I propose to give the context-save-blob into the kernel. It
> does not require any
; open list:KEYS-TRUSTED; open
list:KEYS-TRUSTED; James Morris; David Safford; a...@linux-foundation.org;
Serge E. Hallyn
Subject: Re: [tpmdd-devel] [PATCH 4/4] keys,trusted: seal/unseal with TPM
2.0 chips
On Mon, Oct 05, 2015 at 09:00:48AM +, Fuchs, Andreas wrote:
> Hi Jarkko,
>
&g
com>; Wiseman, Monty <monty.wise...@intel.com>;
Arthur, Will C <will.c.art...@intel.com>
Subject: Re: [tpmdd-devel] [PATCH 4/4] keys, trusted: seal/unseal with TPM 2.0
chips
On Mon, Oct 05, 2015 at 02:13:15PM +, Fuchs, Andreas wrote:
> > > I was just pointing out, tha
On Mon, Oct 05, 2015 at 01:36:18PM +, Fuchs, Andreas wrote:
> > It's still unnecessary functionality and increases the kernel image size
> > and every hack requires maintenance. It would probably end up needing
> > compilation flag as there exists efforts like:
> >
> >
> > 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
>
On Mon, Oct 05, 2015 at 02:13:15PM +, Fuchs, Andreas wrote:
> > > 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.
> >
> >
> > 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
, 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;
Serge E. Hallyn
Subject: Re: [tpmdd-devel] [PATCH 4/4] keys,trusted
, 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;
Serge E. Hallyn
Subject: Re: [tpmdd-devel] [PATCH 4/4] keys,trusted
On Sat, Oct 03, 2015 at 01:26:55PM +0300, Jarkko Sakkinen wrote:
> 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
> > ---
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/trusted.h
> @@ -12,6 +12,13 @@
> #define
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
+/*
On Sat, Oct 03, 2015 at 01:26:55PM +0300, Jarkko Sakkinen wrote:
> 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
> > ---
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
+/*
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/trusted.h
> @@ -12,6 +12,13 @@
> #define
44 matches
Mail list logo
