- TF-M - lists.trustedfirmware.org

Re: [TF-M] Using tfm_plat_get_huk_derived_key(), TFM key-storage?

by Jamie Fox

Hi Andrej, Key derivation should be deterministic - given the same input parameters, tfm_plat_get_huk_derived_key() should always derive the same key. Each platform needs to implement tfm_plat_get_huk_derived_key() to use a key derivation function (KDF) to derive keys from the hardware unique key (HUK) that is kept in some one time programmable (OTP) memory on the chip. Depending on the platform, the key derivation might be done with a crypto accelerator, or it might be done with a software implementation of a KDF if no accelerator is available. You can use the Musca-B1 implementation as an example (https://git.trustedfirmware.org/trusted-firmware-m.git/tree/platform/ext/ta…), which uses CryptoCell-312 to derive keys from the HUK. Other Arm platforms only have dummy implementations of this function. In general, users of this API will keep their derived keys in volatile memory and redo the key derivation on each boot, as the cost of key derivation is low. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrej Butok via TF-M Sent: 09 April 2020 11:49 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Using tfm_plat_get_huk_derived_key(), TFM key-storage? Hello, Could you clarify: 1) Must the tfm_plat_get_huk_derived_key() function to return the same key per each call (as it's done now), or it may return randomized key (per each call) derived from HUK? 2) If tfm_plat_get_huk_derived_key() may return a different key per call, the generated key must be stored in persistent storage. Is this key persistent storage already implemented (using the default parameters) for example in ITS, or the key-storage must be implemented additionally? It looks like the current TFM key storage is placed in RAM, or I have missed something? Thank you, Andrej Butok

6 years, 1 month

2
1
0 0

Using tfm_plat_get_huk_derived_key(), TFM key-storage?

by Andrej Butok

Hello, Could you clarify: 1) Must the tfm_plat_get_huk_derived_key() function to return the same key per each call (as it's done now), or it may return randomized key (per each call) derived from HUK? 2) If tfm_plat_get_huk_derived_key() may return a different key per call, the generated key must be stored in persistent storage. Is this key persistent storage already implemented (using the default parameters) for example in ITS, or the key-storage must be implemented additionally? It looks like the current TFM key storage is placed in RAM, or I have missed something? Thank you, Andrej Butok

6 years, 1 month

1
0
0 0

Re: [TF-M] [RFC] The veneer usage under library model (Ken Liu)

by Ken Liu

Hi Reinhard, Thanks for your feedback, and let's see if others would give more comments. Will broadcast the implementation after it is created. Before that we need to know if some users (especially those developing secure partitions under library model) got comments on this. Also, I think this update could help the first point in your list. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: Thursday, April 9, 2020 2:57 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] The veneer usage under library model (Ken Liu) Ken, This is the answer to "What do you think about this update?" When external TF-M APIs do not change, there should be no user impact. As the veneer is just an internal implementation of parameter passing, changing the veneer implementation would be just fine. I made some suggestions here https://lists.trustedfirmware.org/pipermail/tf-m/2020-March/000805.html I would be happy to review your implementation in case that you have doubts. Best regards Reinhard

6 years, 1 month

1
0
0 0

Re: [TF-M] Multi-threaded single-scheduler model proposal

by Ken Liu

Hi Erik, Could you share us more design details such as the slides you presented in Tech Forum, the progress and so on? We want to see more details (the more the better I think) and then we could discuss more precisely. Also, if this design has been prototyped, try to collect some data would be much helpful. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Reinhard Keil via TF-M Sent: Thursday, April 9, 2020 2:51 PM To: Shreve, Erik <e-shreve(a)ti.com>; DeMars, Alan <ademars(a)ti.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Multi-threaded single-scheduler model proposal Erik, I believe we should measure timing behaviour and document it first before come to conclusions. Personally I have not reviewed the IPC mode. I was just reviewing the SFN (aka Library mode) and measured the current implementation (actually it was a RC3+patches version). My result and assessment is here https://lists.trustedfirmware.org/pipermail/tf-m/2020-March/000805.html - it has as expected for v1 "room for improvement". Did you do similar tests with the IPC model already? Do you have timing measurements of the HW crypto accelerator operations? From the STM32L5 data sheet we are getting 410 cycles as the maximum time of an AES 256-byte key decrypt operation (most operations seems to take less than 100 cycles). The fact that crypto is time consuming is not new for system designers that use a single core processor. As said the solution in today's applications is: * Crypto is in "Normal" priority * Time critical execution is "High" priority - this threads can preempt execution of "Normal" priority threads. Have a happy Easter time and stay healty! Reinhard From: Shreve, Erik <e-shreve(a)ti.com<mailto:e-shreve@ti.com>> Sent: Tuesday, April 7, 2020 3:24 PM To: Reinhard Keil <Reinhard.Keil(a)arm.com<mailto:Reinhard.Keil@arm.com>>; DeMars, Alan <ademars(a)ti.com<mailto:ademars@ti.com>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: [TF-M] Multi-threaded single-scheduler model proposal Reinhard, I'm happy to engage in discussion over email. Didn't mean to send any other impression. Also, appreciate your feedback on the proposal. Elegance is in the eye of the beholder, but that said I think that the IPC model does have an elegance to it. However, its elegance imposes limitations that complicate the entirety of _some_ systems - leading to less overall elegance in _those_ systems. The IPC model isn't bad or inappropriate, it's a great solution. It just doesn't cover everything (what could?) Further, if a middle ground is needed but there exists no 'elegant' solution then a solution a bit less than elegant may be required. Also, no debate that the IPC model is not much different from when users are running mbedTLS only in a dedicated thread, but that is not how we see crypto used in our ecosystem. There are many industrial and automotive use cases where determinism is required. Further, both of these markets are seeing an uptick in security interest and even regulation pressure. And these markets don't like change. Change implies opening products back up to costly verification and validation activities and risk. I can't share particulars on this email list, but I can say that any system supporting multiple concurrent connections wherein different connections have different priority and at least some of those have deterministic response requirements will have difficulty adopting the IPC model. (Of course there are other ways to solve this such as increased clock rate or duplicated HW accelerators, but these impact die cost and can negatively impact power performance.) Keep in mind that not all connections are TLS connections over the internet where a few milliseconds would be noise. But based on your statement "Maybe there are other solutions that extending the RTOS kernel," I'm wondering if I've not communicated the idea well enough. The RTOS kernels would only be extended by the calling of tz_context APIs during task switching. This is something that is already occurring in the IPC model. (You mention that using the tz_context APIs is "tricky," can you elaborate more on this?) There is then a TF-M _to_ RTOS layer allowing secured code to signal semaphore and mutex usage to the RTOS. The RTOS kernel itself has no changes for this layer. Thus, I see the impact to the RTOS kernels as minimal. And since the RTOS retains the same control over when tasks run, there is minimal (if any) impact to application code. I think one of your concerns is adoption of TF-M and that it may be negatively impacted if difficult integration with each RTOS is required. Yes? If so, I am sharing your concern about adoption, but I think the bigger hindrance is not the RTOS integration but application level integration. After all there are far fewer RTOSes than applications in the world. Likely our different experiences are leading us to different conclusions here despite a shared concern. But providing a few well selected options can maximize adoption for effort. At the end of the Tech Forum meeting someone suggested a model like this could replace (or upgrade) the Library model. Regarding HW run times, the specifics really are in cycle counts if we want to compare them with the cost of task switching. Many ECC (and certainly RSA/DSA/DH) math operations take much longer (millions of cycles) than the time to switch a task. Finally, regarding minimal viable product (MVP), I understand the purpose of an MVP to either be a platform to gain feedback toward a product launch or a minimum product that is useful to early adopters. Either way, it seems that with the release of TF-M 1.0 this has been achieved. So then the next steps are to incorporate feedback and grow the market of the product. Growing the market use of TF-M is what I seek to do with the proposal. Again, appreciate the discussion. Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: Reinhard Keil [mailto:Reinhard.Keil@arm.com] Sent: Friday, April 03, 2020 7:26 AM To: Shreve, Erik; DeMars, Alan Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; nd Subject: [EXTERNAL] RE: [TF-M] Multi-threaded single-scheduler model proposal Erik, Alan, Sorry I had not enough time to participate the whole meeting yesterday and I therefore kicked-off some discussion before. It's really great to see your engagement here. Let me summarize: TF-M should work with many different RTOSes as the various CSPs currently have preferences (Azure=ThreadX, AWS=FreeRTOS, etc.). To make it easy to work with this diverse eco-system we should aim for simplicity of TF-M/RTOS interaction. Also tz_context slows down overall thread switching and is tricky to use. I agree with you that we will need a middle ground. You say: "No impact to time deterministic execution on the NS side unless two threads call secure services" is the issue. However I cannot see today an elegant solution. My question is: what use-cases do you see where two different threads need to call secure services. Is in such use-cases timing a critical factor? Alan raised "In a real world use case we are faced with, the process kicked off by the secure service may take a long time (ie several ms)". This is correct, but makes it really sense to schedule CPU execution. HW accelerator math operations take some ~1usec; thread scheduling is not economic. IMHO: It is not different from today's implementation where i.e. mbedTLS is running in a thread. For time critical applications you would solve that problem with thread priorities where: * Crypto is in "Normal" priority * Time critical execution is "High" priority I believe we should focus first on a minimum viable product and then analyze the real-world problems that come with it. Maybe there are other solutions that extending the RTOS kernel. Have a good weekend. Reinhard From: Shreve, Erik <e-shreve(a)ti.com<mailto:e-shreve@ti.com>> Sent: Thursday, April 2, 2020 4:55 PM To: DeMars, Alan <ademars(a)ti.com<mailto:ademars@ti.com>>; Reinhard Keil <Reinhard.Keil(a)arm.com<mailto:Reinhard.Keil@arm.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] Multi-threaded single-scheduler model proposal I see the discussion of today's tech forum agenda has begun ahead of time. :) Individual public key operations can take ms even when accelerated with HW. Further, the HW accelerators operate as math coprocessors with a series of math operations stitched together by SW. No doubt existing models in TF-M have the benefit of simplicity for the secure code analysis. However, their simplicity complicates the scheduling of the non-trusted code. The qualifier in this statement "No impact to time deterministic execution on the NS side unless two threads call secure services" is the issue. I believe we need a middle ground to drive additional adoption. Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development) From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M Sent: Thursday, April 02, 2020 9:47 AM To: Reinhard Keil; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd Subject: [EXTERNAL] Re: [TF-M] Multi-threaded single-scheduler model proposal I used crypto accelerator as a hypothetical example. In a real world use case we are faced with, the process kicked off by the secure service may take a long time (ie several ms). It is not acceptable to be parked in wfe during that time. Alan From: Reinhard Keil [mailto:Reinhard.Keil@arm.com] Sent: Thursday, April 2, 2020 6:52 AM To: DeMars, Alan; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd Subject: [EXTERNAL] RE: [TF-M] Multi-threaded single-scheduler model proposal Alan, "I was afraid that this was the proposal. No lower priority NS threads can run while waiting for the secure interrupt. Only higher priority threads that are initiated by a NS interrupt can run." You are correct, scheduling of lower priority NS threads would be not possible. This is definitely a shortcoming of the solution. May I ask: how long does a hardware crypto operation take? What time could be used for low priority NS thread execution? Reinhard

6 years, 1 month

1
0
0 0

[RFC] The veneer usage under library model (Ken Liu)

by Reinhard Keil

Ken, This is the answer to "What do you think about this update?" When external TF-M APIs do not change, there should be no user impact. As the veneer is just an internal implementation of parameter passing, changing the veneer implementation would be just fine. I made some suggestions here https://lists.trustedfirmware.org/pipermail/tf-m/2020-March/000805.html I would be happy to review your implementation in case that you have doubts. Best regards Reinhard

6 years, 1 month

1
0
0 0

[RFC] The veneer usage under library model

by Ken Liu

Hi, There are veneer prototypes in 'tfm_veneers.h', with different function name but the same parameters. These veneers are for the library model. I think these veneers can be combined into one and use a parameter 'type' to dispatch to the actual functions. What do you think about this update? Would this change impact your development much? Please provide your comments. Thanks. /Ken

6 years, 1 month

1
0
0 0

Re: [TF-M] [TF-A] TF-A Tech Forum @ Thu 9 Apr 2020 17:00 - 18:00 (GMT) - Special session on Project Maintenance Proposal for tf.org

by Joanna Farley

I realise non TF-A people may not have access to session conference details. These can be found here: https://lists.trustedfirmware.org/pipermail/tf-a/2020-March/000330.html From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: Joanna Farley <Joanna.Farley(a)arm.com> Date: Tuesday, 7 April 2020 at 18:10 To: tf-a <tf-a(a)lists.trustedfirmware.org> Cc: "tsc(a)lists.trustedfirmware.org" <tsc(a)lists.trustedfirmware.org>, "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>, "op-tee(a)linaro.org" <op-tee(a)linaro.org> Subject: [TF-A] TF-A Tech Forum @ Thu 9 Apr 2020 17:00 - 18:00 (GMT) - Special session on Project Maintenance Proposal for tf.org Hi All, The third TF-A Tech Forum is scheduled for Thu 9th Apr 2020 17:00 - 18:00 (GMT). A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know. For this special session I have also copied the TF-M, TSC and OPTEE mailing lists as the subject may interest the people subscribed to those lists as there is a cross mailing list discussion currently ongoing. Agenda: * Overview of the Project Maintenance Proposal for tf.org Projects by Sandrine Bailleux * Optional TF-A Mailing List Topic Discussions Thanks Joanna 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. 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

TF-A Tech Forum @ Thu 9 Apr 2020 17:00 - 18:00 (GMT) - Special session on Project Maintenance Proposal for tf.org

by Joanna Farley

Hi All, The third TF-A Tech Forum is scheduled for Thu 9th Apr 2020 17:00 - 18:00 (GMT). A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know. For this special session I have also copied the TF-M, TSC and OPTEE mailing lists as the subject may interest the people subscribed to those lists as there is a cross mailing list discussion currently ongoing. Agenda: * Overview of the Project Maintenance Proposal for tf.org Projects by Sandrine Bailleux * Optional TF-A Mailing List Topic Discussions Thanks Joanna 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] [TF-A] [TF-TSC] Project Maintenance Proposal for tf.org Projects

