- TF-A - lists.trustedfirmware.org

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

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, 3 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, 3 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, 3 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, 3 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, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A