- TF-A - lists.trustedfirmware.org

by Yann GAUTIER

Hi, >From the wiki page https://developer.trustedfirmware.org/w/tf_a/tf-a_release_information/, the next v2.2 tag may be released soon. But the exact timeframe is not yet published. The wiki page might be updated if you have more information. When do you expect to release tag v2.2? What will be the deadline to send patches upstream? Thanks, Yann

6 years, 1 month

1
0
0 0

Re: [TF-A] On supporting unmaintained platforms and downstream projects

by Julius Werner

Hi Soby, > Hi Julius, > Apologize for the radio silence as I was on sabbatical. Yes, I agree the > project needs to have a clear policy around platforms. We will get this > started on our end and send a policy proposal for review. No problem, thanks to Sandrine for taking care of it so quickly. Unfortunately we now discovered that we're still stuck on the same issue with MT8173. Could one of you please help getting https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/990/31 landed to fix that too? Thanks, Julius

6 years, 1 month

1
0
0 0

Merge Tegra platform changes

by Varun Wadekar

Hello Soby/Joanna, We would like to upstream support for a new Tegra platform along with some other changes. The last time I checked, there were more than 400 changes waiting to be upstreamed. Can someone help me with the best/fastest approach to start upstreaming? Previously, we would upstream changes in big chunks (as branches) but I don't know if that approach still works. Thanks. ----------------------------------------------------------------------------------- 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. -----------------------------------------------------------------------------------

6 years, 1 month

3
6
0 0

Re: [TF-A] On supporting unmaintained platforms and downstream projects

by Julius Werner

Hi Soby, > Hmm, if we merge a non-trivial patch and ensure the build works, then we > do not know whether it runs correctly, whether there are any runtime > effects that would affect stability/robustness of the platform that even > might have security implications. Hence, in my view, it is better to > have a broken build for the platform, rather than have runtime problems. > > The project could form a policy that if a platform remains broken for > more than 2 releases (1 year by current release intervals), then it will > get removed from the tree after giving enough notifications. Thanks, yes, I think it would be good to have a clear policy on this, whatever it is. I would still like to make a case for keeping these platforms in the tree on a best-effort basis. You're right that there's a chance for untested patches to cause all sorts of runtime errors, but I think that may still be better than a platform that doesn't build at all. A platform that doesn't build doesn't benefit anyone. A platform that may have errors still has a chance of working, and even if it doesn't it gives a third-party contributor or hobby developer who wants to start using it a chance to fix it up again. This is something we occasionally see happening with some of our older, less maintained platforms in coreboot. But if it doesn't even build, the chance of someone coming along to fix it seem very slim, because then more and more build issues will keep piling up over time. (In fact, I doubt there's even any point in keeping broken stuff in the tree for another year as you proposed... likely all that would do is confuse people who are trying to refactor project-wide APIs. Code that's never build-tested just bit rots very quickly. I think at that point you might as well remove it from the repo immediately.) It's true that there may also be security issues (which is more serious), but I'm skeptical that this really makes a lot of difference. After all, this may happen even while the platform is still actively maintained. Just testing whether it boots doesn't make sure you have no security issues anyway. Maybe a way to make this more visible instead could be to introduce a new ALLOW_UNMAINTAINED_PLATFORM=1 make variable that the user has to explicitly set to build a platform without active maintainer? That could serve as a warning that the code may not be safe to use for critical applications anymore while still giving developers access to something if they're willing to deal with possible issues. Anyway, whatever the policy may be, a more defined process would help. I think the initial messaging around the console deprecation plan was fine, but it would have been good to have another explicit announcement when the CI actually gets turned off for a platform.

6 years, 1 month

2
1
0 0

Re: [TF-A] broken link in phabricator wiki

by Sandrine Bailleux

