Subject: [Teep] My BoF impression

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 3 Apr 2017 13:39:52 +0000

Hi all,

we started the meeting with a somewhat surprisingly large audience. Given the narrow focus on a protocol for managing software on Trusted Execution Environments (TEEs) I expected fewer people to show up. Instead, the room was full and it was one of the largest.

As I had expected the initial presentations providing background about TEEs was useful. I doubt that most attendees have had a chance to read through the material shared on the mailing list. After the meeting a few folks approached me and told me that they had learned new concepts during the BoF, which is good.

Following the presentations we had a couple of questions, which I believe, deserve further discussion on the list.

Going fast forward to the end of the meeting, the chairs asked two questions:

Q1: "Does the group understand the work to be done?"
A: More people hummed yes than no but it was only by a bit.  Not convincing.

Q2: How many people are interested in working on this?
A: About 14-15 people.

Sitting in the plane going back to Austria I was wondering whether we should have asked further questions to those who said "no". I am curious what aspect they didn't understood or whether this group included also those who weren't interested to do the work or, like PHB, wanted a different hardware security solution to begin with.

In any case, we will have to figure out what the next steps are and I am looking forward to chat with those who are interested to work on this topic. Please drop me a message if you care about turning TEEs into a more successful technology.

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Apr 2017 10:59:14 -0400

> Q1: “Does the group understand the work to be done?”

    > A: About 14-15 people.

I think that the question:
        Why do this work at the IETF?

was not sufficiently answered.  There are many possible answers.

I note that after TRILL and some other things, the answer "because the IETF
has the right clue" seems to be an acceptable answer to the above question.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 3 Apr 2017 11:21:00 -0400

Hello,

Thanks for your summary to the list, Hannes.  The helpful feedback I
received should provide guidance for those interested to get ready for
the next BoF.

The concrete work items were discussed on list, but not in the room.
These need to be made clear so that attendees understand the type and
scope of work.  Understanding the protocols and data models that exist
and what gaps remain would have been helpful.  Is there anything
unique about the protocols needed (managing trust applications, etc.).

Thank you,
Kathleen

On Mon, Apr 3, 2017 at 10:59 AM, Michael Richardson
<[email-masked]> wrote:
> _______________________________________________
> TEEP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teep
>

-- 

Best regards,
Kathleen

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 4 Apr 2017 14:21:03 +0300

Hannes Tschofenig writes:
> Sitting in the plane going back to Austria I was wondering whether we should
> have asked further questions to those who said “no”. I am curious what aspect
> they didn’t understood or whether this group included also those who weren’t
> interested to do the work or, like PHB, wanted a different hardware security
> solution to begin with.

I would have liked to have bit more time at the end for these type of
questions, but the discussion before those were also good, so I did
not want to cut it too short.

My feeling that the main question what people did not understand was:

	What is the real difference between TEEP and just normal
	application download. I.e., why separate protocol is needed.
	How is this different from just having perhaps encrypted
	signed application blob from the marketplace and installing
	that.

At least that was my main question when we discussed this before the
BoF.

Of course it does not help, that when you ask that question from
different people you get different answer, as the idea of what TEEP is
different for different people...

Trying to make the architecture too generic also confuses things. It
might be better to have more concrete example with more limited scope,
that would explain things what TEEP should provide.

For example:

	1) TEEP provides a way to install software from the Secure
	trusted application marketplace to the TEE running inside
	device.

	2) The Secure trusted appliation marketplace needs to be able
	to verify that the TEE wanting to install an application is
	actual TEE, and not some fake device, for example using
	signature from the key installed by the manufacturer which is
	used to sign the installation request.

	3) The Secure trusted application marketplace can then encrypt
	the trusted application with TEE specific key, so that nobody
	else than TEE can decrypt and install it. This will prevent
	leaking out confidential material inside the application.
	Trusted application instlal package might also be personalized
	for the specific TEE. Secure trusted application marketplace
	will also sign the trusted application install package, so TEE
	can verify it is authentic.

	4) TEE will verify the signature of the trusted application
	install package, and check that signer is trusted, and then it
	will decrypt the package, and install it.

	5) The application running on the REE side might need to
	verify that the trusted application part of it has been
	properly installed to real TEE, so it can trust it doing its
	job. I am not sure if this will be part of the TEEP or not...

