- TF-A - lists.trustedfirmware.org

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, 2 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

2025

2024

2023

2022

2021

2020

2019

2018

TF-A