Hi Leif, On 9/3/19 3:16 AM, Leif Lindholm via TF-A wrote: > On page https://developer.trustedfirmware.org/w/tf_a/gerrit-getting-started/ > the link to "new TF-A Contribution Guidelines" points at > https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/contribut…, > which is a dead link. > I expect it is meant to be pointing to > https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/proc…. You're right, thanks for pointing it out. We forgot to update this page when the docs hierarchy got restructured some time ago. This is now fixed. Regards, Sandrine

6 years, 1 month

1
0
0 0

broken link in phabricator wiki

by Leif Lindholm

Hi there, On page https://developer.trustedfirmware.org/w/tf_a/gerrit-getting-started/ the link to "new TF-A Contribution Guidelines" points at https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/contribut…, which is a dead link. I expect it is meant to be pointing to https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/proc…. Best Regards, Leif

6 years, 1 month

1
0
0 0

Re: [TF-A] On supporting unmaintained platforms and downstream projects

by Sandrine Bailleux

Hi Julius, On 8/27/19 9:55 PM, Julius Werner via TF-A wrote: > Could either of you please help get the Tegra fix in > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1192 > landed (and subsequently CI for Tegra re-enabled)? It has been > reviewed and approved for two weeks but nobody is merging it. This is > blocking more and more work across all coreboot-based platforms so I > would appreciate if we could get it resolved quickly. Apologies for the delay. As you may have seen, the patch has now been merged, and we've also re-enabled the Tegra builds in the CI. Regards, Sandrine

6 years, 2 months

2
1
0 0

Re: [TF-A] On supporting unmaintained platforms and downstream projects

by Julius Werner

Hi Soby, Joanna, Could either of you please help get the Tegra fix in https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1192 landed (and subsequently CI for Tegra re-enabled)? It has been reviewed and approved for two weeks but nobody is merging it. This is blocking more and more work across all coreboot-based platforms so I would appreciate if we could get it resolved quickly. Thanks, Julius

6 years, 2 months

2
1
0 0

Ultra96-V1 stops booting since b8e39f49e634

by Jan Kiszka

Hi all, I've bisected a boot issue of my Ultra96 version 1 down to commit [1]. U-Boot plays no role, I tried current master, 2019.07 and 2019.01. What might be related: I'm using pre-built fsbl, pmu-fw and bitstream from Alex' OpenSUSE packages [2][3][4]. Build steps are as described in [5]. Meanwhile, I rebuilt at least the pmu-fw from current embeddedsw git (c12743e5d7b0), but also without any impact on the issue. Any idea what could be wrong and why specifically this commit triggers it? I'd like to lift everything to a recent ATF version because of compilation issues with currently used 1.6 and newer gcc releases. Thanks, Jan [1] https://github.com/ARM-software/arm-trusted-firmware/commit/b8e39f49e634 [2] https://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Zy… [3] https://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Zy… [4] https://download.opensuse.org/repositories/devel:/ARM:/Factory:/Contrib:/Zy… [5] https://github.com/siemens/jailhouse-images/blob/v0.11/recipes-bsp/u-boot/f…

6 years, 2 months

2
2
0 0

Re: [TF-A] SMC to intentionally trigger a panic in TF-A

by Dan Handley

