Hi,
A new tag TF-Mv1.0-RC3 was created last Friday. The main change since RC2 is that it provides support for integrated Cryptocell-312 cryptographic hardware accelerator on MuscaB1e platform.
This enables TF-M to make use of Cryptocell-312 (CC-312) for crypto acceleration during Secure boot and runtime. TF-M is also can use the provisioned HUK (Hardware Unique Key), Attestation key and RoTPK (Root of Trust Public Key) in Cryptocell's OTP memory.
Tamas
Thomas,
Tests are placed under the test -> suites -> service name directory.
In your case you are looking at the Secure Storage Service non secure suite.
For SST The logic is located at :
* Non Secure side tests: test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c
* Secure side tests: test/suites/sst/secure/psa_ps_s_interface_testsuite.c
Hope that helps
Minos
________________________________
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org>
Sent: 28 November 2019 14:49
To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>
Subject: [TF-M] Regression test issues with IAR port
In my quest to port TF-M to the IAR toolchain I've run into issues with
a few of the tests, and I need some hints where to look.
The cmake build command line:
---
cmake .. -G"Unix Makefiles"
-DPROJ_CONFIG=C:\Users\thomasto\Projects\tf-m16\trusted-firmware-m\configs\ConfigRegression.cmake
-DTARGET_PLATFORM=MUSCA_A -DCOMPILER=IARARM
-DCMAKE_BUILD_TYPE=RelWithDebInfo
---
This results in three similar tests that fails:
---
> Executing 'TFM_SST_TEST_1018'
Description: 'Get interface with invalid thread name'
Get should not succeed with invalid thread name (Failed at
C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:936)
TEST FAILED!
> Executing 'TFM_SST_TEST_1019'
Description: 'Get info interface with invalid thread name'
Get info should not succeed with invalid thread name (Failed at
C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:1015)
TEST FAILED!
> Executing 'TFM_SST_TEST_1020'
Description: 'Remove interface with invalid thread name'
Remove should not succeed with invalid thread name (Failed at
C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:1093)
TEST FAILED!
---
Where do I find the logic that determines if these tests succeed or fails?
Cheers,
Thomas
--
*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
Website: www.iar.com<http://www.iar.com> <http://www.iar.com>
Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems> <http://www.twitter.com/iarsystems>
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
In my quest to port TF-M to the IAR toolchain I've run into issues with
a few of the tests, and I need some hints where to look.
The cmake build command line:
---
cmake .. -G"Unix Makefiles"
-DPROJ_CONFIG=C:\Users\thomasto\Projects\tf-m16\trusted-firmware-m\configs\ConfigRegression.cmake
-DTARGET_PLATFORM=MUSCA_A -DCOMPILER=IARARM
-DCMAKE_BUILD_TYPE=RelWithDebInfo
---
This results in three similar tests that fails:
---
> Executing 'TFM_SST_TEST_1018'
Description: 'Get interface with invalid thread name'
Get should not succeed with invalid thread name (Failed at
C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:936)
TEST FAILED!
> Executing 'TFM_SST_TEST_1019'
Description: 'Get info interface with invalid thread name'
Get info should not succeed with invalid thread name (Failed at
C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:1015)
TEST FAILED!
> Executing 'TFM_SST_TEST_1020'
Description: 'Remove interface with invalid thread name'
Remove should not succeed with invalid thread name (Failed at
C:/Users/thomasto/Projects/tf-m16/trusted-firmware-m/test/suites/sst/non_secure/psa_ps_ns_interface_testsuite.c:1093)
TEST FAILED!
---
Where do I find the logic that determines if these tests succeed or fails?
Cheers,
Thomas
--
*Thomas Törnblom*, /Product Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01
E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com>
Website: www.iar.com <http://www.iar.com>
Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>
Hi Andrej/Kevin,
Pasting the ;Secure Storage' Security Function Requirement below from the PSA Certified Level2 Protection Profile*
It doesn’t specifically mention Protected Storage and Internal Trusted Storage Service as a requirement. As long as the Target of Evaluation can prove that the confidentiality and integrity of assets in Secure Storage can be maintained, the requirement can be met.
PSA defines Protected Storage (PS)** and Internal Trusted Storage (ITS)**. PS is meant to store larger data sets stored on external flash and ITS for device intimate data stored on chip flash storage. If the device doesn’t have an on chip flash storage,
maybe it is still possible to just use PS implementation using external flash to ensure confidentiality and integrity of the secret assets on the platform.
@Marcus Streets<mailto:Marcus.Streets@arm.com> – Could you please share your thought on this
>>>
5.3 F.SECURE_STORAGE
The TOE protects the confidentiality and integrity of assets in a secure storage. The secure storage is bound to
the platform. Only the TOE can retrieve and modify assets from this secure storage.
This security function mitigates T.STORAGE by preventing direct and unprotected access to assets.
>>>
Regards,
Shebu
* https://www.psacertified.org/app/uploads/2019/02/JSADEN002-PSA_Certified_Le…
** https://developer.arm.com/-/media/Files/pdf/PlatformSecurityArchitecture/Im…
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: Thursday, November 28, 2019 7:50 AM
To: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com>
Cc: tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] PSA Certification without PS?
Hi Kevin,
So, platforms without internal flash memory, required by Internal Trusted Storage, may apply only for PSA L1. Right?
Thank you for your clarification,
Andrej Butok
-----Original Message-----
From: Kevin Peng (Arm Technology China) <Kevin.Peng(a)arm.com<mailto:Kevin.Peng@arm.com>>
Sent: Thursday, November 28, 2019 5:14 AM
To: Andrej Butok <andrey.butok(a)nxp.com<mailto:andrey.butok@nxp.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>
Subject: RE: [TF-M] PSA Certification without PS?
A quick information: Internal Trusted Storage is mandatory by PSA for isolation level 2 and 3.
Best Regards,
Kevin
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrej Butok via TF-M
Sent: Wednesday, November 27, 2019 7:32 PM
To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>
Subject: [TF-M] PSA Certification without PS?
Hello,
Most probably, we will port TFM to a platform with TZ and external flash, BUT without internal flash.
Is it possible to certify it for PSA L1 & L2 & Dev API, without Internal Trusted Storage service and its API?
Do you see any issue?
Thanks
Andrej Butok
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org>
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
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.
A quick information: Internal Trusted Storage is mandatory by PSA for isolation level 2 and 3.
Best Regards,
Kevin
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M
Sent: Wednesday, November 27, 2019 7:32 PM
To: tf-m(a)lists.trustedfirmware.org
Subject: [TF-M] PSA Certification without PS?
Hello,
Most probably, we will port TFM to a platform with TZ and external flash, BUT without internal flash.
Is it possible to certify it for PSA L1 & L2 & Dev API, without Internal Trusted Storage service and its API?
Do you see any issue?
Thanks
Andrej Butok
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi Ken, all,
Right, let's see the binary size of a prototype.
Regarding TBB instruction, It's applied at the stage of binary generation, after source parsing and references resolution so it is irrelevant to the problem of dead references, I have mentioned.
The best,
Anton
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M
Sent: 22 November 2019 10:23
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: Re: [TF-M] The svcall switch-case vs function table
Hi Anton,
Thanks for the reminder.
About code size, two points:
- We saved code size for switch/case usage: switch(num) {case1:case2:} -> func_tbl[num].func();
- The compiler uses 'TBB' instruction, which is a function table already.
So I think it should be okay; we can verify the code size after the prototype is available.
BR
/Ken
-----Original Message-----
From: Anton Komlev <Anton.Komlev(a)arm.com>
Sent: Thursday, November 21, 2019 8:09 PM
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>; Ken Liu (Arm Technology China) <Ken.Liu(a)arm.com>
Subject: RE: The svcall switch-case vs function table
Hi Ken, All,
Just a reminder of a side-effect of array-based function table. It creates unconditional reference to a function and blocks that function from removal during code size optimization. TF-M is quite sensitive to binary image size and we should be very careful to avoid its increase.
This is a general comment on functions table, irrelevant to the patch, where I have no knowledge yet to comment.
The best,
Anton
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu (Arm Technology China) via TF-M
Sent: 14 November 2019 09:33
To: tf-m(a)lists.trustedfirmware.org
Cc: nd <nd(a)arm.com>
Subject: [TF-M] The svcall switch-case vs function table
Hi,
I am trying to look at into the svcall logics and found if we keep using the switch/case would make it hard to abstract this logic for different configurations.
Thinking to move this static defined svc codes into an array-based function table. The pros are, the svc code set for different configurations is configurable, we don't need any #ifdef inside the svc numbers but rely on the configuration provided svc headers, and these headers are used inside configuration logic. And the overall svcall logic does not need to know the exact number definition but just do a f[num].func() call. The cons... I think the only thing is table may be out of date and cause a potential problem? or some function has only <4 parameter but we have to define a f(a0,a1,a2,a3) type function and fill extra parameter as zeros?
This won't improve the execution efficiency if the svc numbers are continuous since compiler uses 'TBB' to create a mapping table while processing switch/case, so we can skip this point while talking pros.
Welcome to comment or propose patches for this.
Thanks.
/Ken
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hello,
Most probably, we will port TFM to a platform with TZ and external flash, BUT without internal flash.
Is it possible to certify it for PSA L1 & L2 & Dev API, without Internal Trusted Storage service and its API?
Do you see any issue?
Thanks
Andrej Butok
Hello, I do also support the move to loose the requirement of 80 columns. The real need is outdated and supported as a legacy style, making more trouble than help.
The best,
Anton
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Laurence Lundblade via TF-M
Sent: 26 November 2019 21:12
To: Tamas Ban <Tamas.Ban(a)arm.com>
Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Coding guideline
For line length I’m following these rules for t_cose <https://github.com/laurencelundblade/t_cose>
- All comments blocks are 80 columns or less
- 2% of code lines can be over 80 columns (1% is too few)
- No lines over 120 columns
I am much happier and think the code is much better by allowing 2% of code lines over 80 columns. I don’t have to make variable names short and obscure, break up if statements in unnatural places, break up for(;;) statements unnaturally and such.
LL
> On Nov 18, 2019, at 8:31 AM, Tamas Ban <Tamas.Ban(a)arm.com> wrote:
>
> Hi,
>
> I would like to open a conversation about TF-M coding guideline <https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/coding_gui…>. I have these proposals:
> Change the rule of the 80 character column width:
> Max 80 characters length.
> Column length is max 80 character in first place, but there are exceptions when length could be MAX 120 character:
> Degrades code understandability: short, obscured variable names;
> awkward line breaks Maximum 1% of the lines can exceed 80 charter length.
> Might remove this rule, because in many cases we are not complaint with it. For example PSA Crypto API:
> o Order function parameters so that input params are before output params.
> o https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu… <https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu…>
>
> I’m interested in your opinions! Other rules also can be revisited!
>
> Tamas
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi,
Build environment provisioning (and dependency management) is a larger topic and sub-modules can only solve a small part of it. There is definitely room for improvement in this area, but as far as I can see sub-modules are a sub optimal answer.
Some of the issues which came to my mind:
1. The user experience of sub-modules is sometimes quirky. For example it is a headache if you have to switch between branches where one of the branches does not have a specific sub-module.
2. With sub-modules you can not have complex dependencies. I.e.: when one platform needs a dependency and another not, or you need two version of a dependency, or a different version for two platforms.
3. It is easy to see on what the repo having the sub-module depends, but the other direction is not. It is hard to see what is using a module.
4. The validness of tests are limited if you use source code. Longer term it would be nice to allow using tested binaries of tf-m dependencies and sub-modules can not handle this need.
5. Flexibility. If we use sub-modules, then the version control and the dependency handling "layers" get bounded. For tf-m developers this might not be an issue but for integrators it can be.
Can you please explain the problem you see a bit more? Zephyr is using cmake and you could use the External_project or the FetchContent module to get all needed dependencies. Also nothing really stops you to use sub-modules in the Zephyr repo to get tf-m and all it's dependencies.
/George
-----Original Message-----
From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Townsend via TF-M
Sent: 26 November 2019 19:23
To: Kumar Gala <kumar.gala(a)linaro.org>
Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org
Subject: Re: [TF-M] Using git submodules for dependencies?
Hi,
I'm reviving an old thread (sorry, probably bad form), but we're running into this issue again now with Zephyr (and probably with FreeRTOS later) where we need to produce a TF-M 'module' got Zephyr that we can include in the zephyr github repo. With the current approach for TF-M, we will have to produce 5 forks of the 5 projects/dependencies, which seems superfluous versus a single 'master' TF-M repo with the four dependencies as sub-modules, and I can't see why technically this would be more of a challenge for end-users (you can even init the submodules at the same time you clone the parent TF-M repo so it's actually LESS work), and means a single repo where all of the dependency versions can change over time in sync with the various releases.
I may be missing or misunderstanding an obvious technical drawback made earlier, but I haven't understand why submodules are less desirable than
1+4 independent repos both for TF-M and any projects on the RTOS side
depending on it?
Kevin
On Wed, 10 Jul 2019 at 18:09, Kumar Gala via TF-M < tf-m(a)lists.trustedfirmware.org> wrote:
> How would a git repo with some submodules preclude any of the things
> you mentioned? I guess my initial thought is that there would be an “uber”
> repo in which TFM, CMSIS and mbedcrypto would all be sub-modules.
>
> There’s also the option of using cmake ExternalProject (
> https://cmake.org/cmake/help/latest/module/ExternalProject.html?highli
> ght=external
> )
>
> Or west
>
> https://pypi.org/project/west/
>
> - k
>
> > On Jul 10, 2019, at 8:47 AM, Ashutosh Singh via TF-M <
> tf-m(a)lists.trustedfirmware.org> wrote:
> >
> > Hi,
> >
> > Initial idea was to keep the external dependencies clearly visible
> > (from
> code auditability point of view). With submodule we can't checkout the
> dependencies out of tree. Since the dependencies need to be checked
> out only once it was considered acceptable nuisance, until you do a
> pull and version of the dependencies have changed.
> > 'repo' was considered as well, but repo tool doesn't work on
> windows(last I checked).
> >
> > Thanks,
> > Ashu
> >
> > -----Original Message-----
> > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of
> > Kumar
> Gala via TF-M
> > Sent: 10 July 2019 09:50
> > To: Andrej Butok <andrey.butok(a)nxp.com>
> > Cc: tf-m(a)lists.trustedfirmware.org
> > Subject: Re: [TF-M] Using git submodules for dependencies?
> >
> > There can always be a fork of the sources kept in TF-M repos to
> > handle
> the case of needing local modifications for some reason.
> >
> > - k
> >
> >> On Jul 10, 2019, at 3:48 AM, Andrej Butok via TF-M <
> tf-m(a)lists.trustedfirmware.org> wrote:
> >>
> >> Hi Kevin,
> >>
> >> Only if 100% of the external project source code is used without
> change.
> >> Even if it is valid now, nobody will give you this guarantee in future.
> >>
> >> Regards,
> >> Andrej
> >>
> >> -----Original Message-----
> >> From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of
> >> Kevin
> Townsend via TF-M
> >> Sent: Wednesday, July 10, 2019 10:41 AM
> >> To: Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org>
> >> Subject: [TF-M] Using git submodules for dependencies?
> >>
> >> Hi,
> >>
> >> I'm currently working on integrating TF-M into Zephyr and getting
> >> TF-M
> working with QEMU. Part of that work is simplifying the setup and
> build process to generate a TF-M secure library.
> >>
> >> Was the idea of git submodules for dependencies considered and rejected?
> >> Using sub-modules would reduce the number of setup steps required,
> >> and
> pair external dependency versions with specific TF-M commits/releases.
> >>
> >> There may be a valid reason this approach was rejected, but it
> >> seems
> like a sensible option on the surface?
> >>
> >> Best regards,
> >> Kevin Townsend
> >> --
> >> TF-M mailing list
> >> TF-M(a)lists.trustedfirmware.org
> >>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-m&data=02%7C01%7Ca
> ndrey.butok%40nxp.com%7C04856a3b68604d01153208d705124e6a%7C686ea1d3bc2
> b4c6fa92cd99c5c301635%7C0%7C0%7C636983448498201722&sdata=IjOFM44xG
> bA2Zgrj%2F2VSmHEYLuXvMzqS7HH6h7gekF4%3D&reserved=0
> >> --
> >> TF-M mailing list
> >> TF-M(a)lists.trustedfirmware.org
> >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
> >
> > --
> > TF-M mailing list
> > TF-M(a)lists.trustedfirmware.org
> > https://lists.trustedfirmware.org/mailman/listinfo/tf-m
> > --
> > TF-M mailing list
> > TF-M(a)lists.trustedfirmware.org
> > https://lists.trustedfirmware.org/mailman/listinfo/tf-m
>
> --
> TF-M mailing list
> TF-M(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-m
>
--
TF-M mailing list
TF-M(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m
Hi,
I would like to open a conversation about TF-M coding guideline<https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/coding_gui…>. I have these proposals:
* Change the rule of the 80 character column width:
* Max 80 characters length.
* Column length is max 80 character in first place, but there are exceptions when length could be MAX 120 character:
* Degrades code understandability: short, obscured variable names; awkward line breaks
* Maximum 1% of the lines can exceed 80 charter length.
* Might remove this rule, because in many cases we are not complaint with it. For example PSA Crypto API:
o Order function parameters so that input params are before output params.
o https://git.trustedfirmware.org/trusted-firmware-m.git/tree/interface/inclu…
I'm interested in your opinions! Other rules also can be revisited!
Tamas
