- TF-A - lists.trustedfirmware.org

[RAS] BL32 UnRecognized Event - 0xC4000061 and BL31 Crashed

by 吴斌(郅隆)

Dear Friends, I am using TF-A to test RAS feature. When I triggered DMC620 RAS error in Linux(echo 0x123 > /sys/kernel/debug/sdei_ras_poison). BL32 will recieve UnRecognized Event - 0xC4000061(SP_EVENT_COMPLETE_AARCH64) and finally BL31 crashed. In my understanding, this 0xC4000061 should consumed by BL31, not send it to BL32 again. A piece of error log as below: ************************************* CperWrite - CperAddress@0xFF610064 CperWrite - 1 Section@FFBE91A8, Length 80, SectionType@FFBE9138 CperWrite - Got Error Section: Platform Memory. MmEntryPoint Done Received delegated event X0 : 0xC4000061 X1 : 0x0 X2 : 0x0 X3 : 0x0 Received event - 0xC4000061 on cpu 0 UnRecognized Event - 0xC4000061 Failed delegated event 0xC4000061, Status 0x2 Unhandled Exception in EL3. x30 = 0x0000000000000000 x0 = 0x00000000ff007e00 x1 = 0xfffffffffffffffe x2 = 0x00000000600003c0 x3 = 0x0000000000000000 x4 = 0x0000000000000000 x5 = 0x0000000000000000 x6 = 0x00000000ff015080 x7 = 0x0000000000000000 x8 = 0x00000000c4000061 x9 = 0x0000000000000021 x10 = 0x0000000000000040 x11 = 0x00000000ff00f2b0 x12 = 0x00000000ff0118c0 x13 = 0x0000000000000002 x14 = 0x00000000ff016b70 x15 = 0x00000000ff003f20 x16 = 0x0000000000000044 x17 = 0x00000000ff010430 x18 = 0x0000000000000e3c x19 = 0x0000000000000000 More error log please refer to attachment. My question is, 1. Does BL31 need to send 0xC4000061 event to BL32 again? 2. Does current TF-A support to run RAS test? It seems BL31 will crash. Appreciate your help. BRs， Bin Wu

5 years, 1 month

1
0
0 0

Re: [TF-A] BRANCH_PROTECTION

by Varun Wadekar

Hello, Can someone please help clarify? -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Varun Wadekar via TF-A Sent: Tuesday, April 7, 2020 9:58 PM To: tf-a(a)lists.trustedfirmware.org Cc: Kalyani Chidambaram Vaidyanathan <kalyanic(a)nvidia.com>; Anthony Zhou <anzhou(a)nvidia.com> Subject: [TF-A] BRANCH_PROTECTION External email: Use caution opening links or attachments Hello, Can someone please help me understand if 1. a 'value' of '1' for BRANCH_PROTECTION covers the PAuth protection provided by a value of '2' and/or '3'? 2. there is a way to enable BTI and "pac-ret" at the same time? The docs provide this information. <snip> - ``BRANCH_PROTECTION``: Numeric value to enable ARMv8.3 Pointer Authentication and ARMv8.5 Branch Target Identification support for TF-A BL images themselves. If enabled, it is needed to use a compiler that supports the option ``-mbranch-protection``. Selects the branch protection features to use: - 0: Default value turns off all types of branch protection - 1: Enables all types of branch protection features - 2: Return address signing to its standard level - 3: Extend the signing to include leaf functions The table below summarizes ``BRANCH_PROTECTION`` values, GCC compilation options and resulting PAuth/BTI<https://tegra-sw-opengrok.nvidia.com/source/s?path=PAuth/BTI&project=stage-…> features. +-------+--------------+-------+-----+ | Value | GCC option | PAuth | BTI | +=======+==============+=======+=====+ | 0 | none | N | N | +-------+--------------+-------+-----+ | 1 | standard | Y | Y | +-------+--------------+-------+-----+ | 2 | pac-ret | Y | N | +-------+--------------+-------+-----+ | 3 | pac-ret+leaf | Y | N | +-------+--------------+-------+-----+ This option defaults to 0 and this is an experimental feature. Note that Pointer Authentication is enabled for Non-secure world irrespective of the value of this option if the CPU supports it. <snip> Thanks, Varun ________________________________ This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ________________________________

5 years, 1 month

1
0
0 0

Trusted Firmware-A 2.3 release candidate tags created

by Bipin Ravi

All, We have applied the release candidate tags(v2.3-rc0<https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.3-rc0>) to the TF-A source and TF-A tests trees as part of the upcoming TF-A v2.3 release. Please use these tags to perform any platform specific tests planned. https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/ https://git.trustedfirmware.org/TF-A/tf-a-tests.git/ Thanks & best regards, [cid:image001.jpg@01D60DB5.48537900] Bipin Ravi | Principal Design Enginee Bipin.ravi(a)arm.com<mailto:Bipin.ravi@arm.com> | Skype: Bipin.Ravi.ARM Direct: +1-512-225 -1071 | Mobile: +1-214-212-0794 5707 Southwest Parkway, Suite 100, Austin, TX 78735