Hi Julius > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Julius > Werner via TF-A > Sent: 20 August 2019 02:15 > > Hi Soby et. al., > > I'd like to implement a small new feature and ask some guidance for how to go > about it: Chrome OS has the ability to automatically collect crash reports > from runtime crashes in Trusted Firmware, and we would like to set up > automated tests to ensure this feature stays working. > In order to do this we need a way for the non-secure OS to intentionally > trigger a panic in EL3. The obvious solution would be to implement a new SMC > for that. (It's common for operating systems to have similar facilities, e.g. > Linux can force a kernel panic by writing 'c' into /proc/sysrq-trigger.) > OK I can see the use of that, although I'd be a bit concerned about such a thing being available as a general service in case it gets used as an attack vector. For example, a test program could aggressively use this service to try to get the firmware to leak secure world information or something about its behaviour. > My main question is: where should I get an SMC function ID for this? > This is not a silicon or OEM specific feature, so the SiP Service Calls and > OEM Service Calls ID ranges seem inappropriate (or do you think it would make > sense to treat Google or Chrome OS as the "OEM" > here, even though that's not quite accurate?). I guess in theory you could mandate that all Chrome OS SiPs provide a specific function ID in their own specific SiP service, but I don't think that's the right solution here... > There are ranges for Trusted > Applications and the Trusted OS but unfortunately none for the normal world > OS. I don't think the TOS range is right either. > Is this something that would make sense to allocate under Standard > Service Calls? Could you just find an ID for me to use there or does > everything in that range need a big specification document written by Arm? > For sure everything in the standard or architectural ranges require specification by Arm, although this does not necessarily need to be big. However, I think there might already be support for what you need. PSCI is part of the standard service and the function SYSTEM_RESET2 allows for both architectural and vendor-specific resets. The latter allows for vendor-specific semantics, which could include crashing the firmware as you suggest. Chrome OS could specify what such a vendor-specific reset looks like and each Chromebook's platform PSCI hooks could be implemented accordingly. Alternatively, this could potentially be defined as an additional architectural reset. This would enable a generic implementation but would require approval/definition by Arm's Architecture team. Like me they might have concerns about this being defined at a generic architectural level. Regards Dan. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 2 months

1
0
0 0

SMC to intentionally trigger a panic in TF-A

by Julius Werner