Is my understanding of TEEP correct? I do not know, and I assume other
people have different ideas what should or should not be part of it.
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 04 Apr 2017 09:54:46 -0400

> can verify it is authentic.

And yet, this can mean that end-user and even app-writers can not verify what
code they are actually running.

I think we need to very carefully seperate signed (and auditable) code from
encrypted data.  And said encrypted data has to be non-executable, and the
auditable code has to be verified to not include a Turing machine.... no
(encrypted) data driven programming allowed.

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Tue, 4 Apr 2017 14:12:39 +0000

On 4 Apr 2017, at 12:21, Tero Kivinen <[email-masked]<mailto:[email-masked]>> wrote:

Of course it does not help, that when you ask that question from
different people you get different answer, as the idea of what TEEP is
different for different people…

I think there is a degree of talking at cross-purposes.

There is one group - essentially those sponsoring the creation of this group - which has a very clear understanding of what it would like TEEP to be, which is essentially three things:

  1.  A mechanism for managing Trusted Applications and their associated secrets and key material in a GlobalPlatform TEE or something that is conceptually very similar.
  2.  A mechanism for establishing a chain of trust rooted in firmware and covering the TEE and possibly other system components up to and including the executing Task in a Security Domain.
  3.  A mechanism - targeted at phone and tablet type devices - which operates independently of the “App Store” mechanism, and is based on a PKI infrastructure allowing Service Providers to manage the Trusted Applications they control without the need for user intervention.

The draft specification very clearly addresses such a system. Understanding it fully requires considerable familiarity with the GlobalPlatform TEE specifications, since much of the terminology and architectural assumptions are derived from these.

There is a second group which is starting from a more abstract position of what a TEE should look like and what security services it might then provide to a system and how the control of these could be structured. This is a completely different problem, and likely a much broader one which is difficult to encapsulate in a small scope.

For example:

I think this is a pretty good explanation of what the first group would like to see.

Best regards
Jeremy

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 5 Apr 2017 15:01:29 +0300

Michael Richardson writes:
> And yet, this can mean that end-user and even app-writers can not
> verify what code they are actually running.

The end-user and app-writers already both trust the marketplace
provided by the operating system and trusts them. I.e. if marketplace
owner decides to add malware to each application they send to the
customers who would notice that? The connection between the device and
markplace is already encrypted, the software which downloads it from
the OS marketplace is provided by the OS, and they do verify that you
need to log in with your credentials before you can load anything. And
marketplace can provide different versions to different users, so
developer migth always get clean copy of their own app, but other
users could get modified version. Operating system on different
devices sometimes already protects apps from each other, and so on.

So if you do not trust the device OS, and marketplace provided by the
OS, there is nothing you can do.

Have you ever tried to verify for example that the application in your
iPhone is really same as what was given to the apple app store? Can
you even do that in iOS environment?

> I think we need to very carefully seperate signed (and auditable)
> code from encrypted data. And said encrypted data has to be
> non-executable, and the auditable code has to be verified to not
> include a Turing machine.... no (encrypted) data driven programming
> allowed.

That would be another good option. On the other hand, I do think
application developers would like to encrypt the executable also in
some cases. Perhaps this just means that we would need two containers
we are sending from the trusted marketplace to the TEE, one for code
and one for data, and data would always be encrypted, but code only if
requested by the trusted app itself.
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Apr 2017 09:00:42 -0400

> provided by the operating system and trusts them. I.e. if marketplace

In Android, this trust is optional, and isn't locked down by the
manufacturer of the device or the supplier of the operating system (at
present).
We are free to create new marketplaces, and also free to avoid all market
places.   We (or, our respective enterprises or national security agencies,
e.g: NIST, CSE, etc.) are free to create environments where all source code
is available for review.

So while all of your points about trust for an average user are true, it does
not change the point that we (the IETF) should not be creating an environment
in which code can not be audited.

    > you even do that in iOS environment?

Well. There is a reason I, and many others, have chosen not to build trust
in that vertically integrated environment.

    > requested by the trusted app itself.

Exactly: it's not hard to do.

As for developers who think they need to encrypt their code:  it is akin
to cryptographers who won't publish their algorithm.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Apr 2017 09:03:43 -0400

