Hi Bryan,
Seems that my last email didn't get in U-Boot mailing list, I'm sending again.
Em sáb, 6 de abr de 2019 às 12:21, Bryan O'Donoghue bryan.odonoghue@linaro.org escreveu:
On 05/04/2019 17:16, Breno Matheus Lima wrote:
if ((IS_ENABLED(CONFIG_OPTEE) ||!IS_ENABLED(CONFIG_ARMV7_BOOT_SEC_DEFAULT)) &&!IS_ENABLED(CONFIG_CMD_DEKBLOB)) {So.
How does this patch work if you want to do HABv4 encrypted authentication of an OP-TEE image prior to booting it ?
Thanks for your comments and for pointing this out, I agree that this can be an issue for OP-TEE users that may want to decrypt additional boot images at U-Boot level.
The main issue is that all users are currently impacted in first authentication/decryption executed at BootROM level:
BootROM -> HABv4 -> U-Boot
We may need to come up with a solution suitable for all use cases
i.e.
You'll switch the job-ring ownership over to non-trusted world, call HAB and the BootROM will fail to authenticate.
How about we improve the hab driver in u-boot ?
- I notice somebody has already added a save_gd()/restore_gd() pair
- How about a save_jr()/restore_jr() pair and
- a bootrom_jr_setup() ?
In pseudocode then
do_hab_auth() { save_jr(); // save current job-ring context bootrom_jr_setup(); // set job-ring to bootrom mode hab_rvt_authenticate(); restore_jr(); // restore previous job-ring context }
That gets us out of the nasty business of
Constraining the use case of CONFIG_OPTEE=y && authenticate(encrypted-dek-blob);
Pushing changes into upstream OP-TEE for job-ring assignment
IMV - we should save and restore the job ring context so that all of this stuff will "just work"
That should work for
BootROM -> u-boot -> HABv4 auth(encryptedblob) -> Linux
and
BootROM -> u-boot -> run optee -> HABv4 auth(encrypted blob) -> Linux
Basically you've described and additional dependency the BootROM has, so lets just "switch context" prior to calling into the BootROM and restore to a default non-secure job-ring assignment after.
Yes, this can work for OP-TEE users decrypting additional boot images at U-Boot level, however all users won't be able to authenticate/decrypt the initial boot image at BootROM level. Out of reset CAAM job rings are assigned to TrustZone secure world and BootROM code is expecting blobs generated by the same environment.
What about moving the job rings assignment to OP-TEE level? Something similar as we currently have in imx-optee-os project?
https://source.codeaurora.org/external/imx/imx-optee-os/tree/core/drivers/ca...
U-Boot is running in TrustZone secure world in most of targets, in my opinion it makes sense to have at least 1 job ring assigned to TrustZone secure world.
Best regards, Breno Lima