- TF-M - lists.trustedfirmware.org

Re: [TF-M] [EXTERNAL] Branches merging from 'feature-ipc' to 'master' is happening

by DeMars, Alan

Yay! When? > On Mar 11, 2019, at 6:57 PM, Ken Liu (Arm Technology China) via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi TF-M Subscribers, > The branch 'feature-ipc' is going to be merged into 'master', and here is the patch: > https://review.trustedfirmware.org/c/trusted-firmware-m/+/677 > > After the merging, the IPC feature will be available in the 'master' branch, future updates on the IPC part will happen in 'master' branch, too. > For those patches pushed towards 'feature-ipc' will be reviewed and we suggest push new patchset to 'master' branch. > > Please reply to this thread without hesitation if there are any questions. > > Thanks. > > -Ken > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

6 years, 1 month

1
0
0 0

Branches merging from 'feature-ipc' to 'master' is happening

by Ken Liu (Arm Technology China)

Hi TF-M Subscribers, The branch 'feature-ipc' is going to be merged into 'master', and here is the patch: https://review.trustedfirmware.org/c/trusted-firmware-m/+/677 After the merging, the IPC feature will be available in the 'master' branch, future updates on the IPC part will happen in 'master' branch, too. For those patches pushed towards 'feature-ipc' will be reviewed and we suggest push new patchset to 'master' branch. Please reply to this thread without hesitation if there are any questions. Thanks. -Ken

6 years, 1 month

1
0
0 0

TF-M v1.0-Beta Blog

by Shebu Varghese Kuriakose

Hi, Here is a blog on the recent TF-M tag v1.0-Beta and how it enables PSA certification https://www.trustedfirmware.org/blog/Trusted-Firmware-M-v10-Beta-Enabling-P… Regards, Shebu

6 years, 1 month

1
0
0 0

Re: [TF-M] Trusted boot - rollback protection

by David Brown

On Mon, Mar 11, 2019 at 01:43:19PM +0000, Tamas Ban via TF-M wrote: >https://developer.trustedfirmware.org/w/tf_m/design/trusted_boot/rollback_p… Oh, and a little terminology comment about the Trusted non-volatile (NV) counters. This section should use "increase" and "decrease" not "increment" and "decrement". There is no requirement that the counter only be incremented (having 1 added to the value), only that it be set to a larger value than the current value. You should probably also add a discussion as to how testing will be done with a HW security counter. Again, my suggestion is to not add an additional counter, but just use the existing version field (minus the build number) as the security counter value. David

6 years, 1 month

1
0
0 0

Trusted boot - rollback protection

by Tamas Ban

Hi all, 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… Comments are welcome! Regards Tamas Ban

6 years, 1 month

1
0
0 0

Re: [TF-M] multiple services within the same SP

by Andrew Thoelke

Hi Alan, I can answer this from the PSA Firmware Framework specification point of view, Ken (or others in the TF-M team) can clarify how closely the TF-M behaviour matches this. In the manifest each service has a "signal" attribute which is a C identifier that is given the signal value for that service. The value is allocated by the TF-M tools and should be available to the SP source code via a generated header file - the specification places these definitions in the psa_manifest/<manifestfilename>.h header file, matching the name of the manifest file itself. When the SP receives a set of signals from psa_wait(), it can identify which signals are asserted using these identifiers to test the signal bits. The example RoT Service in Appendix D of the PSA Firmware Framework demonstrates this. Regards, Andrew -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, Alan via TF-M Sent: 08 March 2019 13:52 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] multiple services within the same SP In a multi-service SP, how does the SP know which SID has been used to connect to it? -- TF-M mailing list TF-M(a)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.

6 years, 1 month

1
0
0 0

Re: [TF-M] multiple services within the same SP

by Ken Liu (Arm Technology China)

Hi Alan, Services are listed in SP. SPM could enumerate the services in a SP by the list. You can check the member variable ' service_list' of ' tfm_spm_ipc_partition_t' to know details. -Ken > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of DeMars, > Alan via TF-M > Sent: Friday, March 8, 2019 9:52 PM > To: tf-m(a)lists.trustedfirmware.org > Subject: [TF-M] multiple services within the same SP > > In a multi-service SP, how does the SP know which SID has been used to connect > to it? > -- > TF-M mailing list > TF-M(a)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.

6 years, 1 month

1
0
0 0

multiple services within the same SP

by DeMars, Alan

In a multi-service SP, how does the SP know which SID has been used to connect to it?

6 years, 1 month

1
0
0 0

Re: [TF-M] META: TF-M Mailing list configuration

by Bill Fletcher

Hi David, Thanks for raising this. I'll contact you directly to review the Mailman configuration. Regards Bill On Thu, 28 Feb 2019, 05:04 David Brown via TF-M, < tf-m(a)lists.trustedfirmware.org> wrote: > I have noticed that this mailing list seems to be configured in a > non-ideal way. > > Primarily, the messages are sent from the list address itself, and a > reply-to header is inserted for the original sender. This at least > often will allow someone to reply to the original sender. > > There are a few problems with this. One is that this tends to break > messages that have been copied to more than one list, especially for > recipients who subscribe to both lists. Admittedly it is better than > the all-to-common practice of setting Reply-to to the list itself, > which effectively steals all replies from any other recipients or > lists that were originally included. > > Secondly, however, this kind of violates the intent of the reply-to > field, which was intended for the originator of the message to be able > to give an alternative address they wish for replies to go to. > > I don't know how this list is hosted, and usually this kind of > configuration results from an ISP that rejects messages. But, I know > a lot of mailing lists are managed with mailman without these > problems, so it should be possible to get this working in a more > homogenous way. > > Lists admins, feel free to contact me if you want any assistance in > trying to configure the list better. > > Thanks, > David > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m >

6 years, 2 months

1
0
0 0

META: TF-M Mailing list configuration

by David Brown

I have noticed that this mailing list seems to be configured in a non-ideal way. Primarily, the messages are sent from the list address itself, and a reply-to header is inserted for the original sender. This at least often will allow someone to reply to the original sender. There are a few problems with this. One is that this tends to break messages that have been copied to more than one list, especially for recipients who subscribe to both lists. Admittedly it is better than the all-to-common practice of setting Reply-to to the list itself, which effectively steals all replies from any other recipients or lists that were originally included. Secondly, however, this kind of violates the intent of the reply-to field, which was intended for the originator of the message to be able to give an alternative address they wish for replies to go to. I don't know how this list is hosted, and usually this kind of configuration results from an ISP that rejects messages. But, I know a lot of mailing lists are managed with mailman without these problems, so it should be possible to get this working in a more homogenous way. Lists admins, feel free to contact me if you want any assistance in trying to configure the list better. Thanks, David

6 years, 2 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M