by Sandrine Bailleux

Hi Joakim, On 4/2/20 10:18 AM, Joakim Bech via TF-A wrote: > Hi Sandrine, > > On Wed, Apr 01, 2020 at 11:46:20AM +0200, Sandrine Bailleux wrote: >> Hi Joakim, >> >> On 4/1/20 10:08 AM, Joakim Bech via TSC wrote: >>> How that works in practice is that all OP-TEE maintainers are adding >>> their "Tested-by" (see example [2]) tag for the platform they maintain >>> when we're doing a release. If there are platforms with no "Tested-by" >>> tag, then they simply end up with the "last known version". >> >> I think that's a very good idea! >> > The "Tested-by" part for OP-TEE releases has been working pretty good, > not sure how scalable it is the long run though. To give some more > info regarding the "last known version", we even at one point had some > stop-light for that. I.e. if a maintainer missed testing a release once, > then it became "orange". If missed twice, then it became "red" and we > showed last know supported version. But we dropped that idea a short > while after introducing it. May I know why you dropped the idea? Was it too much maintenance? If that's the reason I guess again this could be addressed with some automation work (generating the stop-light status from the commit message info). >>> However, to keep that up-to-date, it requires some discipline from the >>> people maintaining such a table ... something that we in the OP-TEE >>> project haven't been very good at :) >> >> Can't this be automated, such that it doesn't need to be manually kept >> up-to-date? I imagine we could have some tools generating the platform >> support table out of such a commit message. >> > Indeed it could, it's just a matter of doing some scripting if one > doesn't want to do it manually. I already have Python scripts pulling > all tags from GitHub pull requests. But there are of course several > other ways how one could pull that kind of information. Regards, Sandrine

