On Tue, Dec 08, 2020 at 10:02:57AM -0500, Mimi Zohar wrote:

Hi Jarkko,

On Fri, 2020-12-04 at 17:30 +0200, Jarkko Sakkinen wrote:

quoted

On Wed, Dec 02, 2020 at 02:34:07PM -0500, gmail Elaine Palmer wrote:

quoted

Hi Sumit,  

Thank you for the detailed descriptions and examples of trust sources
for Trusted Keys.   A group of us in IBM (Stefan Berger, Ken Goldman,
Zhongshu Gu, Nayna Jain, Elaine Palmer, George Wilson, Mimi Zohar)
have been doing related work for quite some time, and we have one
primary concern and some suggested changes to the document. 

Our primary concern is that describing a TEE as a Trust Source needs
to be more specific.   For example, "ARM TrustZone" is not sufficient,
but "wolfSSL embedded SSL/TLS library with ARM TrustZone
CryptoCell-310" is.  Just because a key is protected by software
running in a TEE is not enough to establish trust.  Just like
cryptographic modules, a Trust Source should be defined as a specific
implementation on specific hardware with well-documented environmental
assumptions, dependencies, and threats.

In addition to the above concern, our suggested changes are inline
below.

In order to give a decent review comment it should have two ingredients:

- Where the existing line of code / text / whatever goes wrong.
- How it should modified and why that makes sense. And use as plain
  English and non-academic terms as possible, if it is documentation.
  Further, scope is only the kernel implementation, no more or no
  less.

"do this" is not unfortunately an argument. Feedback is welcome when
it is supported by something common sensse.

Even after the code is fully debugged, reviewed and tested, our concern
is that people will assume the security guarantees of TEE based trusted
keys to be equivalent to that of a discrete TPM.

quoted

Some meta suggestion of related to email:

Please also use a proper email client and split your paragraphs into
at most 80 character lines with new line characters when writing email.
I prefer to use 72 character line length so that there's some space
for longer email threads.

Sure, we'll re-post the suggested documentation changes/additions.

Mimi

So. Wouldn't it be a better idea to post a patch that Sumit could
squash to his (and add co-developed-by tag)?

/Jarkko

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel