Hi,
We are going to configure Coverity Scan Online to make it send
notifications to this mailing list. This way, everyone subscribed on
this mailing list will be aware of newly detected/eliminated defects
found by the tool.
The report will provide a summary of the findings (their nature,
location in the source code). In order to look up the details or to
triage them, you will still need to access the database through the web
portal on
https://scan.coverity.com/projects/arm-software-arm-trusted-firmware .
As a reminder, you will need to create an account to view the defects
there (it's possible to use your Github account).
This is expected to generate a low volume of emails, as we typically do
1 analysis per week day.
As a heads up, the web interface mentions that "an authorization
confirmation will be sent to each newly provided email address and must
be acknowledged before notifications will be sent". In which case,
please ignore these emails.
Regards,
Sandrine
Hi Tristan,
Can you please clarify what your exact concern is? Which files and what text exactly? That will help us answer your concern.
Thanks
Joanna
On 16/09/2019, 23:48, "TF-A on behalf of Tristan Muntsinger via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote:
Hello all,
It looks like the copyright guidance on this project changed about a year
ago (Nov 13, 2018) to a placeholder and hasn't been corrected yet. Can
this be fixed to make the license valid so the project can be legally
redistributed per BSD-3 as intended?
Thanks,
Tristan Muntsinger
--
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.
Hi Dan,
Whoops, sorry, this fell through the cracks for me since I wasn't on
the to: line. Thanks for your response!
> 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.
Yes, of course, we can gate this with a build option so it would only
be available where desired.
> 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.
Right, but defining a separate vendor-specific reset type for each
platform is roughly the same as defining a separate SiP SMC for each
of them. It's the same problem that the SMC/PSCI spec and the TF
repository layout is only designed to deal with generic vs.
SoC-vendor-specific differentiation. If the normal world OS needs a
feature, we can only make it generic or duplicate it across all
vendors running that OS.
> 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.
Yes, I think that would be the best option. Could you kick off that
process with the Architecture team? Or tell me who I should talk to
about this?
Thanks,
Julius
Hello all,
It looks like the copyright guidance on this project changed about a year
ago (Nov 13, 2018) to a placeholder and hasn't been corrected yet. Can
this be fixed to make the license valid so the project can be legally
redistributed per BSD-3 as intended?
Thanks,
Tristan Muntsinger
Hi Yann,
You are quite correct. We will be looking to create a v2.2 tag release sometime early to mid October. You can expect a more formal notification and a request to get any patches submitted in the next week or so. As in previous releases master will be generally locked for a week or so while closedown testing is performed although we will assess incoming patches to see if they can be taken with low risk.
Joanna
On 16/09/2019, 13:19, "TF-A on behalf of Yann GAUTIER via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote:
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
--
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.
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
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
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.
-----------------------------------------------------------------------------------
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.
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
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
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.
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
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.
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.
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
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
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.
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
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.