6 years, 1 month

2
1
0 0

Re: [TF-M] [TF-A] [EXTERNAL] Project Maintenance Proposal for tf.org Projects

by Sandrine Bailleux

Hi Erik, On 4/1/20 9:24 PM, Shreve, Erik via TF-A wrote: > Sandrine, > > To clarify on functionality vs. support. I listed out a support life cycle consisting of the following states: > Fully Supported > Orphan > Out of Date > Deprecated > These states are intended to have nothing to do with functionality, but only the support offered for the functionality that currently exists for a platform. > > I think I may have confused things when I listed "Functional Support" as the heading to represent "Functionality." > I'm proposing that the supported "Functionality" should be documented in a standard way (within a project) for every platform. > > I do agree this could be burdensome to keep up with. But that is why I suggested that the project's feature list be versioned. The platform's supported feature list document would reference the version of the project feature list used. Platform maintainers then don' t have to continuously update the document. But it will be clear how long it has been since they did update and thus what information may be missing. Versioning the feature list document is also why I mentioned that the project version number may want to adopt a version number scheme where feature changes are represented by a certain part of the version number. For example Semantic Versioning 2.0.0: https://semver.org/. Hope that clarifies the intent? For implementation of this I'm imagining each project could create a supported_feature_list.rst file and each platform would copy that file into their platform doc folder and fill it in. I'm not saying that approach would be required at tf.org level, just sharing to further illustrate. > > That said, perhaps the implementation details for a project would not warrant such a document per platform? My primary concern around this is misuse/misconfiguration. If a platform doesn't support a feature or configuration it may not be obvious to a user unless an error is generated at build or run-time. OK, I think I get the idea now, thanks for the explanations. This looks reasonable to me. The idea of keeping a project's feature list being mirrored and filled in per platform sounds like something we would want to enforce at the tf.org level IMO. At the same time, this could also be handled at the build system level as you pointed out, or more precisely by the configuration manager. I am thinking about the Linux kernel, where support for a particular feature is handled (and documented) through the KConfig system. This might be a more scalable approach. And it doesn't prevent us from also auto-generating some feature list out of the Kconfig files for making this information more accessible to users. > My secondary concern is being able to consistently track tickets/bugs with features. Thus, I'm recommending that the features on that list be used with the ticket/issue system by feature name. This would allow users to find all bugs for Feature X on Platform Y in Project Z. > Related to that, when I mentioned "tags." I wasn't thinking of Git tags, but "labels" in the ticket/issue tracking system(s). Different systems work differently for labeling/categorizing issues, but the goal is to provide a consistent way (per project) to find issues related to a feature on a platform. > > If requiring a feature list it is too much at the tf.org level then I'll be satisfied to push for that kind of documentation in the projects or platforms I'm involved in if/as appropriate. Yes, good point, I think it would be desirable to be able to tie tickets to some specific platform/feature/version. And I think it makes sense to unify this across tf.org projects. > Regarding the other conversational tidbits: > > Thanks for pointing out that the original proposal does say "builds all configurations supported by this platform" under "Fully Supported." I can see the intention here now. Substituting "features" for "configurations" would broaden the meaning a bit. OK, I will change the wording, thanks for the suggestion. > You said: "I am starting to think that we need a list of items to be defined per project." > Yes, this sounds like a great idea. > > My original mention of wanting a "stronger standard put forth for platform documentation" was a response to seeing "Limited Support" in the original proposal allowing documentation to fall out of date. > > > Hope that clarifies some of my thoughts. If not, I'm happy to continue the discussion. Thanks again for taking feedback! > > Erik Shreve, PSEM > Software Security Engineer & Architect (CMCU Platform Development) > > -----Original Message----- > From: Sandrine Bailleux [mailto:sandrine.bailleux@arm.com] > Sent: Wednesday, April 01, 2020 4:18 AM > To: Shreve, Erik; tf-a; tf-m(a)lists.trustedfirmware.org; tsc(a)lists.trustedfirmware.org; op-tee(a)linaro.org > Cc: nd(a)arm.com > Subject: Re: [EXTERNAL] [TF-M] Project Maintenance Proposal for tf.org Projects > > Hello Erik, > > Thanks for the feedback. > > On 3/26/20 3:37 PM, Shreve, Erik wrote: >> Sandrine, >> >> Really glad to see this being pulled together. A couple of areas of feedback around the Platform Support Life Cycle. >> >> As previously mentioned there are two orthogonal concerns captured in the current life cycle: Support and Functionality. >> I'd like to see these split out. > > Yes, you are the second person to mention that and I agree with you > both. Unless someone disagrees, I intend to update the proposal and > separate these 2 concepts in the next version of the document. > >> For functionality, chip vendors may not have a business case for supporting all features on a given platform but they may provide full support for the features they have chosen to include. >> A simple example would be supporting PSA FF Isolation Level 1 only due to lack of HW isolation support needed to achieve Isolation Level 2 or greater. > > I completely agree. It would not make sense to support all features on > all platforms just for the sake of completeness. Each platform ought to > implement what is relevant in its case. > > That's what the current proposal tried to convey: a fully supported > platform must "build all configurations *supported by this platform*" > and "All *supported* configurations are tested in the CI". The key word > here is supported and that would be defined by the platform itself. But > I can see that maybe this wasn't clear enough. Your proposal below makes > that a lot clearer. > >> Also, I'd like to see a stronger standard put forth for platform documentation. If a platform is "supported," I believe the documentation should be complete and accurate. A lack of complete and clear documentation leaves open a wide door for misuse/misconfiguration which could result in a vulnerable system. > > Fair point. > > But is it something we should include in this proposal or should we push > it to a separate document setting expectations for the project's > documentation, which the current general proposal could refer to (as in, > "the platform should provide quality documentation up to the project's > criteria defined in document XXX')? > > This is definitely an important topic but I am wary of keeping the > tf.org proposal concise and focused at this point. I am worried that if > we put too much stuff in it discussions will diverge too much and we > might never reach an agreement. > > The same applies to testing standards for example, we could detail that > in the proposal or simply leave it to projects to define it separately. > >> Here is a more concrete proposal: >> >> Functional Support: >> Each project shall provide a standard feature or functionality list. >> Each platform shall include in its documentation a copy of this list with the supported functionality marked as supported. >> The platform documentation may reference a ticket if support is planned but not yet present. >> The platform documentation shall explicitly state if a feature or function has no plans for support. > > Regarding the last item, this would require all platform maintainers to > update their documentation every time a new feature is added to the > project's global list of features. This seems too much of a constraint > and unnecessary maintenance burden to me. > > I think a better, more lightweight alternative might be to let platform > maintainers list what's supported and if some feature is not listed, it > implies that it is not supported. This does not prevent platform > maintainers from indicating their future plans of supporting a feature > if they want to. > >> The feature/functionality list shall be versioned, with the version tied to the release version(s) of the project. >> In this way, it will be clear if a platform was last officially updated for version X but the project is currently at version Y > X. > > I can see that Joakim Bech proposed something similar, with more details > about how this was implemented for OP-TEE. > >> Note: projects will need to adopt (if they have not already) a version scheme that distinguishes between feature updates and bug fixes. > > Sorry I didn't get this, could you please elaborate? > >> Each project and platform shall use tags or similar functionality on tickets to associate tickets to features/functionality and platforms. >> If the names of tags can't match the name of the feature or platform exactly then a mapping shall be provided in the appropriate document(s). > > If there's no appropriate tag in some cases, I guess we could always use > a git SHA1 of a specific commit. > >> Life Cycle State >> >> Fully Supported >> There is (at least) one active code owner for this platform. >> All supported features build and either all tests pass or failures are associated with tracked known issues. >> Other (not associated to a test) Known Issues are tracked >> Documentation is up to date >> >> Note: Projects should document standards on how "active" code ownership is measured and >> further document standards on how code owners are warned about impending life cycle state changes. > > Yes, good point, that is currently undefined in the proposal but I agree > that it needs defining per project. I will add an item in the last > section of the document. > > I am starting to think that we need a list of items to be defined per > project. This list would complement the general tf.org proposal. Things > like code owners/maintainers activity, code review timelines, and so on. > >> >> Orphan >> There is no active code owner >> All supported features build and either all tests pass or failures are associated with tracked known issues. >> Other (not associated to a test) Known Issues may not have been maintained (as there is no active code owner) >> Documentation status is unclear since there is no active code owner. >> There has been no change to the feature/functionality list in the project since the platform was last "Fully Supported" > > I am confused, you said earlier that you would like to see the concepts > of support and functionality split out, but here you're listing 'orphan' > as one of the possible states... Did I miss your point? > >> Out of date >> Same as orphan, but either: >> there have been changes to the feature/functionality list, or >> there are failing tests without tracked tickets, or >> there are known documentation issues. >> >> Deprecated >> Same as Out of Date, but the build is broken. Platform may be removed from the project codebase in the future. >> >> Erik Shreve, PSEM >> Software Security Engineer & Architect (CMCU Platform Development)

6 years, 1 month

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M