5 years, 1 month

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 3 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 3 of 3 defect(s) ** CID 355490: Uninitialized variables (UNINIT) /plat/brcm/board/stingray/src/paxb.c: 516 in pcie_cores_init() ________________________________________________________________________________________________________ *** CID 355490: Uninitialized variables (UNINIT) /plat/brcm/board/stingray/src/paxb.c: 516 in pcie_cores_init() 510 511 pcie_core_soft_reset(core_idx); 512 513 VERBOSE("PCIe core %u is powered up\n", core_idx); 514 } 515 >>> CID 355490: Uninitialized variables (UNINIT) >>> Using uninitialized value "ret". 516 return ret; 517 } 518 519 void paxb_rc_cfg_write(unsigned int core_idx, unsigned int where, 520 uint32_t val) 521 { ** CID 355489: Control flow issues (NO_EFFECT) /plat/brcm/board/stingray/src/bl2_setup.c: 685 in plat_bcm_bl2_plat_arch_setup() ________________________________________________________________________________________________________ *** CID 355489: Control flow issues (NO_EFFECT) /plat/brcm/board/stingray/src/bl2_setup.c: 685 in plat_bcm_bl2_plat_arch_setup() 679 EMMC_ERASE_PARTITION); 680 #endif 681 682 bcm_board_detect(); 683 #ifdef DRIVER_EMMC_ENABLE 684 /* Initialize the card, if it is not */ >>> CID 355489: Control flow issues (NO_EFFECT) >>> This less-than-zero comparison of an unsigned value is never true. "bcm_emmc_init(true) < 0U". 685 if (bcm_emmc_init(true) < 0) 686 WARN("eMMC Card Initialization Failed!!!\n"); 687 #endif 688 689 #if BL2_TEST_I2C 690 i2c_test(); ** CID 355488: (VARARGS) /plat/brcm/board/common/bcm_elog.c: 251 in bcm_elog() /plat/brcm/board/common/bcm_elog.c: 253 in bcm_elog() /plat/brcm/board/common/bcm_elog.c: 241 in bcm_elog() /plat/brcm/board/common/bcm_elog.c: 234 in bcm_elog() /plat/brcm/board/common/bcm_elog.c: 223 in bcm_elog() /plat/brcm/board/common/bcm_elog.c: 239 in bcm_elog() ________________________________________________________________________________________________________ *** CID 355488: (VARARGS) /plat/brcm/board/common/bcm_elog.c: 251 in bcm_elog() 245 case 'l': 246 bit64 = 1; 247 fmt++; 248 goto loop; 249 case 'u': 250 if (bit64) >>> CID 355488: (VARARGS) >>> Calling va_arg on va_list "args", which has not been prepared with va_start(). 251 unum = va_arg(args, uint64_t); 252 else 253 unum = va_arg(args, uint32_t); 254 255 elog_unsigned_num(elog, unum, 10); 256 break; /plat/brcm/board/common/bcm_elog.c: 253 in bcm_elog() 247 fmt++; 248 goto loop; 249 case 'u': 250 if (bit64) 251 unum = va_arg(args, uint64_t); 252 else >>> CID 355488: (VARARGS) >>> Calling va_arg on va_list "args", which has not been prepared with va_start(). 253 unum = va_arg(args, uint32_t); 254 255 elog_unsigned_num(elog, unum, 10); 256 break; 257 default: 258 /* Exit on any other format specifier */ /plat/brcm/board/common/bcm_elog.c: 241 in bcm_elog() 235 elog_string(elog, str); 236 break; 237 case 'x': 238 if (bit64) 239 unum = va_arg(args, uint64_t); 240 else >>> CID 355488: (VARARGS) >>> Calling va_arg on va_list "args", which has not been prepared with va_start(). 241 unum = va_arg(args, uint32_t); 242 243 elog_unsigned_num(elog, unum, 16); 244 break; 245 case 'l': 246 bit64 = 1; /plat/brcm/board/common/bcm_elog.c: 234 in bcm_elog() 228 } else 229 unum = (unsigned long)num; 230 231 elog_unsigned_num(elog, unum, 10); 232 break; 233 case 's': >>> CID 355488: (VARARGS) >>> Calling va_arg on va_list "args", which has not been prepared with va_start(). 234 str = va_arg(args, char *); 235 elog_string(elog, str); 236 break; 237 case 'x': 238 if (bit64) 239 unum = va_arg(args, uint64_t); /plat/brcm/board/common/bcm_elog.c: 223 in bcm_elog() 217 switch (*fmt) { 218 case 'i': /* Fall through to next one */ 219 case 'd': 220 if (bit64) 221 num = va_arg(args, int64_t); 222 else >>> CID 355488: (VARARGS) >>> Calling va_arg on va_list "args", which has not been prepared with va_start(). 223 num = va_arg(args, int32_t); 224 225 if (num < 0) { 226 elog_putchar(elog, '-'); 227 unum = (unsigned long)-num; 228 } else /plat/brcm/board/common/bcm_elog.c: 239 in bcm_elog() 233 case 's': 234 str = va_arg(args, char *); 235 elog_string(elog, str); 236 break; 237 case 'x': 238 if (bit64) >>> CID 355488: (VARARGS) >>> Calling va_arg on va_list "args", which has not been prepared with va_start(). 239 unum = va_arg(args, uint64_t); 240 else 241 unum = va_arg(args, uint32_t); 242 243 elog_unsigned_num(elog, unum, 16); 244 break; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

5 years, 1 month

1
0
0 0

BRANCH_PROTECTION

by Varun Wadekar

Hello, Can someone please help me understand if 1. a 'value' of '1' for BRANCH_PROTECTION covers the PAuth protection provided by a value of '2' and/or '3'? 2. there is a way to enable BTI and "pac-ret" at the same time? The docs provide this information. <snip> - ``BRANCH_PROTECTION``: Numeric value to enable ARMv8.3 Pointer Authentication and ARMv8.5 Branch Target Identification support for TF-A BL images themselves. If enabled, it is needed to use a compiler that supports the option ``-mbranch-protection``. Selects the branch protection features to use: - 0: Default value turns off all types of branch protection - 1: Enables all types of branch protection features - 2: Return address signing to its standard level - 3: Extend the signing to include leaf functions The table below summarizes ``BRANCH_PROTECTION`` values, GCC compilation options and resulting PAuth/BTI<https://tegra-sw-opengrok.nvidia.com/source/s?path=PAuth/BTI&project=stage-…> features. +-------+--------------+-------+-----+ | Value | GCC option | PAuth | BTI | +=======+==============+=======+=====+ | 0 | none | N | N | +-------+--------------+-------+-----+ | 1 | standard | Y | Y | +-------+--------------+-------+-----+ | 2 | pac-ret | Y | N | +-------+--------------+-------+-----+ | 3 | pac-ret+leaf | Y | N | +-------+--------------+-------+-----+ This option defaults to 0 and this is an experimental feature. Note that Pointer Authentication is enabled for Non-secure world irrespective of the value of this option if the CPU supports it. <snip> Thanks, Varun ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------

5 years, 1 month

1
0
0 0

Re: [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.

5 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.

5 years, 1 month

1
0
0 0

Re: [TF-A] [TF-TSC] [TF-M] 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

5 years, 1 month

2
1
0 0

Re: [TF-A] [EXTERNAL] [TF-M] 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)

5 years, 1 month

1
0
0 0

Re: [TF-A] fconf: Validating config data

by Louis Mayencourt

