Closed fr0st61te closed 1 year ago
We also need that kas option file to enable the special firmware build. And that setup should exclude signing the firmware, ie. detect and reject secure boot mode. With that safety measure, I think we could offer to build the special firmware also via kconfig. That would additionally provide the change to explain the usage and constraints in the help entry.
We also need that kas option file to enable the special firmware build.
kas-iot2050-boot-pg1-optee-rpmbw.yml kas-iot2050-boot-pg2-optee-rpmbw.yml ? Or something else?
Do we need pg1/2 differentiation for that? Officially supported will be pg2 only anyway, but we can leave that door technically open. Otherwise maybe kas/opt/rpbm-setup.yml
?
What is now the actual testing status of these OP-TEE patches in the backported environment (3.16.0, rather than master)? Can we trust that? Or should we move at least to 3.17.0 (upstream merged them not that many commits after the release)?
What is now the actual testing status of these OP-TEE patches in the backported environment (3.16.0, rather than master)? Can we trust that? Or should we move at least to 3.17.0 (upstream merged them not that many commits after the release)?
3.16.0 works fine with backported patches. 3.17.0 and 3.17.0-rc1 don't have these patches, probably in new rc or .18 it will be available.
Last version of commits is not tested with 3.18.0, will do it on the current week.
Testing on PG2, below error print could be confusing.
Security ID 0xc8beb00d-0x7f55c02e
Security policy: none
No options found, skip.
Validating FIT...
Loading image atf...
Loading image tee...
Loading image spl...
Loading image k3-am65-iot2050-spl.dtb...
NOTICE: BL31: v2.6(release):
NOTICE: BL31: Built : 02:56:00, Sep 14 2022
I/TC:
I/TC: OP-TEE version: 3.18.0 (gcc version 10.2.1 20210110 (Debian 10.2.1-6)) #1 Mon Sep 26 02:11:06 UTC 2022 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html
I/TC: Primary CPU initializing
I/TC: SYSFW ABI: 3.1 (firmware rev 0x0015 '21.9.1--v2021.09a (Terrific Lla')
I/TC: HUK Initialized
I/TC: Activated SA2UL device
E/TC:0 0 ti_sci_get_response:120 Message not acknowledged
E/TC:0 0 ti_sci_do_xfer:149 Failed to get response (-65536)
I/TC: Enabled firewalls for SA2UL TRNG device
I/TC: SA2UL TRNG initialized
I/TC: SA2UL Drivers initialized
I/TC: Primary CPU switching to normal world boot
This happens during Line 64 of core/arch/arm/plat-k3/drivers/sa2ul.c
/* Try to claim the SA2UL firewall for ourselves */
ret = ti_sci_change_fwl_owner(fwl_id, sa2ul_region, owner_index,
&owner_privid, &owner_permission_bits);
if (ret) {
/*
* This is not fatal, it just means we are on an HS device
* where the DMSC already owns the SA2UL. On GP we need
* to do additional setup for access permissions below.
*/
DMSG("Could not change SA2UL firewall owner");
}
So it is expected on HS device. However, it is still confusing if I am a end user.
Already reported to upstream, see: https://github.com/OP-TEE/optee_os/issues/5552 & https://github.com/OP-TEE/optee_os/pull/5328/files#r979529747
Seems CONFIG_CMD_OPTEE_RPMB
is missing from u-boot?
I think we should have some wikis regarding how to program the RPMB key, just as what we've done for secure boot otp key programming.
Test passed on PG2 device.
This patch provides rpmb support for IOT2050 on am65 which includes:
Signed-off-by: Ivan Mikhaylov ivan.mikhaylov@siemens.com