On Tue, Jul 30, 2019 at 05:53:34PM +0530, Sumit Garg wrote:
> tee: optee: allow kernel pages to register as shm
> tee: enable support to register kernel memory
> tee: add private login method for kernel clients
> KEYS: trusted: Introduce TEE based Trusted Keys
> doc: keys: Document usage
On Thu, Aug 1, 2019 at 1:00 PM Sumit Garg wrote:
> > > Here TEE isn't similar to a user-space crypto library. In our case TEE
> > > is based on ARM TrustZone which only allows TEE communications to be
> > > initiated from privileged mode. So why would you like to route
> > > communications via us
On Thu, 1 Aug 2019 at 13:30, Janne Karhunen wrote:
>
> On Thu, Aug 1, 2019 at 10:40 AM Sumit Garg wrote:
>
> > > I chose the userspace plugin due to this, you can use userspace aids
> > > to provide any type of service. Use the crypto library you desire to
> > > do the magic you want.
> >
> > Her
On Thu, Aug 1, 2019 at 10:40 AM Sumit Garg wrote:
> > I chose the userspace plugin due to this, you can use userspace aids
> > to provide any type of service. Use the crypto library you desire to
> > do the magic you want.
>
> Here TEE isn't similar to a user-space crypto library. In our case TEE
On Thu, 1 Aug 2019 at 11:51, Janne Karhunen wrote:
>
> On Wed, Jul 31, 2019 at 4:58 PM Sumit Garg wrote:
>
> > > To clarify a bit further - my thought was to support any type of trust
> > > source.
> >
> > That could be very well accomplished via Trusted Keys abstraction
> > framework [1]. A trus
On Wed, Jul 31, 2019 at 5:23 PM Sumit Garg wrote:
> > I guess my wording was wrong, tried to say that physical TEEs in the
> > wild vary massively hardware wise. Generalizing these things is rough.
> >
>
> There are already well defined GlobalPlatform Standards to generalize
> the TEE interface.
On Wed, Jul 31, 2019 at 4:58 PM Sumit Garg wrote:
> > To clarify a bit further - my thought was to support any type of trust
> > source.
>
> That could be very well accomplished via Trusted Keys abstraction
> framework [1]. A trust source just need to implement following APIs:
>
> struct trusted_
On Wed, 31 Jul 2019 at 16:33, Janne Karhunen wrote:
>
> On Wed, Jul 31, 2019 at 1:26 PM Sumit Garg wrote:
>
> > > Interesting, I wrote something similar and posted it to the lists a while
> > > back:
> > > https://github.com/jkrh/linux/commit/d77ea03afedcb5fd42234cd834da8f8a0809f6a6
> > >
> > >
On Wed, 31 Jul 2019 at 15:51, Janne Karhunen wrote:
>
> Hi,
>
> To clarify a bit further - my thought was to support any type of trust
> source.
That could be very well accomplished via Trusted Keys abstraction
framework [1]. A trust source just need to implement following APIs:
struct trusted_k
On Wed, Jul 31, 2019 at 1:26 PM Sumit Garg wrote:
> > Interesting, I wrote something similar and posted it to the lists a while
> > back:
> > https://github.com/jkrh/linux/commit/d77ea03afedcb5fd42234cd834da8f8a0809f6a6
> >
> > Since there are no generic 'TEEs' available,
>
> There is already a
Hi Janne,
On Wed, 31 Jul 2019 at 12:41, Janne Karhunen wrote:
>
> Hi,
>
> Interesting, I wrote something similar and posted it to the lists a while
> back:
> https://github.com/jkrh/linux/commit/d77ea03afedcb5fd42234cd834da8f8a0809f6a6
>
> Since there are no generic 'TEEs' available,
There is a
Hi,
To clarify a bit further - my thought was to support any type of trust
source. Remote, local or both. Just having one particular type of
locally bound 'TEE' sounded very limited, especially when nothing from
the TEE execution side is really needed for supporting the kernel
crypto. What you rea
Hi,
Interesting, I wrote something similar and posted it to the lists a while back:
https://github.com/jkrh/linux/commit/d77ea03afedcb5fd42234cd834da8f8a0809f6a6
Since there are no generic 'TEEs' available, I implemented the same
thing as a generic protocol translator. The shared memory binding f
13 matches
Mail list logo
