On Mon, Mar 11, 2019 at 01:43:19PM +0000, Tamas Ban via TF-M wrote:
>Please see the following link for a design proposal on anti-rollback protection in trusted boot:
>
>https://developer.trustedfirmware.org/w/tf_m/design/trusted_boot/rollback_p…
Somewhat related, as I've been working through a prototype
implementation of SUIT, the SUIT manifest also wants what they call a
"sequence number", which is a monotonically increasing number
associated with each version. They've kind of decided they don't want
to have to do anything like semantic version parsing as part of the
firmware upgrade.
I think this sequence number serves the same purpose as this security
counter (except that the sequence number is required to increase with
each software relase).
One of the goals of the MCUboot community is to make sure that however
the SUIT manifest is implemented, it must be semantically the same as
the existing TLV-format manifest. An easy solution is to just treat
the existing version as a 32-bit number (ignoring the build-id, which
I think is supposed to be the case, anyway).
As far as the possibility of re-using the same security counter value,
I don't think that is something that should be done. In general, it
isn't possible to know where security bugs will be found in an image.
If we always increase the security counter value, someone still
running the immediately following image will be prevented from rolling
back to the version with the security flaw, whereas if we reused the
values, it might be necessary to try to force them to upgrade to a new
version that has the counter increased.
Also, I think it is important to clarify that the security counter is
not required for anti-rollback, it only protects the anti-rollback
implementation from a specific threat: something that is able to
replace the primary firmware image outside of the control of the
bootloader. The cost is that implementing a security counter
generally requires specific hardware just for that purpose. An
entirely software anti-rollback protects against other threats,
including the common case of using the ordinary firmware upgrade
process.
David
Hi Andrej,
Your interpretation is correct: if NS client identification is disabled, all non-secure threads are assigned the default non-secure client id (-1).
That means that secure services cannot differentiate between various non-secure threads, i.e. they would all be provided the same access policies when requesting secure services.
This is in line with PSA Firmware Framework. As described in chapter 3.3.3 of PSA FF 1.0 beta Release 0, "In implementations where NSPE client_id values are provided by the SPM, the same negative client_id must be used for all connections."
Note that according to that specification each connection and message would still have their own unique handles - see chapter 3.3.4.
Note also that this does not impact the client ID assignments for secure partitions, so any service would be able to identify if it was called by a non-secure entity or a secure one, and if a secure one, then which one.
Let me know if you need further assistance in this matter.
Regards
Miklos
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: 25 April 2019 12:47
To: David Hu (Arm Technology China) <David.Hu(a)arm.com>
Cc: TF-M(a)lists.trustedfirmware.org
Subject: Re: [TF-M] [EXT] Re: TFM and FreeRTOS
Hi David,
OK. We may try to limit FreeRTOS to the case when it starts and runs only in non-secure world and its tasks will call secure world only via PSA/TFM API.
In this case, if I understand well, to avoid conflict for non-secure SVC, it is enough to disable TFM_NS_CLIENT_IDENTIFICATION.
It means that all user tasks will be assigned to the default user id = DEFAULT_NS_CLIENT_ID.
What does it mean? How does it limits the functionality? Is it OK from PSA point of view?
Thanks,
Andrej
-----Original Message-----
From: David Hu (Arm Technology China) <David.Hu(a)arm.com>
Sent: Thursday, April 25, 2019 11:26 AM
To: Andrej Butok <andrey.butok(a)nxp.com>; tf-m(a)lists.trustedfirmware.org
Subject: [EXT] Re: [TF-M] TFM and FreeRTOS
Caution: EXT Email
Hi Andrej,
I guess that you may ask about the SVCalls communication between secure world and non-secure world in FreeRTOS. If I misunderstood your question, please ignore the following.
In my very own opinion, FreeRTOS has a different concept of how to manage secure stack/context from TF-M does.
FreeRTOS prefers to allocate and manage a dedicated secure stack/context for each non-secure task requiring secure service. In its implementation, each time when it does context switch, it invokes SVCalls to also switch the secure stack/context for the next non-secure task. FreeRTOS implements several own APIs to accomplish those functionalities.
By contrast, TF-M as a trusted firmware, naturally, manages all the secure resource by its own. Therefore, there is no such dedicated stack in secure world mapping to each non-secure task. Currently, TF-M implements CMSIS RTOS thread context management APIs to execute some management work between non-secure world and secure world, on Armv8-M core.
Hope it can hlep you.
Best regards,
Hu Ziji
On 4/25/2019 3:45 PM, Andrej Butok via TF-M wrote:
> Hello,
>
> Do you know about any existing port of FreeRTOS (instead of RTX) to TFM? Did somebody a feasibility study?
> I have just started to look at it, and immediately detected a conflict, both are using Supervisor Calls (SVC) for own needs.
>
> Thanks,
> Andrej
>
>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi,
This is a proposal that introduces scheduling rules in TF-M.
Introduction:
On ArmV8-M CPUs, NSPE and SPE share the same physical processing element(PE). A TF-M enabled system need to be able to handle asynchronous events (interrupts) regardless of current security state of the PE; and that may lead to scheduling decisions. This introduces significant complexity into TF-M. To keep the integrity of (NSPE and SPE) schedulers and call paths between NSPE and SPE, following set of rules are imposed on the TF-M scheduler design.
https://developer.trustedfirmware.org/w/tf_m/design/cooperative_scheduling/
Feedback welcome!
Thanks,
Ashu
Hi All,
The parts that refer to the BASEPRI_NS register being set on return from Secure services has been removed from the document (marked with strikethrough), as the attack surfaces introduced by not doing it are mitigated by the veneer stack checking on secure function entry.
Sorry for the inconvenience.
Best regards,
Mate
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mate Toth-Pal via TF-M
Sent: 29 April 2019 15:21
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Non-secure interrupt handling design proposal
Hi All,
The design proposal for the Non-secure interrupt handling is available for review at the following link:
https://developer.trustedfirmware.org/w/tf_m/design/ns_interrupt_handling/
Please share your thoughts in this mail thread.
Thank you!
Best regards,
Mate
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi,
There was a cmake response file patch to fix the linker error especially in windows:
https://review.trustedfirmware.org/c/trusted-firmware-m/+/237
In this patch I set proper flags for linkers, but also enable response file as default, which caused some concerns about: is the response file option stable enough, will it break the build?
So I created an updated one, which just set correct response file switch for linkers, and do not enable response file as default. In the case if ARMCLANG response is enabled by cmake automatically, cmake could apply correct response flag for ARMCLANG:
https://review.trustedfirmware.org/c/trusted-firmware-m/+/925
Because they are pushed towards different branches, so a new gerrit item is generated which lost the history...The only difference with previous one is removed below line :
set(CMAKE_${lang}_USE_RESPONSE_FILE_FOR_OBJECTS 1)
The reason I raise this patch is because, this problem happens every time in my PC so I have to cherry-pick this patch before building anything. I had seen someone got the same issue, and want to check how you solve this.
Call for volunteers to help verifying this patch (925) in your side and provide feedback to ensure it will not break the building, is there anyone could help? Just cherry-pick this patch into your environment is OK.
Thanks.
-Ken
Hi all,
I've created a change as a follow-on from the mail discussion below to provide a design pattern proposal: IOCTL for platform-specific services.
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/951/
Brief problem statement:
Some platforms required services and HAL functions that were not generic to warrant their dedicated generic HAL API functions as that implied a requirement for *all* platforms to implement - essentially stub - the implementation if the functionality was not applicable to that platform. The existing solution doesn't scale so I propose to introduce a single mandatory function that serves as a platform-specific wrapper/arbiter for services that are specific to a single platform, or a family of similar platforms.
Note that at present the change IS the design proposal - I felt it would make more sense to present it this time as code changes and documentation updates instead of a single linear design document.
Let me know your thought in this mail thread for generic observations or on the review page for specific details of the implementation.
Thanks
Regards,
Miklos
-----Original Message-----
From: Michel JAOUEN <michel.jaouen(a)st.com>
Sent: 11 April 2019 17:38
To: Miklos Balint <Miklos.Balint(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: RE: Platform: Create platform service for pin functions
Hello,
You should detail your proposal with single entry.
It should help to implement the function really required for dedicated platform.
Regards
-----Original Message-----
From: Miklos Balint <Miklos.Balint(a)arm.com>
Sent: jeudi 11 avril 2019 17:28
To: Michel JAOUEN <michel.jaouen(a)st.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: RE: Platform: Create platform service for pin functions
Michel,
I agree there is a need for a more generic design pattern for such platform-specific features.
I think that there should be a single entry point for any platform specific service request to the platform/ directory and each platform should/could list the specific features it supports. Then the specific function type would be encoded in an invec to the service request.
But I think a more detailed design proposal is needed with enough room for discussion before committing to a new pattern, and I'd prefer to avoid introducing platform dependencies in the services/ folder. That folder should ideally just have an indirection across HAL to a platform-specific service request arbiter.
Any opinions or should I produce a more detailed proposal to show what I mean?
Regards
Miklos
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Michel JAOUEN via TF-M
Sent: 11 April 2019 13:57
To: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Platform: Create platform service for pin functions
I see that there is https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/825/
On review , it adds some dummy functions for the platform not requiring these services Can we think about introducing some configuration on platform basis.
As example , I post
https://review.trustedfirmware.org/#/c/trusted-firmware-m/+/854/
Best regards
From: Michel JAOUEN
Sent: mercredi 10 avril 2019 13:05
To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org>
Subject: Platform: Create platform service for pin functions
Hello,
I noticed the merge of this api, which seems require only for platform Musca_a.
This create the need to implement dummy functions for the other platform.
would it be better to make this configurable for each platform ?
I think for the interface connected to platform partition, it is important to have a flexibility.
As example some platform , may require an API requesting a pin to be configureable from non secure .
Best regards
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi Stanislav,
Thanks for reporting the issue. As the issue seems to be in the PSA Tests rather than TF-M, please can you report it directly to the psa-arch-tests project here https://github.com/arm-software/psa-arch-tests as we in the TF-M team do not maintain that code.
Best wishes,
Jamie
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Stanislav Jancik via TF-M
Sent: 25 April 2019 12:51
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] TF-M ARM GCC PSA Test 014 fail
Hi,
I use "7 2018-q2-update" ARMGCC compiler. The PSA Tests code works when it is compiled by ARMGLANG, but a fail occurs when the same code is compiled by ARMGCC.
Issue:
When TEST: 414 runs, I've got secure violation fault. See report bellow:
TEST: 414 | DESCRIPTION: Optional APIs not supported check [Info] Executing tests from non-secure Optional PS APIs are not supported.
[Check 1] Call to create API should fail as API not supported [Check 2] Create valid storage with set API [Check 3] Call to set_extended API call should fail [Check 4] Verify data is unchanged Oops... Secure fault!!! You're not going anywhere!
Reason:
The valtest_entry_p014 is overwritten by read_buff variable and this caused this fail.
Workaround:
When I changed read_buff declaration in test_p014.c from static uint8_t read_buff[TEST_BUFF_SIZE/4] = {0}; to static uint32_t read_buff[TEST_BUFF_SIZE/4] = {0}; the code is running correctly. But I think, that it should be officially fixed.
Best Regards
Stanislav
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi,
I use "7 2018-q2-update" ARMGCC compiler. The PSA Tests code works when it is compiled by ARMGLANG, but a fail occurs when the same code is compiled by ARMGCC.
Issue:
When TEST: 414 runs, I've got secure violation fault. See report bellow:
TEST: 414 | DESCRIPTION: Optional APIs not supported check
[Info] Executing tests from non-secure
Optional PS APIs are not supported.
[Check 1] Call to create API should fail as API not supported
[Check 2] Create valid storage with set API
[Check 3] Call to set_extended API call should fail
[Check 4] Verify data is unchanged
Oops... Secure fault!!! You're not going anywhere!
Reason:
The valtest_entry_p014 is overwritten by read_buff variable and this caused this fail.
Workaround:
When I changed read_buff declaration in test_p014.c from static uint8_t read_buff[TEST_BUFF_SIZE/4] = {0}; to static uint32_t read_buff[TEST_BUFF_SIZE/4] = {0}; the code is running correctly. But I think, that it should be officially fixed.
Best Regards
Stanislav
Hi Andrej,
I guess that you may ask about the SVCalls communication between secure
world and non-secure world in FreeRTOS. If I misunderstood your
question, please ignore the following.
In my very own opinion, FreeRTOS has a different concept of how to
manage secure stack/context from TF-M does.
FreeRTOS prefers to allocate and manage a dedicated secure stack/context
for each non-secure task requiring secure service. In its
implementation, each time when it does context switch, it invokes
SVCalls to also switch the secure stack/context for the next non-secure
task. FreeRTOS implements several own APIs to accomplish those
functionalities.
By contrast, TF-M as a trusted firmware, naturally, manages all the
secure resource by its own. Therefore, there is no such dedicated stack
in secure world mapping to each non-secure task. Currently, TF-M
implements CMSIS RTOS thread context management APIs to execute some
management work between non-secure world and secure world, on Armv8-M core.
Hope it can hlep you.
Best regards,
Hu Ziji
On 4/25/2019 3:45 PM, Andrej Butok via TF-M wrote:
> Hello,
>
> Do you know about any existing port of FreeRTOS (instead of RTX) to TFM? Did somebody a feasibility study?
> I have just started to look at it, and immediately detected a conflict, both are using Supervisor Calls (SVC) for own needs.
>
> Thanks,
> Andrej
>
>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
