June 2020 - TF-A - lists.trustedfirmware.org

Re: [TF-A] How should we manage patches affecting multiple users?

by Varun Wadekar

Hello @Sandrine Bailleux, Thanks for starting the email chain. My response to the issues you flagged in the email below. 1. This seems to be a bit tricky. As a consumer of an API, one would expect that it works as advertised. If the behavior changes, thus affecting the expectations or assumptions surrounding the API, then they should be announced. With so many platforms in the tree, we should always assume that even a small change will break a platform. 2. For improvements, we should strive to upgrade all consumers of the API/makefile/features. This will ensure that all platforms remain current and we reduce maintenance cost in the long run. I assume, that such improvements will give birth to additional configs/makefile settings/platform variables etc. We would be signing up for a lot of maintenance by allowing some platforms to lag. For straight forward changes (e.g. the change under discussion) I assume that the platforms will respond and we would get the changes merged relatively fast. For controversial features, this will spark a healthy discussion in the community. 3. For a case where the change breaks platforms, it makes sense to just upgrade all of them. >> Now the question we were pondering in Gerrit is, where does the responsibility of migrating all platforms/users lie for all these types of changes? Is the patch author responsible to do all the work? [VW] IMO, the author of such a patch is the best person to upgrade all affected platforms/users. The main reason being that he/she is already an expert for the patch. But, this might not be true in some cases where the author will need help from the community. For such cases, we should ask for help on the mailing list. I also want to highlight the dangers of introducing make variables as a solution. The current situation is already unmanageable with so many build variables and weak handlers. We should try and avoid adding more. Finally, I agree that there's no silver bullet and we have to deal with each situation differently. Communication is key, as you rightly said. As long we involve the community, we should be OK. -Varun -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandrine Bailleux via TF-A Sent: Friday, June 19, 2020 2:57 AM To: tf-a <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] How should we manage patches affecting multiple users? External email: Use caution opening links or attachments Hello everyone, I would like to start a discussion around the way we want to handle changes that affect all platforms/users. This subject came up in this code review [1]. I'll present my views on the subject and would like to know what others think. First of all, what do we mean by "changes that affect all platforms"? It would be any change that is not self-contained within a platform port. IOW, a change in some file outside of the plat/ directory. It could be in a driver, in a library, in the build system, in the platform interfaces called by the generic code... the list goes on. 1. Some are just implementation changes, they leave the interfaces unchanged. These do not break other platforms builds since the call sites don't need to be updated. However, they potentially change the responsibilities of the interface, in which case this might introduce behavioral changes that all users of the interface need to be aware of and adapt their code to. 2. Some other changes might introduce optional improvements. They introduce a new way of doing things, perhaps a cleaner or more efficient one. Users can safely stay with the old way of doing things without fear of breakage but they would benefit from migrating. This is the case of Alexei's patch [1], which introduces an intermediate GICv2 makefile, that Arm platforms now include instead of pulling each individual file by themselves. At this point, it is just an improvement that introduces an indirection level in the build system. This is an improvement in terms of maintainability because if we add a new essential file to this driver in the future, we'll just need to add it in this new GICv2 makefile without having to update all platforms makefiles. However, platform makefiles can continue to pull in individual files if they wish to. 3. Some other changes might break backwards compatibility. This is something we should avoid as much as possible and we should always strive to provide a migration path. But there are cases where there might be no other way than to break things. In this case, all users have to be migrated. Now the question we were pondering in Gerrit is, where does the responsibility of migrating all platforms/users lie for all these types of changes? Is the patch author responsible to do all the work? I think it's hard to come up with a one-size-fits-all answer. It really depends on the nature of changes, their consequences, the amount of work needed to do the migration, the ability for the patch author to test these changes, to name a few. I believe the patch author should migrate all users on a best-effort basis. If it's manageable then they should do the work and propose a patch to all affected users for them to review and test on their platforms. On the other hand, if it's too much work or impractical, then I think the best approach would be for the patch author to announce and discuss the changes on this mailing list. In some scenarios, the changes might be controversial and not all platform owners might agree that the patch brings enough benefit compared to the migration effort, in which case the changes might have to be withdrawn or re-thought. In any case, I believe communication is key here and no one should take any unilateral decision on their own if it affects other users. I realize this is a vast subject and that we probably won't come up with an answer/reach an agreement on all the aspects of the question. But I'd be interested in hearing other contributors' view and if they've got any experience managing these kinds of issues, perhaps in other open source project. Best regards, Sandrine [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4538 -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

3 years, 9 months

2
2
0 0

Re: [TF-A] Question on authenticating FIP images

by Raghu K

3 years, 9 months

1
0
0 0

Re: [TF-A] Question on authenticating FIP images

by arm in-cloud

Hi Sandrine, Waiting for your suggestions on this query. Thanks On Mon, Jun 22, 2020 at 3:40 PM arm in-cloud via TF-A < tf-a(a)lists.trustedfirmware.org> wrote: > <Posting the question to tf-a mailing list from Maniphest and copied all > previous conversation> > > Hi, > > On our boards I have an external security chip which communicates with AP > (application processor) over a encrypted communication channel. I have a > communication driver/PTA running in a Secure Playload (OPTEE) running in > S-EL1. My firmware update workflow (FIP.BIN) is as below. > > In our design, we have QSPI from where AP boots up (regular TF-A workflow) > this QSPI is also accessible from external Security chip (which is > responsible for AP/SOC's firmware update) > On software side, I have a Non-Secure application which receives the > prebuilt binary (FIP.BIN) it chopps the binary in fixed sized buffers and > send to OPTEE-PTA which internally sends the binary to Security chip (which > then validates and writes to QSPI). > > Now in this firmware update flow, I want to do following things. > > 1. I want to validate/authenticate the FIP image before sending to > security chip. If it authentication is successful only then send the image > to security chip. > > This is what I am planning:- > > 1. Receive the whole FIP.BIN from NS-APP and store it in RAM (in > OPTEE's RAM) > 2. I am planning to implement a SIP service in TF-A which will receive > the address and size of FIP.BIN in RAM. > 3. Calls in to auth_mod driver for authentication of the image. > > I don't want to update the images immediately I just needs to authenticate > the images within FIP.BIN > > To design this feature, I started looking in to BL1 & BL2 code but not > sure how much piece if code I can reuse or use. > Also I looked in to fwu test apps if I can mimic something but looks the > fwu implementation is absolutely different. > > My question is how do I just use the authentication functionality > available in TF-A for my purpose. > > Appreciate your help! > > > > > sandrine-bailleux-arm > <https://developer.trustedfirmware.org/p/sandrine-bailleux-arm/> added a > subscriber: sandrine-bailleux-arm > <https://developer.trustedfirmware.org/p/sandrine-bailleux-arm/>.Tue, Jun > 16, 6:50 AM <https://developer.trustedfirmware.org/T763#9015> > > <https://developer.trustedfirmware.org/T763#> > > Hi, > > Apologies for the delay, I had missed this ticket... Generally speaking, > it's better to post questions on the TF-A mailing list [1], it's got far > better visibility than Maniphest (which few people monitor I believe) and > you are more likely to get a quick answer there. > > First of all, I've got a few questions that would help me understand your > design. > > 1. You say that OPTEE-PTA would store the FIP image in its RAM. I am > assuming this is secure RAM, that only secure software can access, right? > If not, this would not seem very secure to me, as the normal world software > could easily change the FIP image after it has been authenticated and > replace it with some malicious firmware. > > > 1. You'd like to implement a SiP service in TF-A to authenticate the > FIP image, given its base address and size. Now I am guessing this would be > an address in OPTEE's RAM, right? > > > 1. What cryptographic key would sign the FIP image? Would TF-A have > access to this key to authenticate it? > > > 1. What would need authentication? The FIP image as a monolithic blob, > or each individual image within this FIP? And in the latter case, would all > images be authenticated using the same key or would different images be > signed with different keys? > > Now, coming back to where to look into TF-A source code. You're looking in > the right place, all Trusted Boot code is indeed built into BL1 and BL2 in > TF-A. The following two documents detail how the authentication framework > and firmware update flow work in TF-A and are worth reading if you haven't > done so already: > > > https://trustedfirmware-a.readthedocs.io/en/latest/design/auth-framework.ht… > > https://trustedfirmware-a.readthedocs.io/en/latest/components/firmware-upda… > > I reckon you'd want to reuse the cryptographic module in your case. It > provides a callback to verify the signature of some payload, see [2] and > include/drivers/auth/crypto_mod.h. However, I expect it won't be straight > forward to reuse this code outside of its context, as it expects > DER-encoded data structures following a specific ASN.1 format. Typically > when used in the TF-A trusted boot flow, these are coming from X.509 > certificates, which already provide the data structures in the right format. > > Best regards, > Sandrine Bailleux > > [1] https://lists.trustedfirmware.org/mailman/listinfo/tf-a > [2] > https://trustedfirmware-a.readthedocs.io/en/latest/design/auth-framework.ht… > > > arm-in-cloud <https://developer.trustedfirmware.org/p/arm-in-cloud/> added > a comment.Edited · Wed, Jun 17, 11:42 AM > <https://developer.trustedfirmware.org/T763#9018> > > <https://developer.trustedfirmware.org/T763#> > > Thank you Sandrine for your feedback. > > Following are the answers to your questions: > > 1. Yes, the image will be stored in to OPTEEs secured memory. I am > guessing TF-A gets access to this memory. > 2. Yes, the OPTEE's secure memory address and Size will be passed to > the SiP service running in TF-A. > 3. These are RSA keys, in my case only TF-A has access to these keys. > On a regular boot these are the same keys used to authenticate the images > (BL31, BL32 & BL33) in the FIP stored in the QSPI. > 4. Yes all images will be authenticated using same key. > > Thanks for the documentation links, from the firmware-update doc. I am > mainly trying to use IMAGE_AUTH part. In my case COPY is already done just > needs AUTH part and once AUTH is successful, optee will pass that payload > the security chip for update. And after rebooting my device will boot with > new firmware. (In my case we always reboot after firmware updates). > > Do you want me to post this query again on the TF-A mailing list? > > Thank you! > > > > sandrine-bailleux-arm > <https://developer.trustedfirmware.org/p/sandrine-bailleux-arm/> added a > comment.Fri, Jun 19, 3:09 AM > <https://developer.trustedfirmware.org/T763#9032> > > <https://developer.trustedfirmware.org/T763#> > > Hi, > > OK I understand a bit better, thanks for the details. > > Do you want me to post this query again on the TF-A mailing list? > > If it's not too much hassle for you then yes, I think it'd be preferable > to continue the discussion on the TF-A mailing list. I will withhold my > comments until then. > > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a >

3 years, 9 months

1
0
0 0

Re: [TF-A] Unhandled Exception at EL3 in BL31 for Neoverse N1 with direct connect of DSU

by Witkowski, Andrzej

Sorry for a delay. I didn't have a bandwidth for doing it. I asked my teammate Marcin Salnik for testing the fix https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3493 on our Veloce emulator. Now, I can confirm that this fix works. ACC BL31 booted. From: Varun Wadekar <vwadekar(a)nvidia.com> Sent: Monday, June 01, 2020 8:57 PM To: Witkowski, Andrzej <andrzej.witkowski(a)intel.com> Cc: Lessnau, Adam <adam.lessnau(a)intel.com>; tf-a(a)lists.trustedfirmware.org Subject: RE: Unhandled Exception at EL3 in BL31 for Neoverse N1 with direct connect of DSU Hi, I believe the fix for this issue is part of https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3493. Can you please try that change? -Varun From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> On Behalf Of Witkowski, Andrzej via TF-A Sent: Monday, June 1, 2020 7:08 AM To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> Cc: Witkowski, Andrzej <andrzej.witkowski(a)intel.com<mailto:andrzej.witkowski@intel.com>>; Lessnau, Adam <adam.lessnau(a)intel.com<mailto:adam.lessnau@intel.com>> Subject: [TF-A] Unhandled Exception at EL3 in BL31 for Neoverse N1 with direct connect of DSU External email: Use caution opening links or attachments Hi, I work on project which uses ARM CPU Neoverse N1 with direct connect of DSU. I noticed the following error "Unhandled Exception at EL3" in BL31 bootloader after switching from ATF 2.1 to 2.2. The root cause is that after invoking neoverse_n1_errata-report function in lib/cpus/aarch64/neoverse_n1.S file and reaching the line 525, the function check_errata_dsu_934 in lib/cpus/aarch64/dsu_helpers.S file is always invoked regardless of whether ERRATA_DSU_936184 is set to 0 or to 1. In our case, ERRATA_DSU_936184 := 0. [cid:image001.png@01D64A40.BBEF1AA0] [cid:image002.png@01D64A40.BBEF1AA0] Neoverse N1 with direct connect version of DSU doesn't contain SCU/L3 cache and CLUSTERCFR_EL1 register. The error "Unhandled Exception at EL3" appears in BL31 bootloader during attempt to read the CLUSTERCFR_EL1 register which doesn't exist in our RTL HW. Andrzej Witkowskie Intel Technology Poland --------------------------------------------------------------------- Intel Technology Poland sp. z o.o. ul. Słowackiego 173 | 80-298 Gdańsk | Sąd Rejonowy Gdańsk Północ | VII Wydział Gospodarczy Krajowego Rejestru Sądowego - KRS 101882 | NIP 957-07-52-316 | Kapitał zakładowy 200.000 PLN. Ta wiadomość wraz z załącznikami jest przeznaczona dla określonego adresata i może zawierać informacje poufne. W razie przypadkowego otrzymania tej wiadomości, prosimy o powiadomienie nadawcy oraz trwałe jej usunięcie; jakiekolwiek przeglądanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited. --------------------------------------------------------------------- Intel Technology Poland sp. z o.o. ul. Sowackiego 173 | 80-298 Gdask | Sd Rejonowy Gdask Pnoc | VII Wydzia Gospodarczy Krajowego Rejestru Sdowego - KRS 101882 | NIP 957-07-52-316 | Kapita zakadowy 200.000 PLN. Ta wiadomo wraz z zacznikami jest przeznaczona dla okrelonego adresata i moe zawiera informacje poufne. W razie przypadkowego otrzymania tej wiadomoci, prosimy o powiadomienie nadawcy oraz trwae jej usunicie; jakiekolwiek przegldanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited.

3 years, 9 months

1
0
0 0

Question on authenticating FIP images

by arm in-cloud

<Posting the question to tf-a mailing list from Maniphest and copied all previous conversation> Hi, On our boards I have an external security chip which communicates with AP (application processor) over a encrypted communication channel. I have a communication driver/PTA running in a Secure Playload (OPTEE) running in S-EL1. My firmware update workflow (FIP.BIN) is as below. In our design, we have QSPI from where AP boots up (regular TF-A workflow) this QSPI is also accessible from external Security chip (which is responsible for AP/SOC's firmware update) On software side, I have a Non-Secure application which receives the prebuilt binary (FIP.BIN) it chopps the binary in fixed sized buffers and send to OPTEE-PTA which internally sends the binary to Security chip (which then validates and writes to QSPI). Now in this firmware update flow, I want to do following things. 1. I want to validate/authenticate the FIP image before sending to security chip. If it authentication is successful only then send the image to security chip. This is what I am planning:- 1. Receive the whole FIP.BIN from NS-APP and store it in RAM (in OPTEE's RAM) 2. I am planning to implement a SIP service in TF-A which will receive the address and size of FIP.BIN in RAM. 3. Calls in to auth_mod driver for authentication of the image. I don't want to update the images immediately I just needs to authenticate the images within FIP.BIN To design this feature, I started looking in to BL1 & BL2 code but not sure how much piece if code I can reuse or use. Also I looked in to fwu test apps if I can mimic something but looks the fwu implementation is absolutely different. My question is how do I just use the authentication functionality available in TF-A for my purpose. Appreciate your help! sandrine-bailleux-arm <https://developer.trustedfirmware.org/p/sandrine-bailleux-arm/> added a subscriber: sandrine-bailleux-arm <https://developer.trustedfirmware.org/p/sandrine-bailleux-arm/>.Tue, Jun 16, 6:50 AM <https://developer.trustedfirmware.org/T763#9015> <https://developer.trustedfirmware.org/T763#> Hi, Apologies for the delay, I had missed this ticket... Generally speaking, it's better to post questions on the TF-A mailing list [1], it's got far better visibility than Maniphest (which few people monitor I believe) and you are more likely to get a quick answer there. First of all, I've got a few questions that would help me understand your design. 1. You say that OPTEE-PTA would store the FIP image in its RAM. I am assuming this is secure RAM, that only secure software can access, right? If not, this would not seem very secure to me, as the normal world software could easily change the FIP image after it has been authenticated and replace it with some malicious firmware. 1. You'd like to implement a SiP service in TF-A to authenticate the FIP image, given its base address and size. Now I am guessing this would be an address in OPTEE's RAM, right? 1. What cryptographic key would sign the FIP image? Would TF-A have access to this key to authenticate it? 1. What would need authentication? The FIP image as a monolithic blob, or each individual image within this FIP? And in the latter case, would all images be authenticated using the same key or would different images be signed with different keys? Now, coming back to where to look into TF-A source code. You're looking in the right place, all Trusted Boot code is indeed built into BL1 and BL2 in TF-A. The following two documents detail how the authentication framework and firmware update flow work in TF-A and are worth reading if you haven't done so already: https://trustedfirmware-a.readthedocs.io/en/latest/design/auth-framework.ht… https://trustedfirmware-a.readthedocs.io/en/latest/components/firmware-upda… I reckon you'd want to reuse the cryptographic module in your case. It provides a callback to verify the signature of some payload, see [2] and include/drivers/auth/crypto_mod.h. However, I expect it won't be straight forward to reuse this code outside of its context, as it expects DER-encoded data structures following a specific ASN.1 format. Typically when used in the TF-A trusted boot flow, these are coming from X.509 certificates, which already provide the data structures in the right format. Best regards, Sandrine Bailleux [1] https://lists.trustedfirmware.org/mailman/listinfo/tf-a [2] https://trustedfirmware-a.readthedocs.io/en/latest/design/auth-framework.ht… arm-in-cloud <https://developer.trustedfirmware.org/p/arm-in-cloud/> added a comment.Edited · Wed, Jun 17, 11:42 AM <https://developer.trustedfirmware.org/T763#9018> <https://developer.trustedfirmware.org/T763#> Thank you Sandrine for your feedback. Following are the answers to your questions: 1. Yes, the image will be stored in to OPTEEs secured memory. I am guessing TF-A gets access to this memory. 2. Yes, the OPTEE's secure memory address and Size will be passed to the SiP service running in TF-A. 3. These are RSA keys, in my case only TF-A has access to these keys. On a regular boot these are the same keys used to authenticate the images (BL31, BL32 & BL33) in the FIP stored in the QSPI. 4. Yes all images will be authenticated using same key. Thanks for the documentation links, from the firmware-update doc. I am mainly trying to use IMAGE_AUTH part. In my case COPY is already done just needs AUTH part and once AUTH is successful, optee will pass that payload the security chip for update. And after rebooting my device will boot with new firmware. (In my case we always reboot after firmware updates). Do you want me to post this query again on the TF-A mailing list? Thank you! sandrine-bailleux-arm <https://developer.trustedfirmware.org/p/sandrine-bailleux-arm/> added a comment.Fri, Jun 19, 3:09 AM <https://developer.trustedfirmware.org/T763#9032> <https://developer.trustedfirmware.org/T763#> Hi, OK I understand a bit better, thanks for the details. Do you want me to post this query again on the TF-A mailing list? If it's not too much hassle for you then yes, I think it'd be preferable to continue the discussion on the TF-A mailing list. I will withhold my comments until then.

3 years, 10 months

1
0
0 0

Re: [TF-A] GICV3: system interface EOI ordering RFC

by Sandeep Tripathy

Hi Raghu, > -----Original Message----- > From: TF-A [mailto:tf-a-bounces@lists.trustedfirmware.org] On Behalf Of > Raghu Krishnamurthy via TF-A > Sent: Monday, June 08, 2020 7:09 PM > To: tf-a(a)lists.trustedfirmware.org > Subject: Re: [TF-A] GICV3: system interface EOI ordering RFC > > Hello, > > Sorry for chiming in late. Are we sure that the msr/mrs to the GICv3 EOI > register is not a context synchronizing event or ensures ordering itself > ? Also did the addition of DSB() fix the issue ? If yes, can you try > adding a delay or a few NOP's/dummy instructions or an ISB to see if the > issue goes away? Yes these experiments were done to observe the behavior which led to this change. A definitive confirmation of how core treats these accesses can be only be from arm core team or by actually probing the transfers. I had a response from arm support on the very same question which reads as follows: "In theory, the memory barrier should be placed between the clearing of the peripheral and the access to the EOI register". In a slightly unrelated case I had observed this with NVIC on axi probe and there is no feasibility to repeat this with GICv3 at the moment. > > We need to know the right thing to do architecturally and confirm that > the issue is really due to reordering at the core before adding the DSB. > Adding a DSB might be masking a timing issue. Is the above response and what Soby had confirmed sufficient ? or could someone from arm get this reconfirmed from core design unless it is obvious to them ? And this is equally applicable to linux as well. > > -Raghu > Thanks Sandeep > > > On 6/8/20 4:47 AM, Sandeep Tripathy via TF-A wrote: > >> -----Original Message----- > >> From: Soby Mathew [mailto:Soby.Mathew@arm.com] > >> Sent: Monday, June 08, 2020 3:36 PM > >> To: Sandeep Tripathy; Olivier Deprez; tf-a(a)lists.trustedfirmware.org > >> Cc: nd > >> Subject: RE: [TF-A] GICV3: system interface EOI ordering RFC > >> > >> Just some inputs from my side: > >> I agree we need at least a dsb() after the write to MMIO region to > >> silence > >> the > >> peripheral and before the EOI at GIC sysreg interface. Adding it to the > >> GIC EOI > > > > Thanks for the confirmation. Now it’s about choosing the right place. > > > >> API seems the logical thing to do but as Olivier mentions, there are > >> interrupt > >> handler which do not deal with MMIO (eg: the Systimer interrupt) so > >> adding > >> it > >> to GICv3 API might be arduous for such handlers. > >> > >> So there is a choice here to let the interrupt handlers to deal with > >> ensuring > >> completeness before EOI at sysreg interface or adding it to GICv3 EOI > >> API > >> and > >> take the overhead for interrupt handlers which do not have to deal with > >> MMIO. > >> > > > > Yes I feel either of these is a must to guarantee functionality > > architecturally though > > both approach end up with some unnecessary overhead. > > > > If GICv3 api takes care then it is an overhead for some ISRs dealing > > with > > non-MMIO. > > At present I do not see an active use case in reference implementation > > where > > sys timer > > ISR is in a performance intensive path where one additional DSB will be > > perceivable. > > But there may be some I could be totally wrong in this assumption > (pmu/debug > > or.. not sure). > > Whereas I can certainly imagine some MMIO ISRs in performance critical > > path > > where unnecessary > > DSB is not acceptable at all. > > > > If the interrupt handler needs to ensure then it will generically add > > 'DSB' > > as I think > > the driver cannot and should not make assumptions about how EOI is done > > afterwards. > > That will be overhead for the ISRs dealing with MMIO peripherals and non > > GIC-v3. > > If we consider only GICv3+ then good. Otherwise I would prefer the > > 'plat_ic_end_of_interrupt' > > like Olivier mentioned with a #if GICv3 instead of each ISRs dealing > > with > > it. > > > >> The GICv3 legacy MMIO CPU interface is deprecated for TF-A and the sys > >> interface is the only one GICv3 driver in TF-A supports. > > > > Right we can ignore the GICv3 legacy mode but GICv2 will still remain ? > > > >> > >> Best Regards > >> Soby Mathew > >> > > > > Thanks > > Sandeep > > > >>> -----Original Message----- > >>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of > Sandeep > >>> Tripathy via TF-A > >>> Sent: 08 June 2020 10:34 > >>> To: Olivier Deprez <Olivier.Deprez(a)arm.com>; tf- > >> a(a)lists.trustedfirmware.org > >>> Subject: Re: [TF-A] GICV3: system interface EOI ordering RFC > >>> > >>> Hi Olivier, > >>>> -----Original Message----- > >>>> From: Olivier Deprez [mailto:Olivier.Deprez@arm.com] > >>>> Sent: Monday, June 08, 2020 1:14 PM > >>>> To: tf-a(a)lists.trustedfirmware.org; Sandeep Tripathy > >>>> Subject: Re: [TF-A] GICV3: system interface EOI ordering RFC > >>>> > >>>> Hi Sandeep, > >>>> > >>>> gicv3_end_of_interrupt_sel1 is a static access helper macro. Its > >>>> naming precisely tells what it does at gicv3 module level. It is > >>>> called from > >>> the weak > >>>> plat_ic_end_of_interrupt function for BL32 image. > >>>> > >>>> I tend to think it is the driver responsibility to ensure the module > >>> interrupt > >>>> acknowledge register write is reaching HW in order (or "be visible to > >>> all > >>>> observers"). > >>> > >>> The driver should be agnostic of what interrupt controller is used and > >>> its > >>> behavior. > >>> And since 'all' writes were to mmio ranges mapped Device(nGnRE) > >>> /strongly-ordered(nGnRnE) > >>> there was no such need. This is a special case for GICv3 system > >>> interface only. > >>> Adding at driver level a DSB is unnecessary for other interrupt > >>> controllers. > >>> > >>>> Also I suspect adding a dsb might not be required generically for all > >>> kind of IP. > >>> > >>> Here are you referring to the peripheral IP or interrupt controller IP > >>> ? > >>> The issue is reordering at arm core itself (STR to device address Vs > >>> msr(sysreg > >>> write)). > >>> So I think Its applicable for all IP. > >>> > >>>> Adding a barrier in generic code might incur an unnecessary > >>>> bottleneck. > >>> > >>> But if there is a need to *ensure* presence of at least one DSB > >>> between > >>> the > >>> write transfer from core to device clear and gicv3 eoi icc register > >>> write in a > >>> generic way then what other option we have. > >>>> > >>>> Thus wouldn't it be better to add the barrier to the overridden > >>>> platform function rather than in generic gicv3 code? > >>> > >>> That can be done but I feel this is more to do with gicv3 system > >>> interface only. > >>> Inside plat_xxx one has to check #if GICV3 ...and system interface. > >>>> > >>>> I have a put a comment in the review, we can continue the discussion > >>> there. > >>>> > >>>> Regards, > >>>> Olivier. > >>>> > >>> Thanks > >>> Sandeep > >>>> ________________________________________ > >>>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of > >>>> Sandeep Tripathy via TF-A <tf-a(a)lists.trustedfirmware.org> > >>>> Sent: 05 June 2020 19:43 > >>>> To: tf-a(a)lists.trustedfirmware.org > >>>> Subject: [TF-A] GICV3: system interface EOI ordering RFC > >>>> > >>>> Hi, > >>>> In a typical interrupt handling sequence we do 1-Read IAR > >>>> 2-Do interrupt handling > >>>> 3-Clear the interrupt at source , so that the device de-asserts > >>>> IRQ > >>> request to > >>>> GIC > >>>> >> I am suggesting a need of DSB here in case of GICv3 +. > >>>> 4-Write to GIC cpu interface to do EOI. > >>>> > >>>> Till GICv2 and with GICv3 legacy interface ICC_EOI write is a write > >>>> over > >>> AMBA > >>>> interface. The > >>>> Addresses are mapped with (nR) attribute. Hence the write transfers > >>> from the > >>>> core will be > >>>> generated at step 3 and 4 in order. Please ignore the additional > >>> buffers/bridges > >>>> in path from > >>>> core till peripheral which has to be dealt separately as per SOC. > >>>> > >>>> Query: I understand GICv3 system interface accesses are not over > >>>> this > >>> protocol > >>>> and core will not > >>>> follow the ordering rule ? > >>>> > >>>> I have observed spurious interrupt issue/manifestation ( I don't have > >>> the > >>>> transfers probed) in > >>>> RTOS environment where I have a primitive GICv3 driver but I wonder > >>>> why things does not fail in Linux or tf-a. If it is working because > >>>> from step(3) to > >>> step(4) we have > >>>> barriers by chace > >>>> due to other device register writes then I would suggest to have one > >>>> in > >>> the EOI > >>>> clearing API itself. > >>>> > >>>> RFC: > >>> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4454 > >>>> > >>>> Thanks > >>>> Sandeep > >>> -- > >>> TF-A mailing list > >>> TF-A(a)lists.trustedfirmware.org > >>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

3 years, 10 months

3
9
0 0

Re: [TF-A] Upgrading libfdt library

by Joanna Farley

I think it is clear Madhu has been applying due diligence here both in his own testing and notification to the project through the ML so that consumers can respond and also perform any testing they feel is necessary. In think its appropriate for us to pause while we wait for such feedback but it would be good to have some indication on who feels there might be an issue here and wants to provide feedback. I appreciate you are Varun and we need to analyse the risks and what mitigations need to be in place. As you may have picked up on from the various tech forums we take testing seriously and are looking to augment with different test strategies and tools however these will take time to deploy and spread their coverage through the project codebase. Until then we will have to analyse the level of risk and apply the appropriate level of mitigations which I think Madhu has but lets see if we have some specific issues needing further mitigations to give more confidence. Thanks Joanna On 19/06/2020, 23:35, "TF-A on behalf of Varun Wadekar via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi, Thanks for the information. Adding libfdt to the unit testing framework is a good idea. The verification should give us more confidence on the stability side. Let’s see if platform owners would like to include more tests. -Varun -----Original Message----- From: Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com> Sent: Friday, June 19, 2020 1:01 PM To: Varun Wadekar <vwadekar(a)nvidia.com> Cc: tf-a(a)lists.trustedfirmware.org Subject: RE: [TF-A] Upgrading libfdt library External email: Use caution opening links or attachments Hi Varun I tested the patch by running all applicable tf-a-tests suites [1] and Linux boot tests on FVP and Juno platforms. Since libfdt is platform agnostic, we are planning on adding it to the unit test framework as well(which was described in yesterday's tech forum). I need to admit that I am (over!) confident about libfdt since it is also used in U-boot and Linux projects. It seems the release tags don’t have much significance in the dtc project. Hence, I picked the latest commit at the time. In our internal CI, we also run Coverity MISRA and other static checks to find issues in TF-A and fix them as needed. However, we don’t fix issues reported in 3rd party libraries such as libfdt. I am waiting to hear feedback from various platform owners if they have any issues with this upgrade. [1] https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/tftf/tests Thanks, Madhukar -----Original Message----- From: Varun Wadekar <vwadekar(a)nvidia.com> Sent: Thursday, June 18, 2020 1:30 PM To: Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com> Cc: tf-a(a)lists.trustedfirmware.org Subject: RE: [TF-A] Upgrading libfdt library Hi, I think there are some valid concerns raised in the thread. Since this is an external project I felt we needed to set a criteria for the upgrade. One day, when we start using the unit testing framework and have 100% coverage numbers and solid positive/negative testing, we would be more confident. Until then we just have to live with what have. @Madhukar is there any we can find out all the tests, static analysis checks, security checks that was run on the upgrade? Just trying to understand how confident we are that this does not introduce any regressions? -Varun -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Raghu K via TF-A Sent: Thursday, June 18, 2020 9:07 AM To: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Upgrading libfdt library External email: Use caution opening links or attachments One thing that might be worth considering is versioning the library like xlat_tables and xlat_tables_v2 for a few releases and deprecate the old one if/when there is broad agreement from platforms to move to the new one. Platforms can perform their independent testing like STM and can report back over time. Obviously, for those few releases if there are API changes in libfdt there will have to be support for both new and old api's which will cause temporary ugliness but this might ease concerns about testing, stability etc. -Raghu On 6/18/20 4:12 AM, Soby Mathew via TF-A wrote: >> -----Original Message----- >> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of >> Sandrine Bailleux via TF-A >> Sent: 16 June 2020 13:09 >> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com>; Madhukar Pappireddy >> <Madhukar.Pappireddy(a)arm.com>; Varun Wadekar <vwadekar(a)nvidia.com> >> Cc: tf-a(a)lists.trustedfirmware.org >> Subject: Re: [TF-A] Upgrading libfdt library >> >> Hi Alexei, >> >> On 6/16/20 1:51 PM, Alexei Fedorov wrote: >>> Thanks for your very detailed explanation of the reason behind this >>> solution. >>> This brings the question on how do we monitor libfdt bug fixes, code >>> cleanup, etc. (which Madhukar pointed out) and integrate these >>> changes in TF-A source tree. >> Right now, it is a manual process and not only for libfdt but for all >> projects TF-A depends on. We keep an eye on them and aim at updating >> them when necessary. Unfortunately, like any manual process, it is >> error-prone and things might slip through the cracks. The TF-A >> release tick is usually a good reminder to update all dependencies >> but unfortunately libfdt has been left behind for some time (about 2 years)... > As I recall, when we tried to update libfdt last time, there was significant code bloat in generated binary (feature creep?) and we abandoned the update. The policy was to stick to a stable version and only update if there are any bugfixes or new feature we would want to make use of. > > Generally speaking, we might have done several fixes in the imported 3rd party library by running static checks like for MISRA compliance etc and this has to be repeated when the library is updated. Also, for security audits, it is important to be sure of the "security status" of the imported library and hence we tended to not update for every release. > > But I agree that we do have to be on top of bug fixes and hence we need to update but not sure how we can balance this with concerns above. > > Regarding MbedTLS, being a security critical project, we would like to encourage platform integrators to take ownership of staying upto date rather than relying on update from TF-A repo. Hence the motivation to keep it separate. > > Best Regards > Soby Mathew > > > > >> Regards, >> Sandrine >> -- >> TF-A mailing list >> TF-A(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

3 years, 10 months

1
0
0 0

Re: [TF-A] Upgrading libfdt library

by Varun Wadekar

Hi, I think there are some valid concerns raised in the thread. Since this is an external project I felt we needed to set a criteria for the upgrade. One day, when we start using the unit testing framework and have 100% coverage numbers and solid positive/negative testing, we would be more confident. Until then we just have to live with what have. @Madhukar is there any we can find out all the tests, static analysis checks, security checks that was run on the upgrade? Just trying to understand how confident we are that this does not introduce any regressions? -Varun -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Raghu K via TF-A Sent: Thursday, June 18, 2020 9:07 AM To: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Upgrading libfdt library External email: Use caution opening links or attachments One thing that might be worth considering is versioning the library like xlat_tables and xlat_tables_v2 for a few releases and deprecate the old one if/when there is broad agreement from platforms to move to the new one. Platforms can perform their independent testing like STM and can report back over time. Obviously, for those few releases if there are API changes in libfdt there will have to be support for both new and old api's which will cause temporary ugliness but this might ease concerns about testing, stability etc. -Raghu On 6/18/20 4:12 AM, Soby Mathew via TF-A wrote: >> -----Original Message----- >> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of >> Sandrine Bailleux via TF-A >> Sent: 16 June 2020 13:09 >> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com>; Madhukar Pappireddy >> <Madhukar.Pappireddy(a)arm.com>; Varun Wadekar <vwadekar(a)nvidia.com> >> Cc: tf-a(a)lists.trustedfirmware.org >> Subject: Re: [TF-A] Upgrading libfdt library >> >> Hi Alexei, >> >> On 6/16/20 1:51 PM, Alexei Fedorov wrote: >>> Thanks for your very detailed explanation of the reason behind this >>> solution. >>> This brings the question on how do we monitor libfdt bug fixes, code >>> cleanup, etc. (which Madhukar pointed out) and integrate these >>> changes in TF-A source tree. >> Right now, it is a manual process and not only for libfdt but for all >> projects TF-A depends on. We keep an eye on them and aim at updating >> them when necessary. Unfortunately, like any manual process, it is >> error-prone and things might slip through the cracks. The TF-A >> release tick is usually a good reminder to update all dependencies >> but unfortunately libfdt has been left behind for some time (about 2 years)... > As I recall, when we tried to update libfdt last time, there was significant code bloat in generated binary (feature creep?) and we abandoned the update. The policy was to stick to a stable version and only update if there are any bugfixes or new feature we would want to make use of. > > Generally speaking, we might have done several fixes in the imported 3rd party library by running static checks like for MISRA compliance etc and this has to be repeated when the library is updated. Also, for security audits, it is important to be sure of the "security status" of the imported library and hence we tended to not update for every release. > > But I agree that we do have to be on top of bug fixes and hence we need to update but not sure how we can balance this with concerns above. > > Regarding MbedTLS, being a security critical project, we would like to encourage platform integrators to take ownership of staying upto date rather than relying on update from TF-A repo. Hence the motivation to keep it separate. > > Best Regards > Soby Mathew > > > > >> Regards, >> Sandrine >> -- >> TF-A mailing list >> TF-A(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

3 years, 10 months

2
2
0 0

How should we manage patches affecting multiple users?

by Sandrine Bailleux

Hello everyone, I would like to start a discussion around the way we want to handle changes that affect all platforms/users. This subject came up in this code review [1]. I'll present my views on the subject and would like to know what others think. First of all, what do we mean by "changes that affect all platforms"? It would be any change that is not self-contained within a platform port. IOW, a change in some file outside of the plat/ directory. It could be in a driver, in a library, in the build system, in the platform interfaces called by the generic code... the list goes on. 1. Some are just implementation changes, they leave the interfaces unchanged. These do not break other platforms builds since the call sites don't need to be updated. However, they potentially change the responsibilities of the interface, in which case this might introduce behavioral changes that all users of the interface need to be aware of and adapt their code to. 2. Some other changes might introduce optional improvements. They introduce a new way of doing things, perhaps a cleaner or more efficient one. Users can safely stay with the old way of doing things without fear of breakage but they would benefit from migrating. This is the case of Alexei's patch [1], which introduces an intermediate GICv2 makefile, that Arm platforms now include instead of pulling each individual file by themselves. At this point, it is just an improvement that introduces an indirection level in the build system. This is an improvement in terms of maintainability because if we add a new essential file to this driver in the future, we'll just need to add it in this new GICv2 makefile without having to update all platforms makefiles. However, platform makefiles can continue to pull in individual files if they wish to. 3. Some other changes might break backwards compatibility. This is something we should avoid as much as possible and we should always strive to provide a migration path. But there are cases where there might be no other way than to break things. In this case, all users have to be migrated. Now the question we were pondering in Gerrit is, where does the responsibility of migrating all platforms/users lie for all these types of changes? Is the patch author responsible to do all the work? I think it's hard to come up with a one-size-fits-all answer. It really depends on the nature of changes, their consequences, the amount of work needed to do the migration, the ability for the patch author to test these changes, to name a few. I believe the patch author should migrate all users on a best-effort basis. If it's manageable then they should do the work and propose a patch to all affected users for them to review and test on their platforms. On the other hand, if it's too much work or impractical, then I think the best approach would be for the patch author to announce and discuss the changes on this mailing list. In some scenarios, the changes might be controversial and not all platform owners might agree that the patch brings enough benefit compared to the migration effort, in which case the changes might have to be withdrawn or re-thought. In any case, I believe communication is key here and no one should take any unilateral decision on their own if it affects other users. I realize this is a vast subject and that we probably won't come up with an answer/reach an agreement on all the aspects of the question. But I'd be interested in hearing other contributors' view and if they've got any experience managing these kinds of issues, perhaps in other open source project. Best regards, Sandrine [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4538

3 years, 10 months

1
0
0 0

Re: [TF-A] ATF LTS version

by Varun Wadekar

Hello Joanna, I had discussed the idea with Matteo in the past, but the discussion in the last tech forum prompted the email. >> I appreciate this CI is currently a little opaque to many contributors as this is still in the process of being transitioned to the OpenCI hosted by Trustedfirmware.org servers which will be visible to all I agree, it is hard to test all the use cases. The opaque nature of the CI is a bit annoying, but not a big issue. >> the additional testing done for a 6 monthly tagged release is quite minimal and the larger work is ensuring all documentation is up to date. Additionally all new features are generally behind their own build flags but I appreciate it is some work for a tagged release to be absorbed into product offerings. Interesting In one of our internal discussions we were exploring the possibility of using doxygen style comments and creating an API reference for a release without a lot of effort. We should try to explore this idea in the community. >> One thing that had been considered briefly was the production of a security bug only branch That is a good idea and can act as the base for the LTS version. But we should consider increasing the scope and include bug fixes, stability issues, performance issues, etc. I believe when the community widely adopts TFTF and starts upstreaming the test cases, we can expect more interest around a LTS release. For platform owners (e.g. NVIDIA) it makes sense to plan our release strategy around LTS versions. Right now, our releases lack direction as we don’t know which version to use. And then there is additional pain of rebasing recent fixes/improvements on older releases. -Varun -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Joanna Farley via TF-A Sent: Thursday, June 11, 2020 6:47 AM To: Matteo Carlini <Matteo.Carlini(a)arm.com>; tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] ATF LTS version External email: Use caution opening links or attachments Hi Varun, I guess this suggestion came in response to last weeks Tech Forum discussion from a question about experiences people had from migrating to different TF-A tagged releases. In general we try and keep the tip of Master at tagged release quality through an extensive CI system ran on each patch. I appreciate this CI is currently a little opaque to many contributors as this is still in the process of being transitioned to the OpenCI hosted by Trustedfirmware.org servers which will be visible to all. As mentioned in the recent "Overview of the TF-A v2.3 Release" presentation on https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ the additional testing done for a 6 monthly tagged release is quite minimal and the larger work is ensuring all documentation is up to date. Additionally all new features are generally behind their own build flags but I appreciate it is some work for a tagged release to be absorbed into product offerings. I asked at the tech forum last week what more we could do to allow releases to be integrated more easily. On the call it was requested if we could disable weak bindings to symbols so it could be more easily seen where platform decisions may need to be made and we will look into this. If there are any more adjustments to the way tagged releases are produced please let us know. One thing that had been considered briefly was the production of a security bug only branch that was maintained only between 6 month tagged releases before being replaced by the next security bug only branch based on the next 6 month release but that has not progressed very far as a proposal as until your email here it was perceived to not be in demand. A LTS branch is a larger endeavour as it sounds like something that includes more than security fixes and I look forward to you elaborating more as Matteo requests. Thanks Joanna On 11/06/2020, 12:19, "Matteo Carlini via TF-A" <tf-a(a)lists.trustedfirmware.org> wrote: Hi Varun, Thanks for raising this topic (but please do embrace the official terminology “TF-A”…we never really promoted ATF and it's also absolutely outdated now 😉 ). Arm has received different queries over time on supporting Trusted Firmware LTS releases, but the effort to sustain them is something that the Arm engineering team alone cannot really afford and commit to (either in the TF-A or TF-M space). The idea has also been just raised to the Trusted Firmware project Board for initial consideration and we will be all very keen to understand how much interest there is from the wider TF-A community of adopters and external (non-Arm) maintainers, so to evaluate the possibility of a more concrete proposal to be carried on within the community Project. I guess it will also be good to start by elaborating more concretely on the requirements that you would like to see in an hypothetical LTS versioning scheme. Thanks Matteo > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Varun Wadekar via TF-A > Sent: 10 June 2020 22:47 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] ATF LTS version > > Hello team, > > To extend the discussion around version upgrades from our last call, I would like to understand if there is enough interest around generating a LTS version of the TF-A to alleviate the pain. > > For NVIDIA, this would be helpful as it streamlines the upgrade path for our devices in the field. The LTS version will guarantee security fixes, bug fixes, stability fixes for the longer term and we won’t have to upgrade the entire firmware to get these goodies. > > It would be interesting to see what OEMs and maintainers think about this? Has this been discussed at tf.org or Arm internally? > > -Varun -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

3 years, 10 months

2
3
0 0

2024

2023

2022

2021

2020

2019

2018

TF-A June 2020