Hi,
(in context of testing BTI support when OP-TEE is loaded as a secure partition on top of SEL2/Hafnium)
I read through the OP-TEE documentation, and would like to confirm: CFG_CORE_BTI=y seems mandatorily required to support BTI in TAs. It means we cannot enable independently BTI for TAs and 'disable' for TEE core, is this correct?
Interestingly I noticed I can build with CFG_CORE_BTI=n and CTG_TA_BTI=y but I appreciate the end result is that the TA get BTI landpads but is not effectively leveraging the arch extension because code page aren't guarde if TEE core option isn't enabled.
I was investigating a way to omit building a specific toolchain as it appears to be required when CFG_CORE_BTI=y, but I'll go ahead if there's no way round. Out of curiosity is OP-TEE core pulling gcc libraries? And if yes, which kind? I naively thought OP-TEE core would be freestanding or be independent from toolchain libs.
Thanks & Regards, Olivier.
Hi,
(in context of testing MTE support when OP-TEE is loaded as a secure partition on top of SEL2/Hafnium)
I appreciate MTE support is fresh starting with v3.18, bear with me if I missed details:
1/ noticed using both CFG_TA_PAUTH=y CFG_MEMTAG=y (if permitted) may break the build
diff --git a/core/tee/tee_svc.c b/core/tee/tee_svc.c index 03bb174a..59f8afae 100644 --- a/core/tee/tee_svc.c +++ b/core/tee/tee_svc.c @@ -365,7 +365,7 @@ const struct tee_props tee_propset_tee[] = { .name = "org.trustedfirmware.optee.cpu.feat_pauth_implemented", .prop_type = USER_TA_PROP_TYPE_BOOL, .get_prop_func = get_prop_feat_pauth_implemented - } + }, #endif #if MEMTAG_IS_ENABLED {
2/ there seems to be a problem with CFG_CORE_SEL2_SPMC=y CFG_MEMTAG=y when it comes to build AArch32 TAs. I guess CNTVCT only exists with AArch64:
In file included from lib/libutils/ext/arch/arm/memtag.c:6: lib/libutee/include/arm_user_sysreg.h: In function 'barrier_read_counter_timer': lib/libutee/include/arm_user_sysreg.h:28:9: error: implicit declaration of function 'read_cntvct'; did you mean 'read_cntpct'? [-Werror=implicit-function-declaration] 28 | return read_cntvct(); | ^~~~~~~~~~~ | read_cntpct lib/libutee/include/arm_user_sysreg.h:28:9: warning: nested extern declaration of 'read_cntvct' [-Wnested-externs]
3/ there seems to be a more general problem with using cache operations affecting tags starting with boot_init_memtag The DC GVA operation triggers an EL1 data abort with DFSC stating alignment fault. I will continue debugging (on FVP) but I thought worth noting, and more importantly confirming if this works on your side (perhaps on qemu?). SEL2 may miss disabling traps for certain cache operations.
4/ still about boot_init_memtag, it attempts clearing tags on the whole range of TEE_RAM_START / TEE_RAM_PH_SIZE but it seems memory pages aren't marked as normal tagged memory so I wonder if it works as expected. It may be harmless though. Let me know if I miss something.
Thanks & Regards, Olivier.
Hi Olivier,
On Wed, Jul 13, 2022 at 3:39 PM Olivier Deprez Olivier.Deprez@arm.com wrote:
Hi,
(in context of testing MTE support when OP-TEE is loaded as a secure partition on top of SEL2/Hafnium)
I appreciate MTE support is fresh starting with v3.18, bear with me if I missed details:
1/ noticed using both CFG_TA_PAUTH=y CFG_MEMTAG=y (if permitted) may break the build
diff --git a/core/tee/tee_svc.c b/core/tee/tee_svc.c index 03bb174a..59f8afae 100644 --- a/core/tee/tee_svc.c +++ b/core/tee/tee_svc.c @@ -365,7 +365,7 @@ const struct tee_props tee_propset_tee[] = { .name = "org.trustedfirmware.optee.cpu.feat_pauth_implemented", .prop_type = USER_TA_PROP_TYPE_BOOL, .get_prop_func = get_prop_feat_pauth_implemented
}
},#endif #if MEMTAG_IS_ENABLED {
Thanks for reporting, addressed in https://github.com/OP-TEE/optee_os/pull/5467. Feel free to give a Reported-by: if you want.
Hello Olivier,
On Wed, Jul 13, 2022 at 3:20 PM Olivier Deprez Olivier.Deprez@arm.com wrote:
Hi,
(in context of testing BTI support when OP-TEE is loaded as a secure partition on top of SEL2/Hafnium)
I read through the OP-TEE documentation, and would like to confirm: CFG_CORE_BTI=y seems mandatorily required to support BTI in TAs. It means we cannot enable independently BTI for TAs and 'disable' for TEE core, is this correct?
Interestingly I noticed I can build with CFG_CORE_BTI=n and CTG_TA_BTI=y but I appreciate the end result is that the TA get BTI landpads but is not effectively leveraging the arch extension because code page aren't guarde if TEE core option isn't enabled.
That is correct. I don't remember if there was a strong reason for this choice. Maybe we could introduce a new CFG to allow OP-TEE OS to enforce BTI in TAs (SEL0) while not using BTI in itself (SEL1), but it might be more complicated than it sounds (depending on how page tables are configured to access SEL0 from SEL1).
I was investigating a way to omit building a specific toolchain as it appears to be required when CFG_CORE_BTI=y, but I'll go ahead if there's no way round.
Currently, there is no other way indeed. I suppose you know how to build a toolchain but just in case I posted a small script here: https://github.com/OP-TEE/optee_os/pull/4967#issuecomment-996987581
Out of curiosity is OP-TEE core pulling gcc libraries? And if yes, which kind? I naively thought OP-TEE core would be freestanding or be independent from toolchain libs.
It does pull libgcc.a for some builtins and floating point ABIs IIRC.
op-tee@lists.trustedfirmware.org
-
Jérôme Forissier -
Olivier Deprez