Jeremy O'Donoghue <[email-masked]> wrote:
    > There is one group - essentially those sponsoring the creation of this
    > group - which has a very clear understanding of what it would like
    > TEEP to be, which is essentially three things:

...

    > There is a second group which is starting from a more abstract
    > position of what a TEE should look like and what security services it
    > might then provide to a system and how the control of these could be
    > structured. This is a completely different problem, and likely a much
    > broader one which is difficult to encapsulate in a small scope.

Do you think the second group, which I perceive as being more of the core
IETF security types, is interested/willing to engage with the first group?

Is the first group actually willing to turn editorial control over to the
IETF?   Can we kill both birds with one protocol?

---

From: "Wheeler, David M" <[email-masked]>
Date: Wed, 5 Apr 2017 16:34:29 +0000

I’m a bit behind on the thread, but want to respond to Jeremy’s original comment.

First, I this is exactly the type of conversation we need to have. Thanks for kicking this off very directly.
I agree with your perception of the two groups, though I think it is important to understand the motivations in the second group, since they may be varied.

I will put myself voluntarily in the second bucket. I will present my personal perspective, which may be different from others in the “second group”.

For myself, I am looking to define a more abstract definition of a TEE, and desiring a protocol that is applicable to a wide set of TEEs. From my perspective, looking at TEEs that Intel has in the marketplace, and also having worked for several years on Intel’s XScale processors (and am thus familiar with TZ), the current OTrP draft addresses Trust Zone concerns without really considering other TEEs. This is my perception, of course.

It is also my opinion that an IETF protocol should do more than address implementation specific concerns.
I am motivated to work jointly on developing OTrP to address a wider set of concerns common to TEEs and their environments, with the purpose of expanding the ease with which the marketplace can utilize TEE mechanisms.

Part of this development of OTrP (from my perspective) is being less normative about the exact location and instantiation of certain parties (particularly the TSM) and be specific on the operations and activities at particular “service access points” of the protocol. My point here is that OTrP in its current rendition is <emphasis> too </emphasis> implementation specific and too normative in its description of the marketplace. I believe this is fine as an example, but not as part of the protocol.

I believe IETF is exactly the place to have this conversation and define a very open and inclusive protocol. I realize that takes some time. I look forward to having this conversation in more detail.

Thanks,
Dave Wheeler

From: TEEP [mailto:[email-masked]] On Behalf Of Jeremy O'Donoghue
Sent: Tuesday, April 4, 2017 7:13 AM
To: Tero Kivinen <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; teep <[email-masked]>
Subject: Re: [Teep] My BoF impression

For example:

Best regards
Jeremy

---

From: Brian Witten <[email-masked]>
Date: Wed, 5 Apr 2017 17:02:10 +0000

Thank You Dave!  I'd like to echo & agree with many of your points, but ask for a clarification on one aspect.  "First, I (believe) this is exactly the type of conversation we need to have. Thanks for kicking this off very directly."  Well Said, Thank You Both!  "I am motivated to work jointly on developing OTrP to address a wider set of concerns common to TEEs and their environments, with the purpose of expanding the ease with which the marketplace can utilize TEE mechanisms." Again, I'm motivated by the same purpose.  "Part of this development of OTrP (from my perspective) is being less normative about the exact location and instantiation of certain parties (particularly the TSM) and be specific on the operations and activities at particular 'service access points' of the protocol."  I believe that is a great suggestion, and I'm fully supportive.  Still my clarifying question relates to the desire "to define a more abstract definition of a TEE, and desiring a protocol that is applicable to a wide set of TEEs."  I'm eager to support a wide set of TEE, including both SGX and TZ based TEE.   My question is, "do we need to abandon the Global Platform (GP) definition of a TEE to support both SGX and TZ based TEE?"  I believe that we do Not need to abandon the GP definition of a TEE to support both SGX and TZ based TEE, but I'd be eager to get your view here as you've framed the rest so very well.  Last, either way, "I believe IETF is exactly the place to have this conversation and define a very open and inclusive protocol."  Again, I agree completely.  

Thank You Again!
Brian

From: TEEP <[email-masked]> on behalf of Wheeler, David M <[email-masked]>
Sent: Wednesday, April 5, 2017 9:34 AM
To: 'Jeremy O'Donoghue'; Tero Kivinen
Cc: Hannes Tschofenig; teep
Subject: [EXT] Re: [Teep] My BoF impression

 

 

