All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Sumit Garg <sumit.garg@linaro.org>
Cc: keyrings@vger.kernel.org, linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	Jens Wiklander <jens.wiklander@linaro.org>,
	corbet@lwn.net, dhowells@redhat.com, jejb@linux.ibm.com,
	zohar@linux.ibm.com, jmorris@namei.org, serge@hallyn.com,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Daniel Thompson <daniel.thompson@linaro.org>,
	linux-doc@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	tee-dev@lists.linaro.org
Subject: Re: [RFC 6/7] doc: keys: Document usage of TEE based Trusted Keys
Date: Fri, 14 Jun 2019 15:36:22 +0000	[thread overview]
Message-ID: <20190614153622.GG11241@linux.intel.com> (raw)
In-Reply-To: <CAFA6WYP7qi_NBRUDBhcEAEzJY-iFvJdXqtCtgQxqAvPSXDjEng@mail.gmail.com>

On Fri, Jun 14, 2019 at 11:07:23AM +0530, Sumit Garg wrote:
> On Thu, 13 Jun 2019 at 21:04, Jarkko Sakkinen
> <jarkko.sakkinen@linux.intel.com> wrote:
> >
> > On Thu, Jun 13, 2019 at 04:00:32PM +0530, Sumit Garg wrote:
> > > Provide documentation for usage of TEE based Trusted Keys via existing
> > > user-space "keyctl" utility. Also, document various use-cases.
> > >
> > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> >
> > Sorry missed this patch. Anyway, I don't think we want multiple trusted
> > keys subsystems. You have to fix the existing one if you care to get
> > these changes in. There is no really other way around this.
> >
> 
> I understand your point.
> 
> When I initially looked at trusted key implementation, it seemed to be
> tightly coupled to use TPM device. So I implemented a parallel
> implementation to get initial feedback (functionality-wise) on this
> new approach.

Yeah, I completely get this. My feedback this is: we can definitely
consider TEE based trusted keys, and I know that trusted.ko is a mess,
but still that is the only right long-term path. Think about the
positive side: if you as a side-effect can make it cleaner and more
versatile, your patch set will improve the quality of the kernel as a
whole i.e. you benefit larger audience than just TEE user base :-)

> I will work on abstraction of trusted key apis to use either approach.
> But is it fine with you if I send if I send a separate RFC patch for
> abstraction and later once reviewed I will incorporate that patch in
> this patch-set.
> 
> It will be really helpful if you could help to test that abstraction
> patch with a real TPM device as I doesn't posses one to test.

I can, yes.

/Jarkko

WARNING: multiple messages have this Message-ID (diff)
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Sumit Garg <sumit.garg@linaro.org>
Cc: keyrings@vger.kernel.org, linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	Jens Wiklander <jens.wiklander@linaro.org>,
	corbet@lwn.net, dhowells@redhat.com, jejb@linux.ibm.com,
	zohar@linux.ibm.com, jmorris@namei.org, serge@hallyn.com,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Daniel Thompson <daniel.thompson@linaro.org>,
	linux-doc@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	tee-dev@lists.linaro.org
Subject: Re: [RFC 6/7] doc: keys: Document usage of TEE based Trusted Keys
Date: Fri, 14 Jun 2019 18:36:22 +0300	[thread overview]
Message-ID: <20190614153622.GG11241@linux.intel.com> (raw)
In-Reply-To: <CAFA6WYP7qi_NBRUDBhcEAEzJY-iFvJdXqtCtgQxqAvPSXDjEng@mail.gmail.com>

On Fri, Jun 14, 2019 at 11:07:23AM +0530, Sumit Garg wrote:
> On Thu, 13 Jun 2019 at 21:04, Jarkko Sakkinen
> <jarkko.sakkinen@linux.intel.com> wrote:
> >
> > On Thu, Jun 13, 2019 at 04:00:32PM +0530, Sumit Garg wrote:
> > > Provide documentation for usage of TEE based Trusted Keys via existing
> > > user-space "keyctl" utility. Also, document various use-cases.
> > >
> > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> >
> > Sorry missed this patch. Anyway, I don't think we want multiple trusted
> > keys subsystems. You have to fix the existing one if you care to get
> > these changes in. There is no really other way around this.
> >
> 
> I understand your point.
> 
> When I initially looked at trusted key implementation, it seemed to be
> tightly coupled to use TPM device. So I implemented a parallel
> implementation to get initial feedback (functionality-wise) on this
> new approach.

Yeah, I completely get this. My feedback this is: we can definitely
consider TEE based trusted keys, and I know that trusted.ko is a mess,
but still that is the only right long-term path. Think about the
positive side: if you as a side-effect can make it cleaner and more
versatile, your patch set will improve the quality of the kernel as a
whole i.e. you benefit larger audience than just TEE user base :-)

> I will work on abstraction of trusted key apis to use either approach.
> But is it fine with you if I send if I send a separate RFC patch for
> abstraction and later once reviewed I will incorporate that patch in
> this patch-set.
> 
> It will be really helpful if you could help to test that abstraction
> patch with a real TPM device as I doesn't posses one to test.

