TF-A August 2019

tf-a@lists.trustedfirmware.org

11 participants
15 discussions

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

2025

2024

2023

2022

2021

2020

2019

2018

TF-A August 2019