Hi Raghu, I do agree with you: case 2 and 3 are similar (wrongly formed DTB) and should lead to the same behavior. A mandatory property miss or a hit with a structurally incorrect node means that the DTB doesn't follow the provided binding document. Such a DTB shouldn't be considered as valid and should trigger a build failure and/or a code panic. With the current implementation, case 2 and 3 are similar. The property_getter() functions expect a specific format of the node. If a node is not found or structurally incorrect, the function will return an error code, which will lead to a panic(). regards, Louis ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Raghu Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 06 April 2020 19:51 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] fconf: Validating config data Thanks Louis. This new terminology helps. Let me spell this out again just to make sure we're on the same page. The following are the cases: 1) Mandatory Property hit, nodes are structurally correct - Works normally. 2) Mandatory Property hit, nodes are structurally *incorrect* - Asserts should catch structural issues during development because system integrator expected to not make mistakes with number of nodes etc. 3) Mandatory Property miss - Panic(). Why is this case causing a panic, but not case 2? You are allowing for some one to make the mistake of not having a mandatory property, but assume that if a mandatory property is present, it is always structurally sound. This is the part i have a problem with. In my view case 2 and case 3 should panic and code should not just assert on mandatory properties and must ALWAYS check for structural soundness of an FDT property. Similarly there are 3 cases for optional properties. My question: Why does case 3 panic, but not case 2 ? It sounds like your assumption is that case 2 cannot happen. If case 2 cannot happen, i claim that case 3 cannot happen either. Let me know what you think! Thanks Raghu On 4/6/20 3:57 AM, Louis Mayencourt via TF-A wrote: > Hi Raghu, > > Let me try to clarify/reword my idea: > > We complete the fconf documentation with a binding document, which > defines the nodes that should be present in the config DTB to consider > it as valid/well-formed. The document contains two kinds of node: > > * mandatory (critical): the firmware can't proceed without this > information (example: load address, image UUID, ...). If this node > is not present in the DTS, the build fails and/or the code panic. > > * optional (no-critical): the firmware can assume or assign a default > value and proceed (example: uart config, enable authentication flag, > ...). Such a property is used to influence the default behavior of > the firmware. > > />> This is non-deterministic failure./ > The miss of a mandatory (critical) node will always lead to a build > failure / code panic. > The miss of an optional (no-critical) node should not influence the > default behavior of the firmware. > > />> Is it not confusing to make the assumption that a DTB is "well > formed",i.e expect the build process/integrator to not mess up the >>> structure or number of nodes but allow the same integrator to miss a critical property in the DTB?/ > A DTB with a missing mandatory (critical) property should not be > considered well formed. > > />> If there is a missing critical property, is that not a badly formed > DTB?/ > With the above definition, it is. > > />> And if so, why not check for badly formed DTB's uniformly in code > and why only check for missing "critical" properties?/ > With the rewording of "critical" / "no-critical" to "mandatory" / > "optional", I think the situation is clearer: A DTB with a missing > "optional" node/property is is still considered well-formed. > > I hope I answered your questions and clarify the idea behind the design. > > regards, > Louis > > ------------------------------------------------------------------------ > *From:* Raghu Krishnamurthy <raghu.ncstate(a)icloud.com> > *Sent:* 05 April 2020 00:06 > *To:* Louis Mayencourt <Louis.Mayencourt(a)arm.com> > *Subject:* Re: [TF-A] fconf: Validating config data > Thanks Louis. > >>you can imagine a well-formed DTB which contain a > >>critical set of properties and can contain some optional properties. > > This makes things even more confusing. The assumption we are asking code > to make is that the DTB is always "well formed", ie don't check for > structural issues such as extra nodes etc, but we are still making the > distinctions between critical and non-critical properties, that may or > may not exist in the DTB, which may or may not cause a panic. This is > non-deterministic failure. > Is it not confusing to make the assumption that a DTB is "well > formed",i.e expect the build process/integrator to not mess up the > structure or number of nodes but allow the same integrator to miss a > critical property in the DTB? If there is a missing critical property, > is that not a badly formed DTB ? And if so, why not check for badly > formed DTB's uniformly in code and why only check for missing "critical" > properties? > > -Raghu > > On 4/3/20 3:16 AM, Louis Mayencourt wrote: >> Hi Raghu, >> >> I do agree that we need something similar to a binding document for >> fconf properties. (similar to >> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3694/2/docs/…). > >> At least for the common properties. >> >> The main idea behind the return code of the populator function was to >> allow the code to handle no-critical property misses or to handle >> critical failure by calling a platform hook. >> With this in mind, you can imagine a well-formed DTB which contain a >> critical set of properties and can contain some optional properties. The >> return code and the populator "name" / "config" can be used to handle >> this two cases. >> >> I tried to keep the design of fconf really simple, to leave room for >> improvement according to feedbacks. Thanks for helping improving it! >> >> Regards, >> Louis >> ------------------------------------------------------------------------ >> *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Raghu >> Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> >> *Sent:* 03 April 2020 10:15 >> *To:* tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> >> *Subject:* Re: [TF-A] fconf: Validating config data >> A further point is that the fconf populators return an error code and >> panics on error today. But if we are making the assumption that the >> DTB's are well formed, do we really need to fail or even return an error >> code? >> >> -Raghu >> >> On 4/3/20 1:51 AM, Raghu Krishnamurthy via TF-A wrote: >>> Hi All, (Sorry for the long email) >>> >>> The review >>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3845 >>> attempts to fix bounds check in the fconf populator code for the >>> topology and SP's. During review, Sandrine thoughtfully pointed out that >>> there were discussions around bounds check along the same lines in the >>> review >>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3492 and >>> it was deemed sufficient to have assertions in code and it was safe to >>> make the assumption that the DTB is always well formed and contains >>> valid values. I think this email mostly echoes Sandrine's concern from >>> review 3492. >>> >>> While i agree with the assumptions, I am generally of the opinion that >>> we should validate/range-check any data, even if it is signed. Being >>> signed does not necessarily mean the data is well formed/valid. If there >>> is a mistake in the build process and it is validly signed, it is >>> possible that we silently corrupt state/data that could later be used to >>> exploit firmware and/or make debugging hard. This is probably far >>> fetched, but the cost of adding the check is trivial to avoid this >>> possibility. >>> >>> I imagine the case where you have secure partitions signed by different >>> entity other than the silicon provider(dual root-of-trust). A silicon >>> provider provides a dev system for the SP provider to test and validate >>> the SP's on silicon. The silicon has production firmware(and hence no >>> assertions), but loads signed data from the SP provider which has some >>> invalid values. There could be silent corruption without any indication >>> whatsoever about what went wrong and it may be hard to debug if/when >>> there are issues. >>> Also, testing does not necessarily catch all invalid values since you >>> will likely not get 100% coverage, given the number of config options >>> available. Moreover, the code today, is not consistent in asserting on >>> every property for valid values and the failure mode is not >>> consistent/deterministic. It seems like every config option should have >>> a list of valid values or a range of acceptable values that must be at a >>> minimum asserted on. >>> I also wouldn't discount platforms such as RPI, where TRUSTED_BOARD_BOOT >>> is likely to be turned off since it really does not provide any >>> security, so assuming we always have signed data might not be valid. >>> >>> Anyway, is this decision worth revisiting? Too paranoid perhaps? :P >>> >>> >>> Thanks >>> Raghu >> -- >> TF-A mailing list >> TF-A(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >> 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. > -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a 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.

5 years, 1 month

1
0
0 0

Re: [TF-A] fconf: Validating config data

by Raghu Krishnamurthy

Thanks Louis. This new terminology helps. Let me spell this out again just to make sure we're on the same page. The following are the cases: 1) Mandatory Property hit, nodes are structurally correct - Works normally. 2) Mandatory Property hit, nodes are structurally *incorrect* - Asserts should catch structural issues during development because system integrator expected to not make mistakes with number of nodes etc. 3) Mandatory Property miss - Panic(). Why is this case causing a panic, but not case 2? You are allowing for some one to make the mistake of not having a mandatory property, but assume that if a mandatory property is present, it is always structurally sound. This is the part i have a problem with. In my view case 2 and case 3 should panic and code should not just assert on mandatory properties and must ALWAYS check for structural soundness of an FDT property. Similarly there are 3 cases for optional properties. My question: Why does case 3 panic, but not case 2 ? It sounds like your assumption is that case 2 cannot happen. If case 2 cannot happen, i claim that case 3 cannot happen either. Let me know what you think! Thanks Raghu On 4/6/20 3:57 AM, Louis Mayencourt via TF-A wrote: > Hi Raghu, > > Let me try to clarify/reword my idea: > > We complete the fconf documentation with a binding document, which > defines the nodes that should be present in the config DTB to consider > it as valid/well-formed. The document contains two kinds of node: > > * mandatory (critical): the firmware can't proceed without this > information (example: load address, image UUID, ...). If this node > is not present in the DTS, the build fails and/or the code panic. > > * optional (no-critical): the firmware can assume or assign a default > value and proceed (example: uart config, enable authentication flag, > ...). Such a property is used to influence the default behavior of > the firmware. > > />> This is non-deterministic failure./ > The miss of a mandatory (critical) node will always lead to a build > failure / code panic. > The miss of an optional (no-critical) node should not influence the > default behavior of the firmware. > > />> Is it not confusing to make the assumption that a DTB is "well > formed",i.e expect the build process/integrator to not mess up the >>> structure or number of nodes but allow the same integrator to miss a critical property in the DTB?/ > A DTB with a missing mandatory (critical) property should not be > considered well formed. > > />> If there is a missing critical property, is that not a badly formed > DTB?/ > With the above definition, it is. > > />> And if so, why not check for badly formed DTB's uniformly in code > and why only check for missing "critical" properties?/ > With the rewording of "critical" / "no-critical" to "mandatory" / > "optional", I think the situation is clearer: A DTB with a missing > "optional" node/property is is still considered well-formed. > > I hope I answered your questions and clarify the idea behind the design. > > regards, > Louis > > ------------------------------------------------------------------------ > *From:* Raghu Krishnamurthy <raghu.ncstate(a)icloud.com> > *Sent:* 05 April 2020 00:06 > *To:* Louis Mayencourt <Louis.Mayencourt(a)arm.com> > *Subject:* Re: [TF-A] fconf: Validating config data > Thanks Louis. > >>you can imagine a well-formed DTB which contain a > >>critical set of properties and can contain some optional properties. > > This makes things even more confusing. The assumption we are asking code > to make is that the DTB is always "well formed", ie don't check for > structural issues such as extra nodes etc, but we are still making the > distinctions between critical and non-critical properties, that may or > may not exist in the DTB, which may or may not cause a panic. This is > non-deterministic failure. > Is it not confusing to make the assumption that a DTB is "well > formed",i.e expect the build process/integrator to not mess up the > structure or number of nodes but allow the same integrator to miss a > critical property in the DTB? If there is a missing critical property, > is that not a badly formed DTB ? And if so, why not check for badly > formed DTB's uniformly in code and why only check for missing "critical" > properties? > > -Raghu > > On 4/3/20 3:16 AM, Louis Mayencourt wrote: >> Hi Raghu, >> >> I do agree that we need something similar to a binding document for >> fconf properties. (similar to >> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3694/2/docs/…). > >> At least for the common properties. >> >> The main idea behind the return code of the populator function was to >> allow the code to handle no-critical property misses or to handle >> critical failure by calling a platform hook. >> With this in mind, you can imagine a well-formed DTB which contain a >> critical set of properties and can contain some optional properties. The >> return code and the populator "name" / "config" can be used to handle >> this two cases. >> >> I tried to keep the design of fconf really simple, to leave room for >> improvement according to feedbacks. Thanks for helping improving it! >> >> Regards, >> Louis >> ------------------------------------------------------------------------ >> *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Raghu >> Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> >> *Sent:* 03 April 2020 10:15 >> *To:* tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> >> *Subject:* Re: [TF-A] fconf: Validating config data >> A further point is that the fconf populators return an error code and >> panics on error today. But if we are making the assumption that the >> DTB's are well formed, do we really need to fail or even return an error >> code? >> >> -Raghu >> >> On 4/3/20 1:51 AM, Raghu Krishnamurthy via TF-A wrote: >>> Hi All, (Sorry for the long email) >>> >>> The review >>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3845 >>> attempts to fix bounds check in the fconf populator code for the >>> topology and SP's. During review, Sandrine thoughtfully pointed out that >>> there were discussions around bounds check along the same lines in the >>> review >>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3492 and >>> it was deemed sufficient to have assertions in code and it was safe to >>> make the assumption that the DTB is always well formed and contains >>> valid values. I think this email mostly echoes Sandrine's concern from >>> review 3492. >>> >>> While i agree with the assumptions, I am generally of the opinion that >>> we should validate/range-check any data, even if it is signed. Being >>> signed does not necessarily mean the data is well formed/valid. If there >>> is a mistake in the build process and it is validly signed, it is >>> possible that we silently corrupt state/data that could later be used to >>> exploit firmware and/or make debugging hard. This is probably far >>> fetched, but the cost of adding the check is trivial to avoid this >>> possibility. >>> >>> I imagine the case where you have secure partitions signed by different >>> entity other than the silicon provider(dual root-of-trust). A silicon >>> provider provides a dev system for the SP provider to test and validate >>> the SP's on silicon. The silicon has production firmware(and hence no >>> assertions), but loads signed data from the SP provider which has some >>> invalid values. There could be silent corruption without any indication >>> whatsoever about what went wrong and it may be hard to debug if/when >>> there are issues. >>> Also, testing does not necessarily catch all invalid values since you >>> will likely not get 100% coverage, given the number of config options >>> available. Moreover, the code today, is not consistent in asserting on >>> every property for valid values and the failure mode is not >>> consistent/deterministic. It seems like every config option should have >>> a list of valid values or a range of acceptable values that must be at a >>> minimum asserted on. >>> I also wouldn't discount platforms such as RPI, where TRUSTED_BOARD_BOOT >>> is likely to be turned off since it really does not provide any >>> security, so assuming we always have signed data might not be valid. >>> >>> Anyway, is this decision worth revisiting? Too paranoid perhaps? :P >>> >>> >>> Thanks >>> Raghu >> -- >> TF-A mailing list >> TF-A(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >> 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. >

5 years, 1 month

1
0
0 0

Re: [TF-A] fconf: Validating config data

by Louis Mayencourt

Hi Raghu, Let me try to clarify/reword my idea: We complete the fconf documentation with a binding document, which defines the nodes that should be present in the config DTB to consider it as valid/well-formed. The document contains two kinds of node: * mandatory (critical): the firmware can't proceed without this information (example: load address, image UUID, ...). If this node is not present in the DTS, the build fails and/or the code panic. * optional (no-critical): the firmware can assume or assign a default value and proceed (example: uart config, enable authentication flag, ...). Such a property is used to influence the default behavior of the firmware. >> This is non-deterministic failure. The miss of a mandatory (critical) node will always lead to a build failure / code panic. The miss of an optional (no-critical) node should not influence the default behavior of the firmware. >> Is it not confusing to make the assumption that a DTB is "well formed",i.e expect the build process/integrator to not mess up the >> structure or number of nodes but allow the same integrator to miss a critical property in the DTB? A DTB with a missing mandatory (critical) property should not be considered well formed. >> If there is a missing critical property, is that not a badly formed DTB? With the above definition, it is. >> And if so, why not check for badly formed DTB's uniformly in code and why only check for missing "critical" properties? With the rewording of "critical" / "no-critical" to "mandatory" / "optional", I think the situation is clearer: A DTB with a missing "optional" node/property is is still considered well-formed. I hope I answered your questions and clarify the idea behind the design. regards, Louis ________________________________ From: Raghu Krishnamurthy <raghu.ncstate(a)icloud.com> Sent: 05 April 2020 00:06 To: Louis Mayencourt <Louis.Mayencourt(a)arm.com> Subject: Re: [TF-A] fconf: Validating config data Thanks Louis. >>you can imagine a well-formed DTB which contain a >>critical set of properties and can contain some optional properties. This makes things even more confusing. The assumption we are asking code to make is that the DTB is always "well formed", ie don't check for structural issues such as extra nodes etc, but we are still making the distinctions between critical and non-critical properties, that may or may not exist in the DTB, which may or may not cause a panic. This is non-deterministic failure. Is it not confusing to make the assumption that a DTB is "well formed",i.e expect the build process/integrator to not mess up the structure or number of nodes but allow the same integrator to miss a critical property in the DTB? If there is a missing critical property, is that not a badly formed DTB ? And if so, why not check for badly formed DTB's uniformly in code and why only check for missing "critical" properties? -Raghu On 4/3/20 3:16 AM, Louis Mayencourt wrote: > Hi Raghu, > > I do agree that we need something similar to a binding document for > fconf properties. (similar to > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3694/2/docs/…). > At least for the common properties. > > The main idea behind the return code of the populator function was to > allow the code to handle no-critical property misses or to handle > critical failure by calling a platform hook. > With this in mind, you can imagine a well-formed DTB which contain a > critical set of properties and can contain some optional properties. The > return code and the populator "name" / "config" can be used to handle > this two cases. > > I tried to keep the design of fconf really simple, to leave room for > improvement according to feedbacks. Thanks for helping improving it! > > Regards, > Louis > ------------------------------------------------------------------------ > *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Raghu > Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> > *Sent:* 03 April 2020 10:15 > *To:* tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> > *Subject:* Re: [TF-A] fconf: Validating config data > A further point is that the fconf populators return an error code and > panics on error today. But if we are making the assumption that the > DTB's are well formed, do we really need to fail or even return an error > code? > > -Raghu > > On 4/3/20 1:51 AM, Raghu Krishnamurthy via TF-A wrote: >> Hi All, (Sorry for the long email) >> >> The review >> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3845 >> attempts to fix bounds check in the fconf populator code for the >> topology and SP's. During review, Sandrine thoughtfully pointed out that >> there were discussions around bounds check along the same lines in the >> review >> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3492 and >> it was deemed sufficient to have assertions in code and it was safe to >> make the assumption that the DTB is always well formed and contains >> valid values. I think this email mostly echoes Sandrine's concern from >> review 3492. >> >> While i agree with the assumptions, I am generally of the opinion that >> we should validate/range-check any data, even if it is signed. Being >> signed does not necessarily mean the data is well formed/valid. If there >> is a mistake in the build process and it is validly signed, it is >> possible that we silently corrupt state/data that could later be used to >> exploit firmware and/or make debugging hard. This is probably far >> fetched, but the cost of adding the check is trivial to avoid this >> possibility. >> >> I imagine the case where you have secure partitions signed by different >> entity other than the silicon provider(dual root-of-trust). A silicon >> provider provides a dev system for the SP provider to test and validate >> the SP's on silicon. The silicon has production firmware(and hence no >> assertions), but loads signed data from the SP provider which has some >> invalid values. There could be silent corruption without any indication >> whatsoever about what went wrong and it may be hard to debug if/when >> there are issues. >> Also, testing does not necessarily catch all invalid values since you >> will likely not get 100% coverage, given the number of config options >> available. Moreover, the code today, is not consistent in asserting on >> every property for valid values and the failure mode is not >> consistent/deterministic. It seems like every config option should have >> a list of valid values or a range of acceptable values that must be at a >> minimum asserted on. >> I also wouldn't discount platforms such as RPI, where TRUSTED_BOARD_BOOT >> is likely to be turned off since it really does not provide any >> security, so assuming we always have signed data might not be valid. >> >> Anyway, is this decision worth revisiting? Too paranoid perhaps? :P >> >> >> Thanks >> Raghu > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > 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.

5 years, 1 month

1
0
0 0

Re: [TF-A] fconf: Validating config data

by Raghu Krishnamurthy

+tf-a list On 4/4/20 4:06 PM, Raghu Krishnamurthy wrote: > Thanks Louis. > >>you can imagine a well-formed DTB which contain a > >>critical set of properties and can contain some optional properties. > > This makes things even more confusing. The assumption we are asking code > to make is that the DTB is always "well formed", ie don't check for > structural issues such as extra nodes etc, but we are still making the > distinctions between critical and non-critical properties, that may or > may not exist in the DTB, which may or may not cause a panic. This is > non-deterministic failure. > Is it not confusing to make the assumption that a DTB is "well > formed",i.e expect the build process/integrator to not mess up the > structure or number of nodes but allow the same integrator to miss a > critical property in the DTB? If there is a missing critical property, > is that not a badly formed DTB ? And if so, why not check for badly > formed DTB's uniformly in code and why only check for missing "critical" > properties? > > -Raghu > > On 4/3/20 3:16 AM, Louis Mayencourt wrote: >> Hi Raghu, >> >> I do agree that we need something similar to a binding document for >> fconf properties. (similar to >> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3694/2/docs/…). >> At least for the common properties. >> >> The main idea behind the return code of the populator function was to >> allow the code to handle no-critical property misses or to handle >> critical failure by calling a platform hook. >> With this in mind, you can imagine a well-formed DTB which contain a >> critical set of properties and can contain some optional properties. >> The return code and the populator "name" / "config" can be used to >> handle this two cases. >> >> I tried to keep the design of fconf really simple, to leave room for >> improvement according to feedbacks. Thanks for helping improving it! >> >> Regards, >> Louis >> ------------------------------------------------------------------------ >> *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of >> Raghu Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> >> *Sent:* 03 April 2020 10:15 >> *To:* tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> >> *Subject:* Re: [TF-A] fconf: Validating config data >> A further point is that the fconf populators return an error code and >> panics on error today. But if we are making the assumption that the >> DTB's are well formed, do we really need to fail or even return an error >> code? >> >> -Raghu >> >> On 4/3/20 1:51 AM, Raghu Krishnamurthy via TF-A wrote: >>> Hi All, (Sorry for the long email) >>> >>> The review >>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3845 >>> attempts to fix bounds check in the fconf populator code for the >>> topology and SP's. During review, Sandrine thoughtfully pointed out >>> that there were discussions around bounds check along the same lines >>> in the review >>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3492 and >>> it was deemed sufficient to have assertions in code and it was safe >>> to make the assumption that the DTB is always well formed and >>> contains valid values. I think this email mostly echoes Sandrine's >>> concern from review 3492. >>> >>> While i agree with the assumptions, I am generally of the opinion >>> that we should validate/range-check any data, even if it is signed. >>> Being signed does not necessarily mean the data is well formed/valid. >>> If there is a mistake in the build process and it is validly signed, >>> it is possible that we silently corrupt state/data that could later >>> be used to exploit firmware and/or make debugging hard. This is >>> probably far fetched, but the cost of adding the check is trivial to >>> avoid this possibility. >>> >>> I imagine the case where you have secure partitions signed by >>> different entity other than the silicon provider(dual root-of-trust). >>> A silicon provider provides a dev system for the SP provider to test >>> and validate the SP's on silicon. The silicon has production >>> firmware(and hence no assertions), but loads signed data from the SP >>> provider which has some invalid values. There could be silent >>> corruption without any indication whatsoever about what went wrong >>> and it may be hard to debug if/when there are issues. >>> Also, testing does not necessarily catch all invalid values since you >>> will likely not get 100% coverage, given the number of config options >>> available. Moreover, the code today, is not consistent in asserting >>> on every property for valid values and the failure mode is not >>> consistent/deterministic. It seems like every config option should >>> have a list of valid values or a range of acceptable values that must >>> be at a minimum asserted on. >>> I also wouldn't discount platforms such as RPI, where >>> TRUSTED_BOARD_BOOT is likely to be turned off since it really does >>> not provide any security, so assuming we always have signed data >>> might not be valid. >>> >>> Anyway, is this decision worth revisiting? Too paranoid perhaps? :P >>> >>> >>> Thanks >>> Raghu >> -- >> TF-A mailing list >> TF-A(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >> 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. >

5 years, 1 month

1
0
0 0

Re: [TF-A] Change in ...trusted-firmware-a[integration]: Check for out-of-bound accesses in the CoT description

by Sandrine Bailleux

Hi Raghu, On 4/3/20 1:38 AM, Raghu Krishnamurthy via TF-A wrote: > Thanks Sandrine. Patches look good. Thanks for the review! > I realized after looking at things a little closer that i had > misunderstood how fconf works for io policies. I thought the image id's > themselves came from the config files and not just the UUID's, which is > why i was worried about bounds check, since the id was coming from an > external source(trusted or untrusted, depending on if it is signed data > or not). > This also made me realize that we are using another table built into > code, to convert from image id to UUID for io policies. Is there a > reason image id's also can't be discovered from the config file? I remember some internal discussions around this topic a few weeks ago. If I recall correctly, the current thinking is that down the line, we would like to move image IDs to DTBs but this looks complicated to achieve today because image IDs are used by several components in TF-A to tie things together. More work would be needed to abstract this properly everywhere. I think other folks in the team (Olivier? Manish? Louis?) might be able to comment further on this. Regards, Sandrine 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.

5 years, 1 month

1
0
0 0

Re: [TF-A] fconf: Validating config data

by Raghu Krishnamurthy

A further point is that the fconf populators return an error code and panics on error today. But if we are making the assumption that the DTB's are well formed, do we really need to fail or even return an error code? -Raghu On 4/3/20 1:51 AM, Raghu Krishnamurthy via TF-A wrote: > Hi All, (Sorry for the long email) > > The review > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3845 > attempts to fix bounds check in the fconf populator code for the > topology and SP's. During review, Sandrine thoughtfully pointed out that > there were discussions around bounds check along the same lines in the > review > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3492 and > it was deemed sufficient to have assertions in code and it was safe to > make the assumption that the DTB is always well formed and contains > valid values. I think this email mostly echoes Sandrine's concern from > review 3492. > > While i agree with the assumptions, I am generally of the opinion that > we should validate/range-check any data, even if it is signed. Being > signed does not necessarily mean the data is well formed/valid. If there > is a mistake in the build process and it is validly signed, it is > possible that we silently corrupt state/data that could later be used to > exploit firmware and/or make debugging hard. This is probably far > fetched, but the cost of adding the check is trivial to avoid this > possibility. > > I imagine the case where you have secure partitions signed by different > entity other than the silicon provider(dual root-of-trust). A silicon > provider provides a dev system for the SP provider to test and validate > the SP's on silicon. The silicon has production firmware(and hence no > assertions), but loads signed data from the SP provider which has some > invalid values. There could be silent corruption without any indication > whatsoever about what went wrong and it may be hard to debug if/when > there are issues. > Also, testing does not necessarily catch all invalid values since you > will likely not get 100% coverage, given the number of config options > available. Moreover, the code today, is not consistent in asserting on > every property for valid values and the failure mode is not > consistent/deterministic. It seems like every config option should have > a list of valid values or a range of acceptable values that must be at a > minimum asserted on. > I also wouldn't discount platforms such as RPI, where TRUSTED_BOARD_BOOT > is likely to be turned off since it really does not provide any > security, so assuming we always have signed data might not be valid. > > Anyway, is this decision worth revisiting? Too paranoid perhaps? :P > > > Thanks > Raghu

5 years, 1 month

1
0
0 0

fconf: Validating config data

by Raghu Krishnamurthy

Hi All, (Sorry for the long email) The review https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3845 attempts to fix bounds check in the fconf populator code for the topology and SP's. During review, Sandrine thoughtfully pointed out that there were discussions around bounds check along the same lines in the review https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3492 and it was deemed sufficient to have assertions in code and it was safe to make the assumption that the DTB is always well formed and contains valid values. I think this email mostly echoes Sandrine's concern from review 3492. While i agree with the assumptions, I am generally of the opinion that we should validate/range-check any data, even if it is signed. Being signed does not necessarily mean the data is well formed/valid. If there is a mistake in the build process and it is validly signed, it is possible that we silently corrupt state/data that could later be used to exploit firmware and/or make debugging hard. This is probably far fetched, but the cost of adding the check is trivial to avoid this possibility. I imagine the case where you have secure partitions signed by different entity other than the silicon provider(dual root-of-trust). A silicon provider provides a dev system for the SP provider to test and validate the SP's on silicon. The silicon has production firmware(and hence no assertions), but loads signed data from the SP provider which has some invalid values. There could be silent corruption without any indication whatsoever about what went wrong and it may be hard to debug if/when there are issues. Also, testing does not necessarily catch all invalid values since you will likely not get 100% coverage, given the number of config options available. Moreover, the code today, is not consistent in asserting on every property for valid values and the failure mode is not consistent/deterministic. It seems like every config option should have a list of valid values or a range of acceptable values that must be at a minimum asserted on. I also wouldn't discount platforms such as RPI, where TRUSTED_BOARD_BOOT is likely to be turned off since it really does not provide any security, so assuming we always have signed data might not be valid. Anyway, is this decision worth revisiting? Too paranoid perhaps? :P Thanks Raghu

5 years, 1 month

1
0
0 0

Re: [TF-A] Change in ...trusted-firmware-a[integration]: Check for out-of-bound accesses in the CoT description

by Raghu Krishnamurthy

Thanks Sandrine. Patches look good. I realized after looking at things a little closer that i had misunderstood how fconf works for io policies. I thought the image id's themselves came from the config files and not just the UUID's, which is why i was worried about bounds check, since the id was coming from an external source(trusted or untrusted, depending on if it is signed data or not). This also made me realize that we are using another table built into code, to convert from image id to UUID for io policies. Is there a reason image id's also can't be discovered from the config file? -Raghu On 4/2/20 7:17 AM, Sandrine Bailleux (Code Review) wrote: > Hi guys, > > This is the patch I mentioned last Thursday at the TF-A tech call. Sorry > it took me so long to post it. > > View Change > <https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3836> > > To view, visit change 3836 > <https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3836>. > To unsubscribe, or for help writing mail filters, visit settings > <https://review.trustedfirmware.org/settings>. > > Gerrit-Project: TF-A/trusted-firmware-a > Gerrit-Branch: integration > Gerrit-Change-Id: Ic5ea20e43cf8ca959bb7f9b60de7c0839b390add > Gerrit-Change-Number: 3836 > Gerrit-PatchSet: 1 > Gerrit-Owner: Sandrine Bailleux <sandrine.bailleux(a)arm.com> > Gerrit-Reviewer: Louis Mayencourt <louis.mayencourt(a)arm.com> > Gerrit-Reviewer: Raghu K <raghu.ncstate(a)icloud.com> > Gerrit-Reviewer: Sandrine Bailleux <sandrine.bailleux(a)arm.com> > Gerrit-Comment-Date: Thu, 02 Apr 2020 14:17:12 +0000 > Gerrit-HasComments: No > Gerrit-Has-Labels: No > Gerrit-MessageType: comment

5 years, 1 month

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 355446: (SIZEOF_MISMATCH) /mbedtls/library/x509_crt.c: 1713 in x509_get_other_name() /mbedtls/library/x509_crt.c: 1691 in x509_get_other_name() /mbedtls/library/x509_crt.c: 1728 in x509_get_other_name() ________________________________________________________________________________________________________ *** CID 355446: (SIZEOF_MISMATCH) /mbedtls/library/x509_crt.c: 1713 in x509_get_other_name() 1707 other_name->value.hardware_module_name.oid.tag = MBEDTLS_ASN1_OID; 1708 other_name->value.hardware_module_name.oid.p = p; 1709 other_name->value.hardware_module_name.oid.len = len; 1710 1711 if( p + len >= end ) 1712 { >>> CID 355446: (SIZEOF_MISMATCH) >>> Passing argument "other_name" of type "mbedtls_x509_san_other_name *" and argument "8UL /* sizeof (other_name) */" to function "mbedtls_platform_zeroize" is suspicious. 1713 mbedtls_platform_zeroize( other_name, sizeof( other_name ) ); 1714 return( MBEDTLS_ERR_X509_INVALID_EXTENSIONS + 1715 MBEDTLS_ERR_ASN1_LENGTH_MISMATCH ); 1716 } 1717 p += len; 1718 if( ( ret = mbedtls_asn1_get_tag( &p, end, &len, /mbedtls/library/x509_crt.c: 1691 in x509_get_other_name() 1685 { 1686 return( MBEDTLS_ERR_X509_FEATURE_UNAVAILABLE ); 1687 } 1688 1689 if( p + len >= end ) 1690 { >>> CID 355446: (SIZEOF_MISMATCH) >>> Passing argument "other_name" of type "mbedtls_x509_san_other_name *" and argument "8UL /* sizeof (other_name) */" to function "mbedtls_platform_zeroize" is suspicious. 1691 mbedtls_platform_zeroize( other_name, sizeof( other_name ) ); 1692 return( MBEDTLS_ERR_X509_INVALID_EXTENSIONS + 1693 MBEDTLS_ERR_ASN1_LENGTH_MISMATCH ); 1694 } 1695 p += len; 1696 if( ( ret = mbedtls_asn1_get_tag( &p, end, &len, /mbedtls/library/x509_crt.c: 1728 in x509_get_other_name() 1722 other_name->value.hardware_module_name.val.tag = MBEDTLS_ASN1_OCTET_STRING; 1723 other_name->value.hardware_module_name.val.p = p; 1724 other_name->value.hardware_module_name.val.len = len; 1725 p += len; 1726 if( p != end ) 1727 { >>> CID 355446: (SIZEOF_MISMATCH) >>> Passing argument "other_name" of type "mbedtls_x509_san_other_name *" and argument "8UL /* sizeof (other_name) */" to function "mbedtls_platform_zeroize" is suspicious. 1728 mbedtls_platform_zeroize( other_name, 1729 sizeof( other_name ) ); 1730 return( MBEDTLS_ERR_X509_INVALID_EXTENSIONS + 1731 MBEDTLS_ERR_ASN1_LENGTH_MISMATCH ); 1732 } 1733 return( 0 ); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

5 years, 1 month

1
0
0 0

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

by Sandrine Bailleux

Hi Joakim, On 4/1/20 10:08 AM, Joakim Bech via TSC wrote: > Hi Christian, Sandrine, all, > > On Thu, Mar 26, 2020 at 10:27:14AM +0100, Sandrine Bailleux wrote: >> Hi Christian, >> >> Thanks a lot for the read and the comments! >> >> On 3/25/20 7:05 PM, Christian Daudt wrote: >>> ï¿½The maintenance proposal looks great ! I have some feedback on >>> specific portions: >>> ï¿½1. maintainer/owner/author patches. " Note that roles can be >>> cumulative, in particular the same individual can be both a code owner >>> and a maintainer. In such a scenario, the individual would be able to >>> self-merge a patch solely affecting his module, having the authority to >>> approve it from both a code owner and maintainer's point of view.": I'm >>> always leery of people self-approving their patches. At a minimum, all >>> self-patches should be published and a minimum wait time provided for >>> feedback. Or preferably that another maintainer does the merge (it does >>> not need to be mandated but should be suggested). >> >> Yes, actually this is something that generated some disagreement inside Arm >> as well and I am glad you're bringing this up here, as I'd like to hear more >> opinions on this. >> >> I too have concerns about allowing self-reviewing. I am not so much >> concerned about people potentially abusing of this situation to silently >> merge patches, as I think we should trust our maintainers. But I am worried >> that a self-review is rarely as good as a peer review, simply because it is >> so easy to miss things when it's your own work. I believe several pair of >> eyes is always better, as different people think differently, have different >> perspectives and backgrounds, and are able to catch different issues. >> >> But to pull this off, we need enough people to do all these reviews. The >> proposal currently allows self-review because some of us feared that >> mandating 2 reviewers for every patch (especially pure platform patches) >> would be impractical and too heavyweight, especially for the TF-M project in >> its current contributors organization, as I understand. It would be great to >> get more feedback from the TF-M community as to whether they think it could >> work in the end. >> >> It's a difficult balance between having the best possible code review >> practices, and realistically getting all the review work done in a timely >> manner, avoiding bottlenecks on specific people and keeping the flow of >> patches smooth. >> >> I like your idea of a minimum wait time provided for feedback. I think it >> could be a good middle ground solution. >> > +1 for that, after silence for X weeks it should be OK to merge the > patch. X would need to be number that is high enough for people to have > a chance to find it and look into it, but shouldn't be too high, since > there is a risk that it'll force the contributor to pile up things that > might be dependent on this patch. To throw something out, I'd say ~2 > weeks sounds like a good number to me. > >> Your other suggestion of having a different maintainer doing the merge would >> work as well IMO but requires more workforce. Again this comes down to >> whether this can realistically be achieved for each project. This solution >> was actually suggested within Arm as well (and even called out at the end of >> the proposal ;) ). >> >> Bottom line is, in an ideal world I would like to condemn self-review >> because I consider this as bad practice > +1 > >> , but I do not know whether this will >> be practical and will work for TF-M as well. >> >>> ï¿½2. 'timely manner': This expectation should be more explicit - when >>> the author can start requesting other maintainers to merge on assumption >>> that silence == approval (or not). Such timeliness expectations are >>> probably best set per project however. >> >> Yes, "timely manner" is definitely too vague and was actually left that way >> on purpose at this stage to avoid touching upon what I think is a sensitive >> subject! I am aware that some patches sometimes spend a long time in review, >> definitely longer than they should and it understandably generates some >> frustration. This is something we absolutely need to improve on IMO and >> hopefully a bigger pool of maintainers will help solve this issue. But I >> agree that the expected review timeline should be clearly established and it >> is probably best to let each project decides theirs. >> >>> ï¿½3. The proposal does not address branching strategies. i.e. will >>> there be separate maintainers for dev/master/stable branches? I don't >>> think it needs to address it yet - keep it simpler for a start. But a >>> todo saying something like "in the future this project maintenance >>> proposal might be expanded to address multi-branch maintainership" would >>> be good. >> >> Good point. A todo sounds good, I will add one in the last section of the >> document. >> >>> ï¿½4. The platform lifecycle state machine has too many transitions. >>> "Fully maintained" <-> "orphan" -> "out" seems sufficient to me. >> >> Hmm OK. There might be too many transitions but I feel we need something >> between fully maintained and out, i.e. the limited support one. >> >> Julius Werner also pointed out on Thursday that orphan might be misplaced, >> as all these other stages deal with some degrees of feature support (what's >> known to work), whereas orphan is an orthogonal topic that is not directly >> related to the level of supported features. For example, a platform could >> have recently become orphan but all features and tests still work for some >> time. >> > At one point in time in the OP-TEE project we tried to keep track of > maintained platforms, by simply saying maintained "Yes" if they are > maintained. However they're not maintained, we indicated that by stating > the last known version where a platform was maintained. People can still > find that information here [1] (not up-to-date). The intention was to > give future users of an old platform a chance to know if it ever has > been supported and what version that was. That could serve as a starting > point in case someone is interested in bring a device/platform back to > life. Yes, I think such information can be very useful. It saves some "git archeology" effort to try and dig this information afterwards. Also, when someone starts looking at a project, I would expect this to be one of the first thing they look up, they would want to know in which shape the project is for the particular platform they are interested in. That's almost as important in my eyes as a "getting started" guide. We could have such a high-level table that just says whether a platform is supported or not (just a yes/no) and have complementary, per-platform documentation that goes into the details of what features are supported exactly. > 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! > 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. > So, I'm not proposing something, it's just that I wanted to share what > we've tried and it "works", but not easy to maintain (a release > checklist could fix that). > > [1] https://optee.readthedocs.io/en/latest/general/platforms.html > [2] https://github.com/OP-TEE/optee_os/pull/3309/commits/765b92604459240bed7fcf… >

5 years, 1 month

2
1
0 0

Re: [TF-A] Event Log for Measured Boot

by Raghu Krishnamurthy

Hi Alexei, I second Varun on this. The patch is huge. I recommend breaking it up into multiple commits. I've reviewed it but since it is a large patch, it might require a few more sittings to grasp all the changes(which also means there may be some stupid review comments :)). -Raghu On 3/31/20 10:28 AM, Varun Wadekar via TF-A wrote: > Hello Alexei, > > Just curious, the patch is huge and will take some time to review. Do > you expect this change to be merged before the v2.3 release? > > -Varun > > *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org> *On Behalf Of > *Alexei Fedorov via TF-A > *Sent:* Tuesday, March 31, 2020 7:19 AM > *To:* tf-a(a)lists.trustedfirmware.org > *Subject:* [TF-A] Event Log for Measured Boot > > *External email: Use caution opening links or attachments* > > Hi, > > Please review and provide your comments for the patch which adds > > Event Log generation for the Measured Boot. > > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3806 > > Thanks. > > Alexei > > 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. > > ------------------------------------------------------------------------ > This email message is for the sole use of the intended recipient(s) and > may contain confidential information. Any unauthorized review, use, > disclosure or distribution is prohibited. If you are not the intended > recipient, please contact the sender by reply email and destroy all > copies of the original message. > ------------------------------------------------------------------------ >

5 years, 1 month

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 2 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 355291: Memory - corruptions (NEGATIVE_RETURNS) /plat/arm/board/arm_fpga/fpga_pm.c: 50 in fpga_pwr_domain_on() ________________________________________________________________________________________________________ *** CID 355291: Memory - corruptions (NEGATIVE_RETURNS) /plat/arm/board/arm_fpga/fpga_pm.c: 50 in fpga_pwr_domain_on() 44 unsigned int pos = plat_core_pos_by_mpidr(mpidr); 45 unsigned long current_mpidr = read_mpidr_el1(); 46 47 if (mpidr == current_mpidr) { 48 return PSCI_E_ALREADY_ON; 49 } >>> CID 355291: Memory - corruptions (NEGATIVE_RETURNS) >>> Using variable "pos" as an index to array "hold_base". 50 hold_base[pos] = PLAT_FPGA_HOLD_STATE_GO; 51 flush_dcache_range((uintptr_t)&hold_base[pos], sizeof(uint64_t)); 52 sev(); /* Wake any CPUs from wfe */ 53 54 return PSCI_E_SUCCESS; 55 } ** CID 355290: Memory - corruptions (OVERRUN) /plat/arm/board/arm_fpga/fpga_pm.c: 50 in fpga_pwr_domain_on() ________________________________________________________________________________________________________ *** CID 355290: Memory - corruptions (OVERRUN) /plat/arm/board/arm_fpga/fpga_pm.c: 50 in fpga_pwr_domain_on() 44 unsigned int pos = plat_core_pos_by_mpidr(mpidr); 45 unsigned long current_mpidr = read_mpidr_el1(); 46 47 if (mpidr == current_mpidr) { 48 return PSCI_E_ALREADY_ON; 49 } >>> CID 355290: Memory - corruptions (OVERRUN) >>> Overrunning array "hold_base" of 64 8-byte elements at element index 4294967295 (byte offset 34359738367) using index "pos" (which evaluates to 4294967295). 50 hold_base[pos] = PLAT_FPGA_HOLD_STATE_GO; 51 flush_dcache_range((uintptr_t)&hold_base[pos], sizeof(uint64_t)); 52 sev(); /* Wake any CPUs from wfe */ 53 54 return PSCI_E_SUCCESS; 55 } ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

5 years, 1 month

1
0
0 0

Patch-set review request: Adding Broadcom Platform support

by Sheetal Tigadoli

Hello TF-A, I understand most devs/reviewers will be busy working towards code freeze, but if its possible can this patch-set be reviewed. The patch-set is about "Add support for Broadcom platform". Patch-set link https://review.trustedfirmware.org/q/topic:%2522brcm_initial_support%2522 Thanks Sheetal

5 years, 1 month

1
0
0 0

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

by Shreve, Erik

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. 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. 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. 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. 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. Note: projects will need to adopt (if they have not already) a version scheme that distinguishes between feature updates and bug fixes. 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). 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. 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" 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) -----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Sandrine Bailleux via TF-M Sent: Tuesday, March 24, 2020 4:42 AM To: tf-a; tf-m(a)lists.trustedfirmware.org; tsc(a)lists.trustedfirmware.org; op-tee(a)linaro.org Cc: nd(a)arm.com Subject: [EXTERNAL] [TF-M] Project Maintenance Proposal for tf.org Projects Hello all, As the developers community at trustedfirmware.org is growing, there is an increasing need to have work processes that are clearly documented, feel smooth and scale well. We think that there is an opportunity to improve the way the trustedfirmware.org projects are managed today. That's why we are sharing a project maintenance proposal, focusing on the TF-A and TF-M projects initially. The aim of this document is to propose a set of rules, guidelines and processes to try and improve the way we work together as a community today. Note that this is an early draft at this stage. This is put up for further discussion within the trustedfirmware.org community. Nothing is set in stone yet and it is expected to go under change as feedback from the community is incorporated. Please find the initial proposal here: https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p… Please provide any feedback you may have by replying to this email thread, keeping all 4 mailing lists in the recipients list. I will collate comments from the community and try to incorporate them in the document, keeping you updated on changes made between revisions. Regards, Sandrine -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 1 month

2
2
0 0

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

by Sandrine Bailleux

Hi Andrej, On 3/26/20 10:54 AM, Andrej Butok via TF-A wrote: >> But I am worried that a self-review is rarely as good as a peer review > > On practice, unfortunately, some TF-M tasks are waiting weeks and even months for review and following approvals. > If I were a maintainer & owner of my own TFM area, I do not want to wait & push & remind somebody else. > Better to have a post-merge review for these cases, which does not limit and slow down the development. Thanks for the feedback. That's not good, patches can't realistically stay in review for weeks and even months, that's just not workable. Worse, it might discourage developers to contribute to the project. I can see that cumulating maintainer & owner roles would solve the problem here but perhaps enlarging the pool of maintainers would as well? Presumably, the situation is like that today because the current maintainers of the project are overloaded and cannot get all reviews done in a timely manner? I am skeptical about a post-merge review process... Once a patch is merged there is less urge and motivation (if any) for people to take a look at it. I am worried that patches might never get reviewed that way. Regards, Sandrine

5 years, 1 month

2
2
0 0

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

by Christian Daudt

Hi Sandrine, > Please find the initial proposal here: > > https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p… > > Please provide any feedback you may have by replying to this email > thread, keeping all 4 mailing lists in the recipients list. > > I will collate comments from the community and try to incorporate them > in the document, keeping you updated on changes made between revisions. The maintenance proposal looks great ! I have some feedback on specific portions: 1. maintainer/owner/author patches. " Note that roles can be cumulative, in particular the same individual can be both a code owner and a maintainer. In such a scenario, the individual would be able to self-merge a patch solely affecting his module, having the authority to approve it from both a code owner and maintainer's point of view.": I'm always leery of people self-approving their patches. At a minimum, all self-patches should be published and a minimum wait time provided for feedback. Or preferably that another maintainer does the merge (it does not need to be mandated but should be suggested). 2. 'timely manner': This expectation should be more explicit - when the author can start requesting other maintainers to merge on assumption that silence == approval (or not). Such timeliness expectations are probably best set per project however. 3. The proposal does not address branching strategies. i.e. will there be separate maintainers for dev/master/stable branches? I don't think it needs to address it yet - keep it simpler for a start. But a todo saying something like "in the future this project maintenance proposal might be expanded to address multi-branch maintainership" would be good. 4. The platform lifecycle state machine has too many transitions. "Fully maintained" <-> "orphan" -> "out" seems sufficient to me. Thanks, Christian. This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

5 years, 1 month

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A