Hi Soby et. al., I'd like to implement a small new feature and ask some guidance for how to go about it: Chrome OS has the ability to automatically collect crash reports from runtime crashes in Trusted Firmware, and we would like to set up automated tests to ensure this feature stays working. In order to do this we need a way for the non-secure OS to intentionally trigger a panic in EL3. The obvious solution would be to implement a new SMC for that. (It's common for operating systems to have similar facilities, e.g. Linux can force a kernel panic by writing 'c' into /proc/sysrq-trigger.) My main question is: where should I get an SMC function ID for this? This is not a silicon or OEM specific feature, so the SiP Service Calls and OEM Service Calls ID ranges seem inappropriate (or do you think it would make sense to treat Google or Chrome OS as the "OEM" here, even though that's not quite accurate?). There are ranges for Trusted Applications and the Trusted OS but unfortunately none for the normal world OS. Is this something that would make sense to allocate under Standard Service Calls? Could you just find an ID for me to use there or does everything in that range need a big specification document written by Arm? Thanks, Julius

6 years, 2 months

1
0
0 0

Re: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the PMCR_EL0 across world switching

by Alexei Fedorov

Hi Marek The patch is available at https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1789 Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 19 August 2019 11:41 To: Marek <marek.bykowski(a)gmail.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the PMCR_EL0 across world switching Hi Marek, Changes are in review so hopefully soon. Joanna On 19/08/2019, 10:56, "TF-A on behalf of Marek via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi Dan, Are there any time estimates when the fix should be in? Thanks, Marek On Sat, 10 Aug 2019 at 22:46, Marek via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Thank you Dan for checking this out. Looking forward into the fix. > > Marek > > On Thu, 8 Aug 2019 at 17:52, Dan Handley via TF-A > <tf-a(a)lists.trustedfirmware.org> wrote: > > > > Hi Marek > > > > Thanks for pointing this out. Typically we expect any timing sensitive secure operations to be implemented at Secure-EL1 or lower, which the current code does protect. However, you are correct that all secure world code including EL3 should not expose timing information. A fix is in progress to address this. > > > > Regards > > > > Dan. > > > > > -----Original Message----- > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Marek > > > Bykowski via TF-A > > > Sent: 03 August 2019 07:37 > > > To: tf-a(a)lists.trustedfirmware.org; David Cunado <David.Cunado(a)arm.com> > > > Subject: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the > > > PMCR_EL0 across world switching > > > > > > Hi David/ATF Support, > > > > > > An excerpt from the commit message to CVE-2017-15031 is "Additionally, > > > PMCR_EL0 is added to the list of registers that are saved and restored during > > > a world switch." > > > > > > My question is why it is only being saved/restored across the world switch > > > and not during a "normal" SMC call? When I do modify the > > > PMCR_EL0 in EL2 or NonSecure-EL1 and run the smc call the PMCCNTR counter > > > counts during the smc call and does expose secure world timing information to > > > NonSecure in that matter. > > > > > > Thanks, > > > Marek > > > -- > > > 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. > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > > -- > Slán, > Marek > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- Slán, Marek -- 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. -- 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.

6 years, 2 months

1
0
0 0

Re: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the PMCR_EL0 across world switching

by Joanna Farley

Hi Marek, Changes are in review so hopefully soon. Joanna On 19/08/2019, 10:56, "TF-A on behalf of Marek via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi Dan, Are there any time estimates when the fix should be in? Thanks, Marek On Sat, 10 Aug 2019 at 22:46, Marek via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Thank you Dan for checking this out. Looking forward into the fix. > > Marek > > On Thu, 8 Aug 2019 at 17:52, Dan Handley via TF-A > <tf-a(a)lists.trustedfirmware.org> wrote: > > > > Hi Marek > > > > Thanks for pointing this out. Typically we expect any timing sensitive secure operations to be implemented at Secure-EL1 or lower, which the current code does protect. However, you are correct that all secure world code including EL3 should not expose timing information. A fix is in progress to address this. > > > > Regards > > > > Dan. > > > > > -----Original Message----- > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Marek > > > Bykowski via TF-A > > > Sent: 03 August 2019 07:37 > > > To: tf-a(a)lists.trustedfirmware.org; David Cunado <David.Cunado(a)arm.com> > > > Subject: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the > > > PMCR_EL0 across world switching > > > > > > Hi David/ATF Support, > > > > > > An excerpt from the commit message to CVE-2017-15031 is "Additionally, > > > PMCR_EL0 is added to the list of registers that are saved and restored during > > > a world switch." > > > > > > My question is why it is only being saved/restored across the world switch > > > and not during a "normal" SMC call? When I do modify the > > > PMCR_EL0 in EL2 or NonSecure-EL1 and run the smc call the PMCCNTR counter > > > counts during the smc call and does expose secure world timing information to > > > NonSecure in that matter. > > > > > > Thanks, > > > Marek > > > -- > > > 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. > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > > -- > Slán, > Marek > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- Slán, Marek -- 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.

6 years, 2 months

1
0
0 0

Re: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the PMCR_EL0 across world switching

by Marek

Hi Dan, Are there any time estimates when the fix should be in? Thanks, Marek On Sat, 10 Aug 2019 at 22:46, Marek via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Thank you Dan for checking this out. Looking forward into the fix. > > Marek > > On Thu, 8 Aug 2019 at 17:52, Dan Handley via TF-A > <tf-a(a)lists.trustedfirmware.org> wrote: > > > > Hi Marek > > > > Thanks for pointing this out. Typically we expect any timing sensitive secure operations to be implemented at Secure-EL1 or lower, which the current code does protect. However, you are correct that all secure world code including EL3 should not expose timing information. A fix is in progress to address this. > > > > Regards > > > > Dan. > > > > > -----Original Message----- > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Marek > > > Bykowski via TF-A > > > Sent: 03 August 2019 07:37 > > > To: tf-a(a)lists.trustedfirmware.org; David Cunado <David.Cunado(a)arm.com> > > > Subject: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the > > > PMCR_EL0 across world switching > > > > > > Hi David/ATF Support, > > > > > > An excerpt from the commit message to CVE-2017-15031 is "Additionally, > > > PMCR_EL0 is added to the list of registers that are saved and restored during > > > a world switch." > > > > > > My question is why it is only being saved/restored across the world switch > > > and not during a "normal" SMC call? When I do modify the > > > PMCR_EL0 in EL2 or NonSecure-EL1 and run the smc call the PMCCNTR counter > > > counts during the smc call and does expose secure world timing information to > > > NonSecure in that matter. > > > > > > Thanks, > > > Marek > > > -- > > > 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. > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > > -- > Slán, > Marek > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- Slán, Marek

6 years, 2 months

1
0
0 0

Re: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the PMCR_EL0 across world switching

by Marek

Thank you Dan for checking this out. Looking forward into the fix. Marek On Thu, 8 Aug 2019 at 17:52, Dan Handley via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Marek > > Thanks for pointing this out. Typically we expect any timing sensitive secure operations to be implemented at Secure-EL1 or lower, which the current code does protect. However, you are correct that all secure world code including EL3 should not expose timing information. A fix is in progress to address this. > > Regards > > Dan. > > > -----Original Message----- > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Marek > > Bykowski via TF-A > > Sent: 03 August 2019 07:37 > > To: tf-a(a)lists.trustedfirmware.org; David Cunado <David.Cunado(a)arm.com> > > Subject: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the > > PMCR_EL0 across world switching > > > > Hi David/ATF Support, > > > > An excerpt from the commit message to CVE-2017-15031 is "Additionally, > > PMCR_EL0 is added to the list of registers that are saved and restored during > > a world switch." > > > > My question is why it is only being saved/restored across the world switch > > and not during a "normal" SMC call? When I do modify the > > PMCR_EL0 in EL2 or NonSecure-EL1 and run the smc call the PMCCNTR counter > > counts during the smc call and does expose secure world timing information to > > NonSecure in that matter. > > > > Thanks, > > Marek > > -- > > 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. > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- Slán, Marek

6 years, 2 months

1
0
0 0

Re: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the PMCR_EL0 across world switching

by Dan Handley

Hi Marek Thanks for pointing this out. Typically we expect any timing sensitive secure operations to be implemented at Secure-EL1 or lower, which the current code does protect. However, you are correct that all secure world code including EL3 should not expose timing information. A fix is in progress to address this. Regards Dan. > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Marek > Bykowski via TF-A > Sent: 03 August 2019 07:37 > To: tf-a(a)lists.trustedfirmware.org; David Cunado <David.Cunado(a)arm.com> > Subject: [TF-A] Advisory TFV 5 to CVE-2017-15031 only saves/stores the > PMCR_EL0 across world switching > > Hi David/ATF Support, > > An excerpt from the commit message to CVE-2017-15031 is "Additionally, > PMCR_EL0 is added to the list of registers that are saved and restored during > a world switch." > > My question is why it is only being saved/restored across the world switch > and not during a "normal" SMC call? When I do modify the > PMCR_EL0 in EL2 or NonSecure-EL1 and run the smc call the PMCCNTR counter > counts during the smc call and does expose secure world timing information to > NonSecure in that matter. > > Thanks, > Marek > -- > 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.

6 years, 2 months

1
0
0 0

On supporting unmaintained platforms and downstream projects

by Julius Werner

Hi Soby et. al., I wanna kick off a little discussion about how TF-A intends to deal with in-tree platform ports as they get older and the interest in maintaining them drops off. Concretely, I noticed that the plat/nvidia/tegra platforms no longer build since the removal of the deprecated console API in https://review.trustedfirmware.org/842 last month. There has been a patch suggestion to fix it uploaded at https://review.trustedfirmware.org/1192 for two months, but it hasn't moved forward because it seems that Arm thinks it's on the platform maintainer (Nvidia) to finish up and test the patch, and they don't seem to be responding. This creates a problem for downstream projects like coreboot and Chrome OS that use Trusted Firmware on Tegra chips and build-test them in their CI systems. My assumption when setting up the Trusted Firmware integration for them was that the Trusted Firmware CI would build test all in-tree platforms for every commit anyway, so we could always assume that all platforms build on the current master... but clearly, that assumption broke in this case. (I guess because you manually overrode the CI in https://review.trustedfirmware.org/842? Or does it not test all platforms anyway?) So now, coreboot is stuck on an old TF-A version and cannot move forward for any platform until we either kick out the Tegra SoCs or get the problem fixed in TF-A (which is a problem with the testing because I don't have a Tegra board on hand either). How do you think we should solve issues like this? Is keeping platforms that don't build in the tree an intended state? Is there some deadline after which you intend to remove the platform completely? Or would it be better to just merge "best effort" commits like https://review.trustedfirmware.org/1192 that we think should do the right thing for the platform (and at least makes it build again), even if nobody is around to test it on real hardware? To give some experience from the coreboot project, I think it's an unfortunate truth that SoC vendors just tend to lose interest in maintaining hardware once it's more than 2-3 years old. At that point the open-source community has to jump in to continue maintenance, and they can only do it on a best effort basis. It's not possible to always find someone with the right hardware and time to test it for all these old platforms whenever you're trying to do some large, project wide API change, so eventually you'll just have to accept patches that haven't been tested for them. Most of the times (if reviewers pay attention) it works well, sometimes they break. If they do, eventually someone will notice and then they'll have to bisect and fix it. I believe Linux is essentially doing the same thing for lesser-used hardware. It's either that, or you have to constantly kick out old platforms after a few years. (From the coreboot point of view, kicking the Tegra platforms out of TF-A would mean we're forced to remove them from coreboot as well, which would be unfortunate.) Let me know what you think! Julius

6 years, 2 months

3
4
0 0

Re: [TF-A] On supporting unmaintained platforms and downstream projects

by Joanna Farley

Hi Julius, It’s a valid issue you have raised. In general we rely on the platform maintainer to work with us to keep their platform port fresh and in this case we proposed some changes and was looking for feedback from the maintainer. We try in our internal standups at least once a week to look for patch reviews that have had no work on them for 21 days and if we do identify any we start chasing to progress these. Eventually if after several attempts we cannot get the patch to progress we would generally look to abandon if it’s the patch originator we cannot contact. In this case it was the platform maintainer who we needed a review from and you managed to get Varun to notice the patches. If we had not managed to contact them then we would have had to make a call on if to submit the changes or not to at least get the build working even though we would not be able to test them. I would like to think in the case of a broken build we would take that option rather than abandon. I think this issue is made a little worse in that the CI results are not yet open so not obvious to everybody although hopefully that will be eventually addressed with the proposed Open CI system on trustedfirmware.org where build results will be available. On top of that if partners want to engage in providing a board available that could be integrated into the LAVA farm that’s part of the CI system and would also be tested. Joanna On 03/08/2019, 01:10, "TF-A on behalf of Julius Werner via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: > Thanks for the email, Julius. To be clear, we very well intend to be part of the TF-A project. Having said that, I was not aware of the two commits you mentioned in the email and di not know that Tegra builds are broken in the master branch. Thanks. You were CCed on the patch so I assumed you would've seen it. If not, maybe your email address isn't set correctly in your Gerrit account or something? I've already pushed an update to https://review.trustedfirmware.org/1192 which I think should fix the issue for Tegra, but I need someone to test it. Nevertheless, I think it's a good idea to answer these questions in a general case (e.g. whether we can make sure that we won't break the build on master even if there are temporary issues with certain platforms), because it's probably going to become relevant again sooner or later even if the Tegra issue gets fixed now. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years, 2 months

1
0
0 0

Advisory TFV 5 to CVE-2017-15031 only saves/stores the PMCR_EL0 across world switching

by Marek Bykowski

Hi David/ATF Support, An excerpt from the commit message to CVE-2017-15031 is "Additionally, PMCR_EL0 is added to the list of registers that are saved and restored during a world switch." My question is why it is only being saved/restored across the world switch and not during a "normal" SMC call? When I do modify the PMCR_EL0 in EL2 or NonSecure-EL1 and run the smc call the PMCCNTR counter counts during the smc call and does expose secure world timing information to NonSecure in that matter. Thanks, Marek

6 years, 3 months

1
0
0 0

Raspberry Pi 4 ATF port

by Andre Przywara

Hi, (BCC:ing Antonio as well) not sure if someone gets notified, but I pushed a patch set to add Raspberry Pi 4 support to Trusted Firmware: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1629 This port is quite a departure from the existing RPi3 port, that's why I wanted to start a discussion about it here. I originally started by copying files. But for the sake of simplicity, also to get away without a BL33 loader, it turned into just a BL31-only port (for now?). This ties more into the existing RPi Foundation boot style, as the resulting bl31.bin is a drop-in replacement for the existing armstub8.bin. So you put your AArch64 kernel into kernel8.img and copy bl31.bin to armstub8.bin (or use the respective config.txt options to point to any other filename), and it should work (TM). The code will pick up the actual kernel and DTB load address from the GPU firmware, patch the DT to use PSCI instead of spin tables, then will drop into EL2 at the kernel load address. There could (should?) be U-Boot or EDK-II there as well, or any other kernel, for that matter. The only thing Linux specific we do is to put the DTB address into x0. I guess this doesn't hurt, even if the BL33 payload does not use this information. I would be grateful to hear some opinions about this approach. Does that sound sensible? Is the split of the platform directory (plat/rpi3 -> plat/rpi/rpi[34]) reasonable? Shall we add this design as a build option to RPi3 as well? Shall we add the "full featured" RPi3 design to RPi4 also? Looking forward to any feedback! Cheers, Andre.

6 years, 3 months

3
2
0 0

Re: [TF-A] Defects detected by Coverity Scan Online

by Sandrine Bailleux

Hi, On 7/3/19 11:15 AM, Sandrine Bailleux via TF-A wrote: > We would need help from the TF-A community for analyzing and fixing > them, especially those in platform ports and drivers. Note that there > might be false positives, in which case we would just triage them as > such in the tool's database. > > Hopefully everyone should be able to view the defects, according to the > tool's settings. You might need to create an account on > https://scan.coverity.com for that. We've received a couple of requests from users to get access to the TF-A defects database in the Coverity Scan Online service. I think it's worth clarifying the different levels of access the tool offers and how we envisage the defects triaging. In Coverity Scan Online, users can have any of the following 4 roles (in ascending order of permissions): - Observer/User: Only sees defects summary. - Defect Viewer. - Contributor/Member: Can also triage defects. - Maintainer/Owner: Also has some admin powers, like managing users and submitting builds to be analyzed. Right now, all users should be able to see the project summary and view the defects in read-only mode so this is equivalent to the "Defect viewer" role. I suspect people still need to create an account in Coverity Scan Online and be logged in to see the data. We would expect subsystems and platforms maintainers (i.e. people listed in docs/maintainers.rst [1]) to manage the defects in the part of the codebase they own, as they know best how to assess the severity of these defects and how to fix or triage them. As such, they need to have the "contributor/member" role in the tool. If you are such a maintainer, please feel free to create an account and request this role. If you would like to delegate part/all of the triaging process to a peer, that is also possible. In this case, could you please send me an email to indicate who you have chosen for this task? This is just to make sure that whoever requests the "contributor/member" role has done so with the relevant maintainer's approval. Please be aware that those with "contributor/member" role will be able to triage any defects in any part of the codebase, and not just in the subsystem/platform they maintain. "Maintainer/Owner" role will be reserved to the main maintainers (i.e. people listed at the top of docs/maintainers.rst) for now. Best regards, Sandrine [1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/maint…

6 years, 3 months

1
0
0 0

Re: [TF-A] How can I check detail error of CI failure?

by Sandrine Bailleux

Hi Jun, On 7/16/19 11:30 AM, John Tsichritzis via TF-A wrote: > Thank you for your email. Unfortunately detailed information is not available in Gerrit since CI is hosted internally. The maintainers post detailed information of the errors in case there is something that needs fixing. In this case I will post the error details in the Gerrit review itself. > > When a patch stack is submitted, usually we launch the tests on the topmost patch on the stack. In this case the entire branch gets tested, not a single commit. In other words, the testing doesn't do any "cherry-picking" on the patches, so even if there are dependencies between the patches this doesn't affect the test. That's why we usually launch the tests on the topmost patch. To add on top of what John said, I would like to mention that we are working with Linaro to have the CI loop opened up to all contributors in the future. When this day comes, you will be able to check the error log by yourself. In the meantime, I'm afraid you'll have to rely on Arm maintainers to give you the details, as John said. If they forget, please feel free to ping them in Gerrit (like you've already done for this patch). Best regards, Sandrine