Thanks,
Dave Wheeler

On 4 Apr 2017, at 12:21, Tero Kivinen <[email-masked]> wrote:

 

 
 A mechanism for managing Trusted Applications and their associated secrets and key material in a GlobalPlatform TEE or something that is conceptually very similar.
A mechanism for establishing a chain of trust rooted in firmware and covering the TEE and possibly other system components up to and including the executing Task in a Security Domain.
A mechanism - targeted at phone and tablet type devices - which operates independently of the “App Store” mechanism, and is based on a PKI infrastructure allowing Service Providers to manage the Trusted Applications they control  without the need for user intervention.

 

For example:

 

Best regards
 
Jeremy

---

From: Nick Cook <[email-masked]>
Date: Thu, 20 Apr 2017 09:20:08 +0000

Personally speaking, OTrP is about being able to install security applications into an environment that provides "trusted" hardware backed isolation between the different applications. OTrP does that by establishing it is working against the right device type and right isolation environment type and then proceeds to install the application in a way that provides protection for confidentiality and integrity. The term TEE is probably too often associated with a specific formulation of an isolation environment and therefore this is perhaps the first thing we should move forward.

As an example, I've been working on a hardware backed hypervisor environment that uses OTrP for the installation of the different containers/domains and the virtual machine contents that goes in them. The trust chain from OTrP is met and the isolation of applications and key material to those applications is also provided.

Based on that work and thinking specifically to my original goals for OTrP when we started this work a few years back, I would like to support Dave Wheeler's comment on needing to formulate a more abstract definition for TEE. I also agree with Brian that the GP definition doesn't need to be abandoned to do that - I believe, expressed in the right way, the GP definition of a TEE covers the hardware hypervisor case I described earlier in the email also and I'm sure it can cover the other environments too.

I do however think it is important that we restrict to isolation environments that are hardware backed as this is fundamental to the trust model.

I also support Dave's suggestion that we can be less normative on exact locations of the functional blocks of OTrP. I would like to have a companion document that does provide example deployments but the core protocol itself does not need to be locked down to a specific deployment approach.

Nick Cook
-----Original Message-----
From: Brian Witten [mailto:[email-masked]] 
Sent: 05 April 2017 18:02
To: Wheeler, David M <[email-masked]>; 'Jeremy O'Donoghue' <[email-masked]>; Tero Kivinen <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; teep <[email-masked]>
Subject: Re: [Teep] [EXT] Re: My BoF impression

Thank You Again!
Brian

I'm a bit behind on the thread, but want to respond to Jeremy's original comment.

I will put myself voluntarily in the second bucket. I will present my personal perspective, which may be different from others in the "second group".
 
For myself, I am looking to define a more abstract definition of a TEE, and desiring a protocol that is applicable to a wide set of TEEs. From my perspective,  looking at TEEs that Intel has in the marketplace, and also having worked for several years on Intel's XScale processors (and am thus familiar with TZ), the current OTrP draft addresses Trust Zone concerns without really considering other TEEs. This is my  perception, of course.

Part of this development of OTrP (from my perspective) is being less normative about the exact location and instantiation of certain parties (particularly the  TSM) and be specific on the operations and activities at particular "service access points" of the protocol. My point here is that OTrP in its current rendition is <emphasis> too </emphasis> implementation specific and too normative in its description of the  marketplace. I believe this is fine as an example, but not as part of the protocol.

Thanks,
Dave Wheeler

What is the real difference between TEEP and just normal application download. I.e., why separate protocol is needed.
How is this different from just having perhaps encrypted signed application blob from the marketplace and installing that.

At least that was my main question when we discussed this before the BoF.

Of course it does not help, that when you ask that question from different people you get different answer, as the idea of what TEEP is different for different people.

 

 A mechanism for managing Trusted Applications and their associated secrets and key material in a GlobalPlatform TEE or something that is conceptually very similar.
A mechanism for establishing a chain of trust rooted in firmware and covering the TEE and possibly other system components up to and including the executing Task in a Security Domain.
A mechanism - targeted at phone and tablet type devices - which operates independently of the "App Store" mechanism, and is based on a PKI infrastructure allowing Service Providers to manage the Trusted Applications they control  without the need for user intervention.

 

