* Re: [PATCH v8 0/4] Introduce TEE based Trusted Keys support [not found] < <CAFA6WYPetvod-Wov2n_L5TL771j+-kt+_csyWYT-uM=haEKMZQ@mail.gmail.com> @ 2020-11-06 14:52 ` Jarkko Sakkinen 2020-12-04 5:16 ` Jarkko Sakkinen 0 siblings, 1 reply; 6+ messages in thread From: Jarkko Sakkinen @ 2020-11-06 14:52 UTC (permalink / raw) To: op-tee [-- Attachment #1: Type: text/plain, Size: 1452 bytes --] On Fri, Nov 06, 2020 at 03:02:41PM +0530, Sumit Garg wrote: > On Thu, 5 Nov 2020 at 10:37, Jarkko Sakkinen <jarkko@kernel.org> wrote: > > > > On Tue, Nov 03, 2020 at 09:31:42PM +0530, Sumit Garg wrote: > > > Add support for TEE based trusted keys where TEE provides the functionality > > > to seal and unseal trusted keys using hardware unique key. Also, this is > > > an alternative in case platform doesn't possess a TPM device. > > > > > > This patch-set has been tested with OP-TEE based early TA which is already > > > merged in upstream [1]. > > > > Is the new RPI400 computer a platform that can be used for testing > > patch sets like this? I've been looking for a while something ARM64 > > based with similar convenience as Intel NUC's, and on the surface > > this new RPI product looks great for kernel testing purposes. > > Here [1] is the list of supported versions of Raspberry Pi in OP-TEE. > The easiest approach would be to pick up a supported version or else > do an OP-TEE port for an unsupported one (which should involve minimal > effort). > > [1] https://optee.readthedocs.io/en/latest/building/devices/rpi3.html#what-versions-of-raspberry-pi-will-work > > -Sumit If porting is doable, then I'll just order RPI 400, and test with QEMU up until either I port OP-TEE myself or someone else does it. For seldom ARM testing, RPI 400 is really convenient device with its boxed form factor. /Jarkko ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v8 0/4] Introduce TEE based Trusted Keys support 2020-11-06 14:52 ` [PATCH v8 0/4] Introduce TEE based Trusted Keys support Jarkko Sakkinen @ 2020-12-04 5:16 ` Jarkko Sakkinen 2020-12-08 11:51 ` Sumit Garg 0 siblings, 1 reply; 6+ messages in thread From: Jarkko Sakkinen @ 2020-12-04 5:16 UTC (permalink / raw) To: op-tee [-- Attachment #1: Type: text/plain, Size: 3825 bytes --] On Fri, Nov 06, 2020 at 04:52:52PM +0200, Jarkko Sakkinen wrote: > On Fri, Nov 06, 2020 at 03:02:41PM +0530, Sumit Garg wrote: > > On Thu, 5 Nov 2020 at 10:37, Jarkko Sakkinen <jarkko@kernel.org> wrote: > > > > > > On Tue, Nov 03, 2020 at 09:31:42PM +0530, Sumit Garg wrote: > > > > Add support for TEE based trusted keys where TEE provides the functionality > > > > to seal and unseal trusted keys using hardware unique key. Also, this is > > > > an alternative in case platform doesn't possess a TPM device. > > > > > > > > This patch-set has been tested with OP-TEE based early TA which is already > > > > merged in upstream [1]. > > > > > > Is the new RPI400 computer a platform that can be used for testing > > > patch sets like this? I've been looking for a while something ARM64 > > > based with similar convenience as Intel NUC's, and on the surface > > > this new RPI product looks great for kernel testing purposes. > > > > Here [1] is the list of supported versions of Raspberry Pi in OP-TEE. > > The easiest approach would be to pick up a supported version or else > > do an OP-TEE port for an unsupported one (which should involve minimal > > effort). > > > > [1] https://optee.readthedocs.io/en/latest/building/devices/rpi3.html#what-versions-of-raspberry-pi-will-work > > > > -Sumit > > If porting is doable, then I'll just order RPI 400, and test with QEMU > up until either I port OP-TEE myself or someone else does it. > > For seldom ARM testing, RPI 400 is really convenient device with its > boxed form factor. I'm now a proud owner of Raspberry Pi 400 home computer :-) I also found instructions on how to boot a custom OS from a USB stick: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md Also, my favorite build system BuildRoot has bunch of of the shelf configs: ➜ buildroot-sgx (master) ✔ ls -1 configs | grep raspberry raspberrypi0_defconfig raspberrypi0w_defconfig raspberrypi2_defconfig raspberrypi3_64_defconfig raspberrypi3_defconfig raspberrypi3_qt5we_defconfig raspberrypi4_64_defconfig raspberrypi4_defconfig raspberrypi_defconfig I.e. I'm capable of compiling kernel and user space and boot it up with it. Further, I can select this compilation option: BR2_TARGET_OPTEE_OS: │ │ OP-TEE OS provides the secure world boot image and the trust │ application development kit of the OP-TEE project. OP-TEE OS │ also provides generic trusted application one can embedded │ into its system. │ │ http://github.com/OP-TEE/optee_os Is that what I want? If I put this all together and apply your patches, should the expectation be that I can use trusted keys? Please note that I had a few remarks about your patches (minor but need to be fixed), but this version is already solid enough for testing. /Jarkko ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v8 0/4] Introduce TEE based Trusted Keys support 2020-12-04 5:16 ` Jarkko Sakkinen @ 2020-12-08 11:51 ` Sumit Garg 0 siblings, 0 replies; 6+ messages in thread From: Sumit Garg @ 2020-12-08 11:51 UTC (permalink / raw) To: op-tee [-- Attachment #1: Type: text/plain, Size: 4589 bytes --] Hi Jarkko, Apologies for the delay in my response as I was busy with other high priority work. On Fri, 4 Dec 2020 at 10:46, Jarkko Sakkinen <jarkko@kernel.org> wrote: > > On Fri, Nov 06, 2020 at 04:52:52PM +0200, Jarkko Sakkinen wrote: > > On Fri, Nov 06, 2020 at 03:02:41PM +0530, Sumit Garg wrote: > > > On Thu, 5 Nov 2020 at 10:37, Jarkko Sakkinen <jarkko@kernel.org> wrote: > > > > > > > > On Tue, Nov 03, 2020 at 09:31:42PM +0530, Sumit Garg wrote: > > > > > Add support for TEE based trusted keys where TEE provides the functionality > > > > > to seal and unseal trusted keys using hardware unique key. Also, this is > > > > > an alternative in case platform doesn't possess a TPM device. > > > > > > > > > > This patch-set has been tested with OP-TEE based early TA which is already > > > > > merged in upstream [1]. > > > > > > > > Is the new RPI400 computer a platform that can be used for testing > > > > patch sets like this? I've been looking for a while something ARM64 > > > > based with similar convenience as Intel NUC's, and on the surface > > > > this new RPI product looks great for kernel testing purposes. > > > > > > Here [1] is the list of supported versions of Raspberry Pi in OP-TEE. > > > The easiest approach would be to pick up a supported version or else > > > do an OP-TEE port for an unsupported one (which should involve minimal > > > effort). > > > > > > [1] https://optee.readthedocs.io/en/latest/building/devices/rpi3.html#what-versions-of-raspberry-pi-will-work > > > > > > -Sumit > > > > If porting is doable, then I'll just order RPI 400, and test with QEMU > > up until either I port OP-TEE myself or someone else does it. > > > > For seldom ARM testing, RPI 400 is really convenient device with its > > boxed form factor. > > I'm now a proud owner of Raspberry Pi 400 home computer :-) > > I also found instructions on how to boot a custom OS from a USB stick: > > https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md > > Also, my favorite build system BuildRoot has bunch of of the shelf > configs: > > ➜ buildroot-sgx (master) ✔ ls -1 configs | grep raspberry > raspberrypi0_defconfig > raspberrypi0w_defconfig > raspberrypi2_defconfig > raspberrypi3_64_defconfig > raspberrypi3_defconfig > raspberrypi3_qt5we_defconfig > raspberrypi4_64_defconfig > raspberrypi4_defconfig > raspberrypi_defconfig > > I.e. I'm capable of compiling kernel and user space and boot it up > with it. > > Further, I can select this compilation option: > > BR2_TARGET_OPTEE_OS: │ > │ > OP-TEE OS provides the secure world boot image and the trust │ > application development kit of the OP-TEE project. OP-TEE OS │ > also provides generic trusted application one can embedded │ > into its system. │ > │ > http://github.com/OP-TEE/optee_os > > Is that what I want? If I put this all together and apply your patches, > should the expectation be that I can use trusted keys? > Firstly you need to do an OP-TEE port for RPI 400 (refer here [1] for guidelines). And then in order to boot up OP-TEE on RPI 400, you can refer to Raspberry Pi 3 build instructions [2]. [1] https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html [2] https://optee.readthedocs.io/en/latest/building/devices/rpi3.html#build-instructions > Please note that I had a few remarks about your patches (minor but need > to be fixed), but this version is already solid enough for testing. > Sure, I will incorporate your remarks and Randy's documentation comments in the next version. -Sumit > /Jarkko ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v8 0/4] Introduce TEE based Trusted Keys support @ 2020-11-03 16:01 Sumit Garg 2020-11-05 5:07 ` Jarkko Sakkinen 0 siblings, 1 reply; 6+ messages in thread From: Sumit Garg @ 2020-11-03 16:01 UTC (permalink / raw) To: op-tee [-- Attachment #1: Type: text/plain, Size: 3133 bytes --] Add support for TEE based trusted keys where TEE provides the functionality to seal and unseal trusted keys using hardware unique key. Also, this is an alternative in case platform doesn't possess a TPM device. This patch-set has been tested with OP-TEE based early TA which is already merged in upstream [1]. [1] https://github.com/OP-TEE/optee_os/commit/f86ab8e7e0de869dfa25ca05a37ee070d7e5b86b Changes in v8: 1. Added static calls support instead of indirect calls. 2. Documented trusted keys source module parameter. 3. Refined patch #1 commit message discription. 4. Addressed misc. comments on patch #2. 5. Added myself as Trusted Keys co-maintainer instead. 6. Rebased to latest tpmdd master. Changes in v7: 1. Added a trusted.source module parameter in order to enforce user's choice in case a particular platform posses both TPM and TEE. 2. Refine commit description for patch #1. Changes in v6: 1. Revert back to dynamic detection of trust source. 2. Drop author mention from trusted_core.c and trusted_tpm1.c files. 3. Rebased to latest tpmdd/master. Changes in v5: 1. Drop dynamic detection of trust source and use compile time flags instead. 2. Rename trusted_common.c -> trusted_core.c. 3. Rename callback: cleanup() -> exit(). 4. Drop "tk" acronym. 5. Other misc. comments. 6. Added review tags for patch #3 and #4. Changes in v4: 1. Pushed independent TEE features separately: - Part of recent TEE PR: https://lkml.org/lkml/2020/5/4/1062 2. Updated trusted-encrypted doc with TEE as a new trust source. 3. Rebased onto latest tpmdd/master. Changes in v3: 1. Update patch #2 to support registration of multiple kernel pages. 2. Incoporate dependency patch #4 in this patch-set: https://patchwork.kernel.org/patch/11091435/ Changes in v2: 1. Add reviewed-by tags for patch #1 and #2. 2. Incorporate comments from Jens for patch #3. 3. Switch to use generic trusted keys framework. Sumit Garg (4): KEYS: trusted: Add generic trusted keys framework KEYS: trusted: Introduce TEE based Trusted Keys doc: trusted-encrypted: updates with TEE as a new trust source MAINTAINERS: Add myself as Trusted Keys co-maintainer Documentation/admin-guide/kernel-parameters.txt | 12 + Documentation/security/keys/trusted-encrypted.rst | 203 +++++++++++-- MAINTAINERS | 2 + include/keys/trusted-type.h | 47 +++ include/keys/trusted_tee.h | 55 ++++ include/keys/trusted_tpm.h | 17 +- security/keys/trusted-keys/Makefile | 2 + security/keys/trusted-keys/trusted_core.c | 354 ++++++++++++++++++++++ security/keys/trusted-keys/trusted_tee.c | 278 +++++++++++++++++ security/keys/trusted-keys/trusted_tpm1.c | 336 ++++---------------- 10 files changed, 979 insertions(+), 327 deletions(-) create mode 100644 include/keys/trusted_tee.h create mode 100644 security/keys/trusted-keys/trusted_core.c create mode 100644 security/keys/trusted-keys/trusted_tee.c -- 2.7.4 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v8 0/4] Introduce TEE based Trusted Keys support 2020-11-03 16:01 Sumit Garg @ 2020-11-05 5:07 ` Jarkko Sakkinen 2020-11-06 9:32 ` Sumit Garg 0 siblings, 1 reply; 6+ messages in thread From: Jarkko Sakkinen @ 2020-11-05 5:07 UTC (permalink / raw) To: op-tee [-- Attachment #1: Type: text/plain, Size: 3632 bytes --] On Tue, Nov 03, 2020 at 09:31:42PM +0530, Sumit Garg wrote: > Add support for TEE based trusted keys where TEE provides the functionality > to seal and unseal trusted keys using hardware unique key. Also, this is > an alternative in case platform doesn't possess a TPM device. > > This patch-set has been tested with OP-TEE based early TA which is already > merged in upstream [1]. Is the new RPI400 computer a platform that can be used for testing patch sets like this? I've been looking for a while something ARM64 based with similar convenience as Intel NUC's, and on the surface this new RPI product looks great for kernel testing purposes. /Jarkko > > [1] https://github.com/OP-TEE/optee_os/commit/f86ab8e7e0de869dfa25ca05a37ee070d7e5b86b > > Changes in v8: > 1. Added static calls support instead of indirect calls. > 2. Documented trusted keys source module parameter. > 3. Refined patch #1 commit message discription. > 4. Addressed misc. comments on patch #2. > 5. Added myself as Trusted Keys co-maintainer instead. > 6. Rebased to latest tpmdd master. > > Changes in v7: > 1. Added a trusted.source module parameter in order to enforce user's > choice in case a particular platform posses both TPM and TEE. > 2. Refine commit description for patch #1. > > Changes in v6: > 1. Revert back to dynamic detection of trust source. > 2. Drop author mention from trusted_core.c and trusted_tpm1.c files. > 3. Rebased to latest tpmdd/master. > > Changes in v5: > 1. Drop dynamic detection of trust source and use compile time flags > instead. > 2. Rename trusted_common.c -> trusted_core.c. > 3. Rename callback: cleanup() -> exit(). > 4. Drop "tk" acronym. > 5. Other misc. comments. > 6. Added review tags for patch #3 and #4. > > Changes in v4: > 1. Pushed independent TEE features separately: > - Part of recent TEE PR: https://lkml.org/lkml/2020/5/4/1062 > 2. Updated trusted-encrypted doc with TEE as a new trust source. > 3. Rebased onto latest tpmdd/master. > > Changes in v3: > 1. Update patch #2 to support registration of multiple kernel pages. > 2. Incoporate dependency patch #4 in this patch-set: > https://patchwork.kernel.org/patch/11091435/ > > Changes in v2: > 1. Add reviewed-by tags for patch #1 and #2. > 2. Incorporate comments from Jens for patch #3. > 3. Switch to use generic trusted keys framework. > > Sumit Garg (4): > KEYS: trusted: Add generic trusted keys framework > KEYS: trusted: Introduce TEE based Trusted Keys > doc: trusted-encrypted: updates with TEE as a new trust source > MAINTAINERS: Add myself as Trusted Keys co-maintainer > > Documentation/admin-guide/kernel-parameters.txt | 12 + > Documentation/security/keys/trusted-encrypted.rst | 203 +++++++++++-- > MAINTAINERS | 2 + > include/keys/trusted-type.h | 47 +++ > include/keys/trusted_tee.h | 55 ++++ > include/keys/trusted_tpm.h | 17 +- > security/keys/trusted-keys/Makefile | 2 + > security/keys/trusted-keys/trusted_core.c | 354 ++++++++++++++++++++++ > security/keys/trusted-keys/trusted_tee.c | 278 +++++++++++++++++ > security/keys/trusted-keys/trusted_tpm1.c | 336 ++++---------------- > 10 files changed, 979 insertions(+), 327 deletions(-) > create mode 100644 include/keys/trusted_tee.h > create mode 100644 security/keys/trusted-keys/trusted_core.c > create mode 100644 security/keys/trusted-keys/trusted_tee.c > > -- > 2.7.4 > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v8 0/4] Introduce TEE based Trusted Keys support 2020-11-05 5:07 ` Jarkko Sakkinen @ 2020-11-06 9:32 ` Sumit Garg 0 siblings, 0 replies; 6+ messages in thread From: Sumit Garg @ 2020-11-06 9:32 UTC (permalink / raw) To: op-tee [-- Attachment #1: Type: text/plain, Size: 4212 bytes --] On Thu, 5 Nov 2020 at 10:37, Jarkko Sakkinen <jarkko@kernel.org> wrote: > > On Tue, Nov 03, 2020 at 09:31:42PM +0530, Sumit Garg wrote: > > Add support for TEE based trusted keys where TEE provides the functionality > > to seal and unseal trusted keys using hardware unique key. Also, this is > > an alternative in case platform doesn't possess a TPM device. > > > > This patch-set has been tested with OP-TEE based early TA which is already > > merged in upstream [1]. > > Is the new RPI400 computer a platform that can be used for testing > patch sets like this? I've been looking for a while something ARM64 > based with similar convenience as Intel NUC's, and on the surface > this new RPI product looks great for kernel testing purposes. Here [1] is the list of supported versions of Raspberry Pi in OP-TEE. The easiest approach would be to pick up a supported version or else do an OP-TEE port for an unsupported one (which should involve minimal effort). [1] https://optee.readthedocs.io/en/latest/building/devices/rpi3.html#what-versions-of-raspberry-pi-will-work -Sumit > > /Jarkko > > > > > [1] https://github.com/OP-TEE/optee_os/commit/f86ab8e7e0de869dfa25ca05a37ee070d7e5b86b > > > > Changes in v8: > > 1. Added static calls support instead of indirect calls. > > 2. Documented trusted keys source module parameter. > > 3. Refined patch #1 commit message discription. > > 4. Addressed misc. comments on patch #2. > > 5. Added myself as Trusted Keys co-maintainer instead. > > 6. Rebased to latest tpmdd master. > > > > Changes in v7: > > 1. Added a trusted.source module parameter in order to enforce user's > > choice in case a particular platform posses both TPM and TEE. > > 2. Refine commit description for patch #1. > > > > Changes in v6: > > 1. Revert back to dynamic detection of trust source. > > 2. Drop author mention from trusted_core.c and trusted_tpm1.c files. > > 3. Rebased to latest tpmdd/master. > > > > Changes in v5: > > 1. Drop dynamic detection of trust source and use compile time flags > > instead. > > 2. Rename trusted_common.c -> trusted_core.c. > > 3. Rename callback: cleanup() -> exit(). > > 4. Drop "tk" acronym. > > 5. Other misc. comments. > > 6. Added review tags for patch #3 and #4. > > > > Changes in v4: > > 1. Pushed independent TEE features separately: > > - Part of recent TEE PR: https://lkml.org/lkml/2020/5/4/1062 > > 2. Updated trusted-encrypted doc with TEE as a new trust source. > > 3. Rebased onto latest tpmdd/master. > > > > Changes in v3: > > 1. Update patch #2 to support registration of multiple kernel pages. > > 2. Incoporate dependency patch #4 in this patch-set: > > https://patchwork.kernel.org/patch/11091435/ > > > > Changes in v2: > > 1. Add reviewed-by tags for patch #1 and #2. > > 2. Incorporate comments from Jens for patch #3. > > 3. Switch to use generic trusted keys framework. > > > > Sumit Garg (4): > > KEYS: trusted: Add generic trusted keys framework > > KEYS: trusted: Introduce TEE based Trusted Keys > > doc: trusted-encrypted: updates with TEE as a new trust source > > MAINTAINERS: Add myself as Trusted Keys co-maintainer > > > > Documentation/admin-guide/kernel-parameters.txt | 12 + > > Documentation/security/keys/trusted-encrypted.rst | 203 +++++++++++-- > > MAINTAINERS | 2 + > > include/keys/trusted-type.h | 47 +++ > > include/keys/trusted_tee.h | 55 ++++ > > include/keys/trusted_tpm.h | 17 +- > > security/keys/trusted-keys/Makefile | 2 + > > security/keys/trusted-keys/trusted_core.c | 354 ++++++++++++++++++++++ > > security/keys/trusted-keys/trusted_tee.c | 278 +++++++++++++++++ > > security/keys/trusted-keys/trusted_tpm1.c | 336 ++++---------------- > > 10 files changed, 979 insertions(+), 327 deletions(-) > > create mode 100644 include/keys/trusted_tee.h > > create mode 100644 security/keys/trusted-keys/trusted_core.c > > create mode 100644 security/keys/trusted-keys/trusted_tee.c > > > > -- > > 2.7.4 > > > > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-12-08 11:51 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] < <CAFA6WYPetvod-Wov2n_L5TL771j+-kt+_csyWYT-uM=haEKMZQ@mail.gmail.com>
2020-11-06 14:52 ` [PATCH v8 0/4] Introduce TEE based Trusted Keys support Jarkko Sakkinen
2020-12-04 5:16 ` Jarkko Sakkinen
2020-12-08 11:51 ` Sumit Garg
2020-11-03 16:01 Sumit Garg
2020-11-05 5:07 ` Jarkko Sakkinen
2020-11-06 9:32 ` Sumit Garg
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox