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>
Hi,
FYI. TF-M Open CI will be on maintenance on 16th Dec.
Time to stop triggering new jobs: 2022-12-16 18:00 UTC
Maintenance end time: 2022-12-16 22:00 UTC
Regards,
Xinyu
From: Kelley Spoon via Tf-openci-triage <tf-openci-triage(a)lists.trustedfirmware.org>
Sent: Thursday, December 15, 2022 4:16 AM
To: tf-openci(a)lists.trustedfirmware.org; tf-openci-triage(a)lists.trustedfirmware.org
Subject: [Tf-openci-triage] [Maintenance] - ci.trustedfirmware.org down time 2022-12-16
Hello All,
The server will be offline to start a maintenance window on 2022-12-16 at 20:00 UTC. Jenkins will be put into "Shutdown Mode" at 2022-12-16 18:00 UTC to stop accepting new jobs and allow executing tasks to complete.
This downtime is required to execute an upgrade for Jenkins to address some security advisories and enable new functionality.
Emails will be sent prior to and following the upgrade to provide status reports.
Start: 2022 12-16 20:00 UTC
End: 2022-12-16 22:00 UTC
Regards,
--
Kelley Spoon <kelley.spoon(a)linaro.org<mailto:kelley.spoon@linaro.org>>
Hello,
I am pleased to announce the release of TF-M v1.7.0.
New major features are:
* Unified API to PSA Service access implementing PSA FF-M and FF-M v1.1 extension
* The Library model is deprecated and removed
* Improve and simplify TF-M configurability
* Introduce the base configuration for TF-M essential
* Shift config options from CMake to C header files for PSA modules and platforms
* Employ Kconfig as a configuration tool and dependency tracker
* Configurable stack size for Secure Partitions
* Add TF-M Medium-ARoT-less profile
* MM-IOVEC deployed in PSA Secure Partitions
* PSA FWU API updated to v1.0
* Mbed TLS updated to v3.2.1
* Code size further optimised
* The manifest tool is decoupled with the build system
* Improvements in the Code size analysis tool
* Updated documentation
It is tagged with TF-Mv1.7.0<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tag/?h=TF-Mv1.7…>.
The release time changes will be integrated with the main branch shortly.
Many thanks everyone for contribution, review and support this milestone.
Anton
Hello,
We are currently integrating a protocol stack with a Radio IRQ in a TrustZone environment with the TF-M as the SPE.
The Radio IRQ requires fast treatment from our protocol stack, the need is to have the Radio IRQ handled with the lowest latency possible.
The fact that all the IRQs in the NonSecure side can't preempt IRQ on the Secure side in the TF-M design leads us to the following possibilities with several limitations:
1. Having the Radio IRQ as the lowest priority on the NonSecure side: if a user creates its own partition with an IRQ (which by design will have a lower priority of our IRQ because it's in the Secure side), it could potentially delay for too long the Radio IRQ processing, thus leading to Radio protocol related issues.
1. Having the protocol stack related to the Radio IRQ in a partition directly in Secure side : this configuration is highly disputable from a Security point of view, the possibility to introduce a Security flaw with the protocol stack in Secure being too high.
1. Having the Radio IRQ in a Secure partition (FLIH for faster handling) and forward the IRQ handling to the protocol stack in the NonSecure side, all modifications to the NVIC registers of this Radio IRQ (enable, disable, priority level) requested by the protocol stack in NonSecure side will have to be done through this partition with TF-M API calls (SFN backend for execution performances) : This configuration will probably led to issues such as reentrancy on the TF-M (for example if the TF-M forward an IRQ to the NonSecure which then calls TF-M API for Radio NVIC register manipulations) or having to call TF-M from NonSecure in handler mode.
Do you already have experienced with this type of problematics, or do you see TF-M configurations which will be more suitable for such a use-case ?
Thank you,
Regards,
Romain
ST Restricted
