Hello all,
I made a patch (https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/16214) that reorganize interaction between ITS partition, ITS file system and ITS flash driver.
1. ITS flash driver interface is decoupled from ITS file system.
2. ITS flash driver interface isn't dependent on upper layers like ITS FS or ITS.
3. ITS flash driver emulated in RAM (its_flash_ram) can be used without CMSIS flash driver even in production environment if needed.
4. Target can provide own implementation of ITS flash driver without implementing CMSIS flash driver. Which can be more flexible or simple in some cases.
5. Allocation of ITS flash driver instance by ITS partition is not dependent on lower layers like CMSIS driver. ITS partition uses abstract flash driver interface to bind ITS file system and driver instance.
This changes gives following benefits.
1. Vendors can provide ITS flash driver without need to create an intermediate CMSIS flash driver.
2. It's possible to implement ITS encryption by adding a new ITS flash driver that performs encryption and uses existing drivers (NOR, NAND, RAM, platform specific) as the storage backend.
3. It's possible to use ITS file system + ITS encryption driver (b) for Protected Storage directly without additional context switching during access to PS file system handled by ITS partition. I think it should improve performance of PS.
4. Use ITS file system directly in application specific custom partitions by allocating ITS file system context and ITS flash driver.
Best regards,
Roman.
Hi everyone,
From what I see manifest lists (e.g. tools/tfm_manifest_list.yaml) describe partitions, but "name" field there (which is a description of the partition) uses "Service" word, for example:
"name": "Protected Storage Service",
Shouldn't this be "name": "Protected Storage Partition" ?
Why do TFM uses Service when describing the Partition?
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,
TF-M coding standard<https://tf-m-user-guide.trustedfirmware.org/contributing/coding_guide.html> mandates up to 80 characters per line. This looks a bit too restrictive nowadays with no punch cards or text terminals.
I propose to increase this limit to 120 or 140 characters. Personally like 128.
Are there any thoughts or objections against it?
Thanks,
Anton
Hi all,
Please be noted that the TF-M example Secure Partition has been moved from the tf-m-tools repo to the tf-m-extras<https://git.trustedfirmware.org/TF-M/tf-m-extras.git/tree/examples/example_…> repo.
It has also been aligned with the latest TF-M. The documentations are improved as well.
It could be a good reference for Secure Partition developer starters.
Best Regards,
Kevin
Hello,
The project documentation will never be ideal and we are continuing improving it.
Let me ask you for reply to this email with the pain points you have experienced or suggestions for improvements to be considered in this phase.
Your direct contribution with docs articles will be much appreciated too. For example: TF-M debugging technics and experience would be very helpful.
Thank you in advance,
Anton
[Thread res-used, title renamed]
Hi all,
This is now happening - fully support non-CMake use of the manifest tool.
Here is the patch:
https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15756
With this patch, the manifest tool takes build configurations from a config header file instead of replying on the build system.
Please check the details in the patch.
Any comments are welcome.
Best Regards,
Kevin
-----Original Message-----
From: Andrej Butok <andrey.butok(a)nxp.com>
Sent: Thursday, May 12, 2022 2:49 PM
To: Kevin Peng <Kevin.Peng(a)arm.com>; Raef Coles <Raef.Coles(a)arm.com>
Cc: tf-m(a)lists.trustedfirmware.org
Subject: RE: Any usage of environment variables in manifest lists
> If there are strong requirements on supporting the non-cmake usecase
Yes, it is 😉
-----Original Message-----
From: Kevin Peng via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Thursday, May 12, 2022 5:46 AM
To: Kevin Peng <Kevin.Peng(a)arm.com>; Raef Coles <Raef.Coles(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Re: Any usage of environment variables in manifest lists
Well, I think I figured out a way to decouple them.
If there are strong requirements on supporting the non-cmake usecase, I can try to work it out.
Best Regards,
Kevin
-----Original Message-----
From: Kevin Peng via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: Thursday, May 12, 2022 10:09 AM
To: Raef Coles <Raef.Coles(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] Re: Any usage of environment variables in manifest lists
Yes.
The manifest tool is now fully replying on CMake (it has been, since I introduced the conditional parsing of manifests around half a year ago).
It needs to be aware of the build configurations.
Best Regards,
Kevin
-----Original Message-----
From: Raef Coles <Raef.Coles(a)arm.com>
Sent: Wednesday, May 11, 2022 7:15 PM
To: tf-m(a)lists.trustedfirmware.org; Kevin Peng <Kevin.Peng(a)arm.com>
Cc: nd <nd(a)arm.com>
Subject: Re: Any usage of environment variables in manifest lists
Hey Kevin
Does this mean that cmake will be required to generate the headers/etc from the manifests?
I believe in the past we deliberately supported the non-cmake usecase, as some people were building TF-M in alternate ways.
Raef
________________________________________
From: Kevin Peng via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 11 May 2022 09:24
To: tf-m(a)lists.trustedfirmware.org
Cc: nd
Subject: [TF-M] Any usage of environment variables in manifest lists
Hi,
Is there anyone using environment variables for the "manifest" attribute in out-of-tree manifest lists?
I'm asking because I'm working to support configurable stack_size for Secure Partitions<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>.
In the patch the support of environment variables in manifest lists is removed<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>.
Because I have to call the CMake command configure_file to replace the stack_size symbols (CMake variables<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…> surrounded with "@") with their values.
While configure_file does not recognize environment variables.
If you do have environment variables in manifest list, there is an alternative:
Replace the env. variables with CMake variables surrounded with "@" and set the value of the CMake variables in either config files or command line inputs.
Best Regards,
Kevin
--
TF-M mailing list -- tf-m(a)lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org
--
TF-M mailing list -- tf-m(a)lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave(a)lists.trustedfirmware.org
Hi,
What was the intended usage of psa_reset_key_attribute(*attributes) which requires a PSA call from non-secure side to reset the client attributes? I am curious because the attributes to be reset comes from the non-secure memory, not directly associated with ITS/PS.
The current IPC setup performs a PSA call to tfm_crypto_rest_key_attributes()(https://git.trustedfirmware.org/TF-M/trust…
This function creates a copy of client key attribute in a secure key attribute structure. The secure key attribute is reset (set to 0) and then copied back to the client key attribute before returning to non-secure code. At first glance, this seems like a roundabout way to zeorise client side attributes.
Regards,
Archanaa