6 years, 3 months

1
0
0 0

Re: [TF-A] How can I check detail error of CI failure?

by John Tsichritzis

Dear Jun, Thank you for your email. Unfortunately detailed information is not available in Gerrit since CI is hosted internally. The maintainers post detailed information of the errors in case there is something that needs fixing. In this case I will post the error details in the Gerrit review itself. When a patch stack is submitted, usually we launch the tests on the topmost patch on the stack. In this case the entire branch gets tested, not a single commit. In other words, the testing doesn't do any "cherry-picking" on the patches, so even if there are dependencies between the patches this doesn't affect the test. That's why we usually launch the tests on the topmost patch. Kind regards, John -- John Tsichritzis | Graduate Software Engineer Email: john.tsichritzis(a)arm.com<mailto:john.tsichritzis@arm.com> 110 Fulbourn Road, Cambridge, CB1 9NJ, United Kingdom https://www.arm.com/ On 16/07/2019 09.24, Jun Nie via TF-A wrote: Hi, I see below failure in this link: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1367 How can I check the error log? I am not sure it is due to lack of earlier patch in patch set or something. Because local build is OK. Patch Set 4: Verified-1 Build Failed https://jenkins.oss.arm.com/job/tf-gerrit-tforg-l1/221/ : FAILURE Jun