I can, yes.

/Jarkko

  reply	other threads:[~2019-06-14 15:36 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-13 10:30 [RFC 0/7] Introduce TEE based Trusted Keys support Sumit Garg
2019-06-13 10:42 ` Sumit Garg
2019-06-13 10:30 ` [RFC 1/7] tee: optee: allow kernel pages to register as shm Sumit Garg
2019-06-13 10:42   ` Sumit Garg
2019-06-13 15:12   ` Jarkko Sakkinen
2019-06-13 15:12     ` Jarkko Sakkinen
2019-06-13 15:17     ` Jarkko Sakkinen
2019-06-13 15:17       ` Jarkko Sakkinen
2019-06-13 15:17       ` Jarkko Sakkinen
2019-06-13 15:17         ` Jarkko Sakkinen
2019-06-14  5:12         ` Sumit Garg
2019-06-14  5:24           ` Sumit Garg
2019-06-14  8:15   ` Jens Wiklander
2019-06-14  8:15     ` Jens Wiklander
2019-06-13 10:30 ` [RFC 2/7] tee: enable support to register kernel memory Sumit Garg
2019-06-13 10:42   ` Sumit Garg
2019-06-13 15:20   ` Jarkko Sakkinen
2019-06-13 15:20     ` Jarkko Sakkinen
2019-06-14  5:13     ` Sumit Garg
2019-06-14  5:25       ` Sumit Garg
2019-06-14  8:16   ` Jens Wiklander
2019-06-14  8:16     ` Jens Wiklander
2019-06-13 10:30 ` [RFC 3/7] tee: add private login method for kernel clients Sumit Garg
2019-06-13 10:42   ` Sumit Garg
2019-07-08 15:39   ` Jens Wiklander
2019-07-08 15:39     ` Jens Wiklander
2019-07-09  5:56     ` Sumit Garg
2019-07-09  5:56       ` Sumit Garg
2019-07-09  7:03       ` Jens Wiklander
2019-07-09  7:03         ` Jens Wiklander
2019-07-09  9:36         ` Sumit Garg
2019-07-09  9:48           ` Sumit Garg
2019-07-29  7:08           ` Jens Wiklander
2019-07-29  7:08             ` Jens Wiklander
2019-07-29 13:13             ` Sumit Garg
2019-07-29 13:25               ` Sumit Garg
2019-06-13 10:30 ` [RFC 4/7] KEYS: trusted: Introduce TEE based Trusted Keys Sumit Garg
2019-06-13 10:42   ` Sumit Garg
2019-06-13 15:32   ` Jarkko Sakkinen
2019-06-13 15:32     ` Jarkko Sakkinen
2019-06-14  5:43     ` Sumit Garg
2019-06-14  5:55       ` Sumit Garg
2019-06-13 10:30 ` [RFC 5/7] KEYS: encrypted: Allow TEE based trusted master keys Sumit Garg
2019-06-13 10:42   ` Sumit Garg
2019-06-13 10:30 ` [RFC 6/7] doc: keys: Document usage of TEE based Trusted Keys Sumit Garg
2019-06-13 10:42   ` Sumit Garg
2019-06-13 15:34   ` Jarkko Sakkinen
2019-06-13 15:34     ` Jarkko Sakkinen
2019-06-14  5:37     ` Sumit Garg
2019-06-14  5:49       ` Sumit Garg
2019-06-14 15:36       ` Jarkko Sakkinen [this message]
2019-06-14 15:36         ` Jarkko Sakkinen
2019-06-13 10:30 ` [RFC 7/7] MAINTAINERS: Add entry for " Sumit Garg
2019-06-13 10:42   ` Sumit Garg
2019-06-13 16:40 ` [RFC 0/7] Introduce TEE based Trusted Keys support Casey Schaufler
2019-06-13 16:40   ` Casey Schaufler
2019-06-14  0:03   ` Mimi Zohar
2019-06-14  0:03     ` Mimi Zohar
2019-06-14  8:17     ` Sumit Garg
2019-06-14  8:29       ` Sumit Garg
2019-06-14  5:58   ` Sumit Garg
2019-06-14  5:58     ` Sumit Garg
2019-07-08 12:41 ` Sumit Garg
2019-07-08 12:53   ` Sumit Garg
2019-07-08 16:31   ` Jens Wiklander
2019-07-08 16:31     ` Jens Wiklander
2019-07-09  5:58     ` Sumit Garg
2019-07-09  5:59       ` Sumit Garg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190614153622.GG11241@linux.intel.com \
    --to=jarkko.sakkinen@linux.intel.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=corbet@lwn.net \
    --cc=daniel.thompson@linaro.org \
    --cc=dhowells@redhat.com \
    --cc=jejb@linux.ibm.com \
    --cc=jens.wiklander@linaro.org \
    --cc=jmorris@namei.org \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=serge@hallyn.com \
    --cc=sumit.garg@linaro.org \
    --cc=tee-dev@lists.linaro.org \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.