Thread (26 messages) 26 messages, 3 authors, 2019-09-02

Re: [RFC/RFT v4 0/5] Add generic trusted keys framework/subsystem

From: Sumit Garg <hidden>
Date: 2019-08-20 05:47:01
Also in: keyrings, linux-crypto, linux-integrity, lkml

On Mon, 19 Aug 2019 at 22:24, Jarkko Sakkinen
[off-list ref] wrote:
On Tue, Aug 13, 2019 at 01:22:59PM +0530, Sumit Garg wrote:
quoted
This patch-set is an outcome of discussion here [1]. It has evolved very
much since v1 to create, consolidate and generalize trusted keys
subsystem.

This framework has been tested with trusted keys support provided via TEE
but I wasn't able to test it with a TPM device as I don't possess one. It
would be really helpful if others could test this patch-set using a TPM
device.
I think 1/5-4/5 make up a non-RFC patch set that needs to reviewed,
tested and merged as a separate entity.
Okay.
On the other hand 5/5 cannot be merged even if I fully agreed on
the code change as without TEE patch it does not add any value for
Linux.
I agree here that 5/5 should go along with TEE patch-set. But if you
look at initial v1 patch-set, the idea was to get feedback on trusted
keys abstraction as a standalone patch along with testing using a TPM
(1.x or 2.0).

Since Mimi has tested this patch-set with TPM (1.x & 2.0), I am happy
to merge 5/5 with TEE patch-set. But it would be nice if I could get
feedback on 5/5 before I send next version of TEE patch-set.
To straighten up thing I would suggest that the next patch set
version would only consists of the first four patches and we meld
them to the shape so that we can land them to the mainline. Then
it should be way more easier to concentrate the actual problem you
are trying to resolve.
Okay will send next patch-set version with first four patches only.

-Sumit
/Jarkko
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help