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.
