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-versi...
-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...
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-inst...
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