Trying to make the architecture too generic also confuses things. It might be better to have more concrete example with more limited scope, that would explain things what TEEP should provide.

For example:

1) TEEP provides a way to install software from the Secure trusted application marketplace to the TEE running inside device.

2) The Secure trusted appliation marketplace needs to be able to verify that the TEE wanting to install an application is actual TEE, and not some fake device, for example using signature from the key installed by the manufacturer which is used to sign the installation request.

3) The Secure trusted application marketplace can then encrypt the trusted application with TEE specific key, so that nobody else than TEE can decrypt and install it. This will prevent leaking out confidential material inside the application.
Trusted application instlal package might also be personalized for the specific TEE. Secure trusted application marketplace will also sign the trusted application install package, so TEE can verify it is authentic.

4) TEE will verify the signature of the trusted application install package, and check that signer is trusted, and then it will decrypt the package, and install it.

5) The application running on the REE side might need to verify that the trusted application part of it has been properly installed to real TEE, so it can trust it doing its job. I am not sure if this will be part of the TEEP or not...

Is my understanding of TEEP correct? I do not know, and I assume other people have different ideas what should or should not be part of it.

Best regards
 
Jeremy

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Thu, 20 Apr 2017 10:01:17 +0000

The GP definition of a TEE[1] is not tied to Trustzone in any way, and I see nothing to suggest that it precludes the type of hypervisor-based environment you describe.

What GlobalPlatform says ([1], Section 2.2.1), is:

The primary purpose of a TEE is to protect its assets from the REE
and other environments.
- This is achieved through hardware mechanisms that those other
  environments cannot control.

This protection always includes protection against other execution
environments.
[…]
The TEE is instantiated through a secure boot process using assets
bound to the SoC or the Off-SoC Security Processor and isolated
from the REE.
- The integrity and authenticity gained through secure boot:
  - Extends throughout the lifetime of the TEE.
  - Is retained through any state transitions in the system such
    as power transitions or core migration.

It further defines the transition from the non-secure to secure world in a fairly abstract manner which covers the hypervisor use case sufficiently, I think ([1], Section 2.2.3):

The only way for the REE to get access to trusted resources is via
any API entry points or services exposed by the TEE and accessed
through, for example, the TEE Client API. This does not preclude
the capability of the REE passing buffers to the TEE (and vice versa)
in a controlled and protected manner.

In short, I agree with Brian that the GP definition of a TEE is a reasonable starting point for discussion, but I strongly support IETF exploring other use cases and system architectures that GP has not addressed - it seems to me that this is where the greatest value would be generated for the ecosystem.

I am concerned that it will be challenging to move forward effectively when many participants are unfamiliar with the GP standards-base on which the current draft draws heavily unless we are able to take steps to remedy this. Are there any suggestions as to how this could be managed? In short, how do we align the two different groups in Deep more closely?

Best regards
Jeremy

[1] GlobalPlatform TEE System Architecture, Version 1.1, January 2017.

On 20 Apr 2017, at 10:20, Nick Cook <[email-masked]<mailto:[email-masked]>> wrote:

Nick Cook
-----Original Message-----
From: Brian Witten [mailto:[email-masked]]
Sent: 05 April 2017 18:02
To: Wheeler, David M <[email-masked]<mailto:[email-masked]>>; 'Jeremy O'Donoghue' <[email-masked]<mailto:[email-masked]>>; Tero Kivinen <[email-masked]<mailto:[email-masked]>>
Cc: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; teep <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teep] [EXT] Re: My BoF impression

Thank You Again!
Brian

From: TEEP <[email-masked]<mailto:[email-masked]>> on behalf of Wheeler, David M <[email-masked]<mailto:[email-masked]>>

Thanks,
Dave Wheeler

From: TEEP [mailto:[email-masked]] On Behalf Of Jeremy O'Donoghue
Sent: Tuesday, April 4, 2017 7:13 AM
To: Tero Kivinen <[email-masked]<mailto:[email-masked]>>
Cc: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; teep <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teep] My BoF impression

For example:

Best regards

Jeremy

---

From: Nick Cook <[email-masked]>
Date: Thu, 20 Apr 2017 15:08:53 +0000

It seems we are also in agreement. I too wrote that I think GP definition is a good starting point for this in my previous post.

