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 ?
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 ?
1. I notice somebody has already added a save_gd()/restore_gd() pair
2. How about a save_jr()/restore_jr() pair and
3. 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
1. Constraining the use case of CONFIG_OPTEE=y &&
authenticate(encrypted-dek-blob);
2. 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.
---
bod
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
