Hi,
Looking at platform/ext/common/tfm_hal_platform_v8m.c, this line stands out as quite odd:
.veneer_limit =
(uint32_t)®ION_NAME(Image$$, VENEER_ALIGN, $$Limit) - 1,
It seems that the various "$$Limit" values that exist within TF-M aren't actually "limits" in the usual meaning of the word (the last value within the range) but are instead the first value *outside* the range. Elsewhere in TF-M we do seem to use the word "limit" in the conventional way.
I worry that this could lead to errors around the boundaries, particularly as some functions we use to check ranges take a "limit" parameter - we could easily see code that looks correct but that actual does the wrong thing, like
ARM_MPC_ConfigRegion(REGION_NAME(Image$$, ER_VENEER, $$Base),
REGION_NAME(Image$$, VENEER_ALIGN, $$Limit, attr);
Or a similar call to check_address_range().
For example, I suspect that this is a bug in the Nuvoton M2354 platform caused by this issue:
platform/ext/target/nuvoton/m2354/target_cfg.c:
.veneer_limit = (uint32_t)®ION_NAME(Image$$, VENEER_ALIGN, $$Limit),
It's obviously a big thing to fix, but it does look to me to be worthwhile...
Chris Brand
Cypress Semiconductor (Canada), Inc.
An Infineon Technologies Company
Sr Prin Software Engr
CSCA CSS ICW SW PSW 1
Office: +1 778 234 0515
Chris.Brand(a)infineon.com<mailto:Chris.Brand@infineon.com>
International Place 13700
V6V 2X8 Richmond
Canada
www.infineon.com<www.cypress.com> www.cypress.com<http://www.cypress.com> Discoveries<http://www.infineon.com/discoveries> Facebook<http://www.facebook.com/infineon> Twitter<http://www.twitter.com/Infineon> LinkedIn<http://www.linkedin.com/company/infineon-technologies>
Part of your life. Part of tomorrow.
NOTICE: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material of Infineon Technologies AG and its affiliated entities which is for the exclusive use of the individual designated above as the recipient. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact immediately the sender by returning e-mail and delete the material from any computer. If you are not the specified recipient, you are hereby notified that all disclosure, reproduction, distribution or action taken on the basis of this message is prohibited.
Hi All,
it is spotted that FLIH tests failed recently and blocks CI verification. We need to dig into it and found the reason. To avoid blocking the daily work, we will temporarily turn FLIH tests off, and recover when solved.
Background: Sometimes the test application stuck in waiting for interrupts even the interrupt is properly configured. If someone got solutions for similar problems please share your info, thank you in advance.
Best Regards,
Xinyu
Hi all,
After having some troubles with isolation level 3 I have noticed that MbedTLS (mbedcrypto) data/code is not properly linked to crypto partition.
Currently mbed crypto data/code is placed into SPM data/code section in level 3 isolation. This is a problem if optional L3 FFM boundaries are applied (when SPM is isolated from PSA RoT partition (Crypto in particular)) because in this case crypto partition does not have access to the mbedcrypto code/data that is located in SPM code/data sections.
I think Mbedcrypto data/code should be linked to crypto partition and placed in crypto partition linker section. This way it will be protected to be accessible by crypto partition.
So my question is whether this should be fixed or there are objectives to not fix this issue?
If fix is needed I would like to discuss possible ways to solve this problem.
Regards,
Bohdan Hunko
Cypress Semiconductor Ukraine
Engineer
CSUKR CSS ICW SW FW
Mobile: +38099 50 19 714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
TF-M Open CI is blocked. Please avoid starting new jobs as it would not start and can be cancelled for restart.
We'll let you know once it is back to normal.
Sorry for this news,
Anton
Hi,
I have been working on TZ stuff recently and found small problem in an521 platform protections.
The problem is in SAU config.
sau_cfg in platform/ext/target/arm/mps2/an521/target_cfg.c has entry for NSPE code:
{
((uint32_t)NS_PARTITION_START),
((uint32_t)NS_PARTITION_START +
NS_PARTITION_SIZE - 1),
false,
},
Where both NS_PARTITION_START and NS_PARTITION_SIZE are 32 bytes aligned, which means that when 1 is subtracted lower 5 bits are getting set to 1, for example:
0x1000_0000 + 0x1000 - 1 = 0x10000FFF
Then in sau_and_idau_cfg() function lower 5 bits are cleared by the mask:
sau_cfg[i].RLAR & SAU_RLAR_LADDR_Msk
This means that in reality highest 32 bytes of NSPE are protected as Secure in SAU.
Same problem is present for SECONDARY_PARTITION_SIZE SAU entry.
This is not huge problem, but still worth fixing.
I believe other arm and TZ platforms may also have this bug, but I haven't checked in details.
Regards,
Bohdan Hunko
Cypress Semiconductor Ukraine
Engineer
CSUKR CSS ICW SW FW
Mobile: +38099 50 19 714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
Hi,
It is reported in a few platforms that the SAU NSC region limit is set 32 bytes larger than expected because the value set did not match the hardware characteristics. The SAU.LADDR treats the last 5 bits as 0x1 which means a valid limit address should be the value with 0x1f in the last bits, take an example if the region starts at 0x1000 with size 0x100, the limit address should be set as 0x1000 + 0x100 - 0x20 which is 0x10E0. The practical region address range is [0x1000 - 0x10FF], all addresses >= 0x1000 and <= 0x10FF would be treated as hitting a region.
If your address and size are 32 bytes aligned already, you can just adjust the limit with "start_address + size - 1", as the tailing 5 bits would be masked. Take this patch as an example:
Platform: Fix the Veneer SAU region for Arm platforms (I2692f318) · Gerrit Code Review (trustedfirmware.org)<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/18547>
Now only the NSC region is affected, but please check your platform if you are using SAU to see if each region is set properly.
Thanks.
/Ken
Hi all,
TFM in current implementation has following condition in tfm_ns_mailbox.h
#if !defined(TFM_MULTI_CORE_NS_OS) && (NUM_MAILBOX_QUEUE_SLOT > 1)
#error "NUM_MAILBOX_QUEUE_SLOT should be set to 1 for NS bare metal environment"
#endif
I was wondering whether this is real restriction or this check can be removed.
I am not mailbox expert so please correct me if I am wrong.
Quick look at the code shows that it should be ok to have multi slot queue in bare metal environment, with the note that only one slot will be used (as there is only one thread).
If my understanding is correct then it would be nice to remove this compile time check (I am happy to provide a patch for it).
We need this change because we deliver TFM as prebuilt binary and interface (one installed after the build). This binary is built with NUM_MAILBOX_QUEUE_SLOT = 4, so in current implementation it cant be used in bare metal environment.
Regards,
Bohdan Hunko
Cypress Semiconductor Ukraine
Engineer
CSUKR CSS ICW SW FW
Mobile: +38099 50 19 714
Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>