My suggestion as a way to start to align the groups would be for us to state how the GP definition maps onto the different concrete realizations of TEE. You’ve begun that process below for the hypervisor environment I mentioned and we should complete that. If we then find through this process that we cannot make the mapping for an environment we can relook at the definition. As a starter I suggest we need to cover Trustzone, hardware backed hypervisor, SGX. Any others?

This should tease out which specific aspects of the GP definition are not generic enough, ** if any **, and I hope that then provides a baseline for all to see how OTrP is relevant to a particular configuration or architecture.

Thoughts?

Nick Cook
From: Jeremy O'Donoghue [mailto:[email-masked]]
Sent: 20 April 2017 11:01
To: Nick Cook <[email-masked]>
Cc: Brian Witten <[email-masked]>; Wheeler, David M <[email-masked]>; Tero Kivinen <[email-masked]>; Hannes Tschofenig <[email-masked]>; teep <[email-masked]>
Subject: Re: [Teep] [EXT] Re: My BoF impression

Best regards
Jeremy

Nick Cook
-----Original Message-----
From: Brian Witten [mailto:[email-masked]]
Sent: 05 April 2017 18:02
To: Wheeler, David M <[email-masked]<mailto:[email-masked]>>; 'Jeremy O'Donoghue' <[email-masked]<mailto:[email-masked]>>; Tero Kivinen <[email-masked]<mailto:[email-masked]>>
Cc: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; teep <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teep] [EXT] Re: My BoF impression

Thank You Again!
Brian

Thanks,
Dave Wheeler

For example:

Best regards

Jeremy

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Apr 2017 14:20:41 -0700

> As an example, I've been working on a hardware backed hypervisor environment that uses OTrP for the installation of the different containers/domains and the virtual machine contents that goes in th…

Nick,

By "hardware backed hypervisor" do you mean running e.g. OKL4 or Xen 
hypervisor on e.g. an Intel or ARM system with hardware virtualization 
support?
Or something else with a different coupling between the hardware and the 
hypervisor?

Just want to make sure I understand.

I think it would be useful to see how the isolation provided by 
hypervisors fit with the TEE/REE split.

Thanks,
    Erik

---

From: Nick Cook <[email-masked]>
Date: Mon, 24 Apr 2017 08:47:36 +0000

Before I answer let me just state that my posts make no comparisons between technologies - that is up to the person selecting a particular type. My posts are purely intended to highlight the scope of OTrP as a protocol.

 So in answer,

Intel or ARM hypervisor with hardware support can form the basis. As long as the hypervisor software has been started following the correct process and provides the other features detailed in the GP definition.

The most likely candidate hypervisor type would be a hybrid mode hypervisor. An REE is simply an environment with a more capable OS and access to a multitude of peripherals - and can be assigned as such in a VM within the hybrid model. A TEE is then the constrained guests. A type 2 hypervisor won't be sufficient (in my view).

I don't want to deflect away from the core conversation thread here - regarding ensuring the OTrP spec usage of TEE is clarified to satisfy the target environments but I do want to highlight that OTrP has broad scope over hardware isolation technologies. It is important that the term TEE, which is commonly used today to refer to a single environment type (albeit incorrectly), is clear within the spec and the coverage that affords.

So what we really need to do is to determine if there is anything in the GP definition that precludes a particular hardware backed isolation technology. Then we can state the definition of TEE in OTrP spec and move the process forward.

Thanks,

Nick Cook
-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]] 
Sent: 20 April 2017 22:21
To: Nick Cook <[email-masked]>; Brian Witten <[email-masked]>; Wheeler, David M <[email-masked]>; 'Jeremy O'Donoghue' <[email-masked]>; Tero Kivinen <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; teep <[email-masked]>
Subject: Re: [Teep] [EXT] Re: My BoF impression

Nick,

By "hardware backed hypervisor" do you mean running e.g. OKL4 or Xen hypervisor on e.g. an Intel or ARM system with hardware virtualization support?
Or something else with a different coupling between the hardware and the hypervisor?

I think it would be useful to see how the isolation provided by hypervisors fit with the TEE/REE split.

Thanks,
    Erik

> To: Wheeler, David M <[email-masked]>; 'Jeremy O'Donoghue' 
> <[email-masked]>; Tero Kivinen <[email-masked]>