6 years, 3 months

1
0
0 0

How can I check detail error of CI failure?

by Jun Nie

Hi, I see below failure in this link: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1367 How can I check the error log? I am not sure it is due to lack of earlier patch in patch set or something. Because local build is OK. Patch Set 4: Verified-1 Build Failed https://jenkins.oss.arm.com/job/tf-gerrit-tforg-l1/221/ : FAILURE Jun

6 years, 3 months

1
0
0 0

Header file re-org

by Soby Mathew

Hi Everyone, This is regarding the header file re-organization patch that was submitted by Julius https://review.trustedfirmware.org/#/c/TF-A/trusted-firmware-a/+/1207/. It is necessary for the headers which form the ABI/handover interface for BL31 to be able to copied separately and included in other projects. The current approach taken in the patch is to define a "raw" version of such headers and have the original header include them. This certainly is the easiest way to solve the problem. But if it possible to have a more refined solution, that would be preferable. For that I have the following questions : 1. Should the project recognize these special headers and have them organized together in a folder ? It is important to recognize that the ABI can be extended by the platform. I would expect even if these "common" headers are organized into a folder, the platform specific ones need not go together with them. 2. Should the header be restricted from including standard C library headers ? 3. Should these ABI headers be allowed to include each other ? Forward declaration might be able to solve some of the issues, but good to have a policy on this. The current patch as such can be treated as step towards the ideal solution, if that solution needs more work/churn in the code base. Comments welcome. Best Regards Soby Mathew

6 years, 3 months

3
8
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A