Updates to reflect ownership changes
In September 2019 ownership of OP-TEE was transferred from Linaro to
TrustedFirmware.org and therefore we need to update the documentation to
reflect that.
- General changes from Linaro to TrustedFirmware.org.
- Updating contact information to use a TrustedFirmware.org hosted
mailinglist.
Signed-off-by: Joakim Bech <joakim.bech@linaro.org>
Reviewed-by: Jerome Forissier <jerome@forissier.org>
diff --git a/LICENSE b/LICENSE
index 2389721..9ffac73 100644
--- a/LICENSE
+++ b/LICENSE
@@ -1,6 +1,6 @@
BSD 2-Clause License
-Copyright (c) 2019 Linaro
+Copyright (c) 2020 TrustedFirmware.org
All rights reserved.
Redistribution and use in source and binary forms, with or without
diff --git a/architecture/porting_guidelines.rst b/architecture/porting_guidelines.rst
index 0744064..0be444e 100644
--- a/architecture/porting_guidelines.rst
+++ b/architecture/porting_guidelines.rst
@@ -234,13 +234,12 @@
**Maintainer**
-If you are submitting the board support upstream and cannot give Linaro
-maintainers a device, then we are going to ask you to become the maintainer for
-the device you have added. This means that you should also update the
-MAINTAINERS.md_ file accordingly. By being a maintainer for a device you are
-responsible to keep it up to date and you will be asked every quarter as part of
-the OP-TEE release schedule to test your device running the latest OP-TEE
-software.
+If you are submitting the board support upstream we are going to ask you to
+become the maintainer for the device you have added. This means that you should
+also update the MAINTAINERS.md_ file accordingly. By being a maintainer for a
+device you are responsible to keep it up to date and you will be asked every
+quarter as part of the OP-TEE release schedule to test your device running the
+latest OP-TEE software.
**Update build.git and manifest.git**
diff --git a/building/devices/rpi3.rst b/building/devices/rpi3.rst
index 9edc78b..89dd347 100644
--- a/building/devices/rpi3.rst
+++ b/building/devices/rpi3.rst
@@ -679,7 +679,6 @@
.. _core team: https://github.com/orgs/OP-TEE/teams/linaro/members
.. _eBay: https://www.ebay.com/sch/i.html?&_nkw=UART+cable
.. _J-Link debuggers: https://www.segger.com/jlink_base.html
-.. _Linaro rootfs: http://releases.linaro.org/debian/images/installer-arm64/latest/linaro*.tar.gz
.. _official OpenOCD: http://openocd.org
.. _RPi3 in TF-A: https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/plat/rpi3.rst
.. _RPi3 OpenOCD config: https://github.com/OP-TEE/build/blob/master/rpi3/debugger/pi3.cfg
diff --git a/building/gits/build.rst b/building/gits/build.rst
index 18c427a..d68c4ea 100644
--- a/building/gits/build.rst
+++ b/building/gits/build.rst
@@ -63,19 +63,16 @@
How do I build using AOSP / OpenEmbedded?
*****************************************
For guides how to build AOSP, please refer to our :ref:`aosp` page. For
-OpenEmbedded we have no guide ready, however there are teams in Linaro who are
-building OP-TEE using OpenEmbedded. If you want to get in contact with them,
-please reach out to us (see :ref:`contact`).
+OpenEmbedded we have no guide ready.
.. _optee_developer_setup:
Platforms supported by build.git
********************************
Below is a table showing the platforms supported by build.git. OP-TEE as such
-supports many more platforms, but since quite a few of the other platforms are
-maintained by people outside Linaro or are using a special setup, we encourage
-you to talk to the maintainer of that platform directly if you have build
-related questions etc. Please see the MAINTAINERS_ file for contact information.
+supports many more platforms. To find out how to run OP-TEE on those, please
+reach out to the maintainer of that platform directly if you have build related
+questions etc. Please see the MAINTAINERS_ file for contact information.
.. Please keep this list sorted in alphabetic order:
.. list-table::
diff --git a/building/trusted_applications.rst b/building/trusted_applications.rst
index ab067b9..48abc61 100644
--- a/building/trusted_applications.rst
+++ b/building/trusted_applications.rst
@@ -6,11 +6,9 @@
This document tells how to implement a Trusted Application for OP-TEE, using
OP-TEE's so called `TA-devkit` to both build and sign the Trusted Application
binary. In this document, a `Trusted Application` running in the OP-TEE os is
-referred to as a `TA`.
-Note that in the default setup a private key generated by Linaro and
+referred to as a `TA`. Note that in the default setup a private test key is
distributed along with the :ref:`optee_os` source is used for signing Trusted
-Applications.
-See TASign_ for more details, including offline signing of TAs.
+Applications. See TASign_ for more details, including offline signing of TAs.
TA Mandatory files
******************
diff --git a/conf.py b/conf.py
index 2cf3f36..b1d1f2e 100644
--- a/conf.py
+++ b/conf.py
@@ -20,8 +20,8 @@
# -- Project information -----------------------------------------------------
project = 'OP-TEE documentation'
-copyright = '2019 - 2020 Linaro'
-author = 'Linaro'
+copyright = '2019 - 2020 TrustedFirmware.org'
+author = 'TrustedFirmware.org'
# The short X.Y version
version = ''
@@ -136,7 +136,7 @@
# author, documentclass [howto, manual, or own class]).
latex_documents = [
(master_doc, 'OP-TEE.tex', 'OP-TEE Documentation',
- 'Linaro', 'manual'),
+ 'TrustedFirmware.org', 'manual'),
]
diff --git a/faq/faq.rst b/faq/faq.rst
index 63ea8fc..d277515 100644
--- a/faq/faq.rst
+++ b/faq/faq.rst
@@ -132,10 +132,8 @@
setup using QEMU, HiKey, RPi3, Juno using repo? AOSP? OpenEmbedded? What
we build on daily basis are the OP-TEE developer setups (see
:ref:`optee_developer_setup`) , but other builds like AOSP and
- OpenEmbedded are builds that we try from time to time, but not very often
- within Security Working Group. Having that said there are other teams in
- Linaro working with such builds, but they most often base their builds on
- OP-TEE stable releases.
+ OpenEmbedded are builds that we try from time to time, but we have no
+ CI/regression testing configured for those builds.
- By running latest instead of stable also comes with a risk of getting
build errors due to version and/or interdependency skew which can result
@@ -207,16 +205,12 @@
Certification and security reviews
**********************************
-Q: Will linaro be involved in GlobalPlatform certification/qualification?
-=========================================================================
- - No we will not, mainly for two reasons. The first is that there was a
- board decision that Security WG in Linaro should not be part of
- certifications. The second reason is that most often certification is done
- using a certain software version and on a unique device. I.e., it is the
- combination software + hardware that gets certified. Since Linaro have no
- own devices in production or for sale, we cannot be part of any
- certification. This is typically something that the SoC or OEM needs to
- do.
+Q: Will TrustedFirmware.org be involved in GlobalPlatform certification/qualification?
+======================================================================================
+ - No, not as of now. Most often certification is performed using a certain
+ software version and on a unique device. I.e., it is the combination
+ software + hardware that gets certified. This is typically something that
+ the SoC or OEM needs to do on their own.
- But it is worth mentioning that since OP-TEE is coming from a proprietary
TEE solution that was GlobalPlatform certified on some products in the
@@ -240,10 +234,12 @@
Q: Have there been any code audit / code review done?
=====================================================
- - Full audit? No! Not something initiated by Linaro. But there has been some
- companies that have done audits internally and they have then shared the
- result with us and where relevant, we have created patches resolving the
- issues reported to us (see :ref:`q_has_any_test_lab_been_testing_op-tee`).
+ - Full audit? No! But in the past Linaro have been collaborating with
+ Riscure trying to identify and fix potential security issues. There has
+ also been some companies that have done audits internally and they have
+ then shared the result with us and where relevant, we have created patches
+ resolving the issues reported to us (see
+ :ref:`q_has_any_test_lab_been_testing_op-tee`).
- Code review, yes! Every single patch going into OP-TEE has been reviewed
in a pull request on GitHub. We more or less have a requirement that every
@@ -507,9 +503,10 @@
Q: I've heard that there is a Widevine and PlayReady TA, how do I get access?
=============================================================================
- - Those can only be shared are under WMLA and NDA/MLA with Google and
- Microsoft. Linaro can help members of Linaro to get access to those. As of
- now, we cannot share it with non-members.
+ - TrustedFirmware have no such implementation, but Linaro do have reference
+ implementations for that that they share with their members who have
+ signed the WMLA and NDA/MLA with Google and Microsoft. So the advice is to
+ reach out to Linaro if you have questions about that.
.. _Issue#280: https://github.com/OP-TEE/optee_os/issues/280
.. _Issue#601: https://github.com/OP-TEE/optee_os/issues/601
diff --git a/general/about.rst b/general/about.rst
index fa8f56e..aece7bb 100644
--- a/general/about.rst
+++ b/general/about.rst
@@ -82,9 +82,11 @@
this. That press release contains a bit more information. At the first year as
an open source project it was owned by STMicroelectronics but maintained by
Linaro and STMicroelectronics. In 2015 there was an ownership transfer of
-OP-TEE from STMicroelectronics to Linaro and since then it has been Linaro who
-is the primary owner and maintainer of the project. But for the maintenance
-part, it has become a shared responsibility between Linaro, Linaro members and
-other companies who are using OP-TEE.
+OP-TEE from STMicroelectronics to Linaro. In September 2019, ownership was
+transferred from Linaro to the TrustedFirmware.org project (see _blogpost for
+more information). Maintenance is a shared responsibility between the members
+for TrustedFirmware.org and some community maintainers representing other
+companies who are using OP-TEE.
+.. _blogpost: https://www.trustedfirmware.org/blog/op-tee-moving-into-trusted-firmware/
.. _checkpatch: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/scripts/checkpatch.pl
diff --git a/general/contact.rst b/general/contact.rst
index eb20037..6038c94 100644
--- a/general/contact.rst
+++ b/general/contact.rst
@@ -21,13 +21,9 @@
Email
*****
You can reach the :ref:`core_team` by sending an email to
-``<op-tee[at]linaro[dot]org>``. However note that the team consist of engineers
-from different companies, i.e, it is **not** just Linaro engineers behind that
-email address.
-
-From time to time we are also using the `Tee-dev`_ mailinglist
-``<tee-dev[at]lists[dot]linaro[dot]org>``. It has mostly been used when we have
-discussed and sent patches related to the TEE framework in Linux kernel.
+``op-tee[at]lists.trustedfirmware.org``. However note that it's a public
+mailinglist and **not** just TrustedFirmware engineers behind that email
+address.
For pure Linux kernel patches, please use the appropriate Linux kernel
mailinglist, basically run the ``get_maintainer.pl`` script in the Linux kernel
@@ -60,10 +56,9 @@
Core Team
*********
-The core team consists of engineers from Linaro and engineers from Linaro's
-member companies. Related, see the `core team`_ at GitHub.
+The core team consists of engineers from TrustedFirmware.org. Related, see the
+`core team`_ at GitHub.
.. _core team: https://github.com/orgs/OP-TEE/teams/linaro/members
.. _issues: https://help.github.com/articles/about-issues/
.. _issues at optee_os: https://github.com/OP-TEE/optee_os/issues
-.. _Tee-dev: https://lists.linaro.org/mailman/listinfo/tee-dev
diff --git a/general/disclosure.rst b/general/disclosure.rst
index c13d7a9..4c6edd0 100644
--- a/general/disclosure.rst
+++ b/general/disclosure.rst
@@ -9,9 +9,9 @@
the responsible disclosure policy that applies to the OP-TEE project.
.. note::
- The "`core team`_" in Linaro (who owns the OP-TEE project) consists of
- engineers directly employed by Linaro as well as engineers employed by
- companies who are members of Linaro.
+ The "`core team`_" in the OP-TEE part of TrustedFirmware.org (who owns the
+ OP-TEE project) mainly consists of engineers coming from the members of
+ TrustedFirmware.org.
Rules
*****
@@ -19,15 +19,15 @@
conditions that applies both when it comes to being a taker of information as
well as being reporter of security issues. It should be noted that it is hard to
write rules that you can follow to 100%, since depending on the type of security
-issues being dealt with it might or might not be possible for the core team and
-Linaro to re-distribute the information right away.
+issues being dealt with it might or might not be possible for
+TrustedFirmware.org to re-distribute the information right away.
As an example of when we couldn't follow our rules and disclosure policy was
when we got informed (under NDA) about the Spectre and Meltdown issues (this was
before it was public knowledge). That was considered so sensitive that we
-weren't even allowed to share or discuss this outside Linaro (employees). But in
-general, we strive and try to do our best to follow the rules etc that have been
-defined on this particular page.
+weren't even allowed to share or discuss this outside TrustedFirmware.org. But
+in general, we strive and try to do our best to follow the rules etc that have
+been defined on this particular page.
Receiving information
=====================
@@ -35,33 +35,33 @@
vulnerabilities must follow these rules:
1. The **receiver** of vulnerability information and/or security fixes
- shared by the core team and Linaro are **not allowed** to share,
- re-distribute or otherwise spread knowledge about the issues and security
- fixes outside their own company until the disclosure deadline has passed
- and the information is publicly available.
+ shared by TrustedFirmware.org are **not allowed** to share, re-distribute
+ or otherwise spread knowledge about the issues and security fixes outside
+ their own company until the disclosure deadline has passed and the
+ information is publicly available.
.. note::
If the receiver still insists to share it with other people/companies he
- must first get approval from the core team and Linaro to do so.
+ must first get approval from TrustedFirmware.org to do so.
.. _reporting_issues:
Reporting issues
================
-The one reporting security vulnerabilities to the core team and Linaro are asked
+The one reporting security vulnerabilities to the TrustedFirmware.org are asked
to do it under the conditions mentioned below. It might seem like a long list,
but we hope that it won't scare people away from reporting issues. It's mostly
common sense and also aims to rule out questions that otherwise might come to
-mind. In short, the rules by default gives the core team and Linaro the power to
+mind. In short, the rules by default gives TrustedFirmware.org the power to
decide what to do with the reported issue if nothing else has been agreed
between them and the reporter.
- 1. If nothing else has been agreed between the reporter and the core team
- and Linaro, then the rules and information as stated on this page
- applies.
+ 1. If nothing else has been agreed between the reporter and
+ TrustedFirmware.org, then the rules and information as stated on this
+ page applies.
- 1.1. This means that the core team and Linaro will re-distribute the
+ 1.1. This means that the TrustedFirmware.org will re-distribute the
information to the stakeholders according to the plan described further
down here.
@@ -70,16 +70,16 @@
reporter after initial investigation.
2. By default, the information about the reported issue(s) will be shared
- within the core team (see the note about the core team at the beginning
- of the page). If you as a reporter **aren't** OK with that, then you must
- inform us about that when reporting the issue.
+ within TrustedFirmware.org and a vetted list of stakeholders. If you as a
+ reporter **aren't** OK with that, then you must inform us about that when
+ reporting the issue.
- 3. By default, the core team and Linaro decides whether there should be a
- CVE created or not. If the reporter insist on having a CVE created, then
- this should be expressed when doing the reporting.
+ 3. By default, the TrustedFirmware.org decides whether there should be a CVE
+ created or not. If the reporter insist on having a CVE created, then this
+ should be expressed when doing the reporting.
- 4. The core team and Linaro have the rights to involve other experts to help
- us with mitigations and patches. If you as a reporter **aren't** OK with
+ 4. TrustedFirmware.org have the rights to involve other experts to help us
+ with mitigations and patches. If you as a reporter **aren't** OK with
that, then you must inform us about that when reporting the issue.
5. Reporting security issues under NDA should be seen as a last resort
@@ -93,10 +93,10 @@
Trusted Stakeholders
********************
-The core team keeps track of companies and maintainers who are considered as
-trustworthy OP-TEE users. This is a vetted list and people from companies can
-only be added to that list after first talking to the core team. In short what
-is required to be added to that list is:
+TrustedFirmware.org keeps track of companies and maintainers who are considered
+as trustworthy OP-TEE users. This is a vetted list and people from companies can
+only be added to that list after first talking to TrustedFirmware.org. In short
+what is required to be added to that list is:
- A justification of why you need to know about security issues and should
have access to security fixes before they are going public.
@@ -107,7 +107,7 @@
- You accept our disclosure policy rules (as described at here).
.. note::
- The core team and Linaro have the rights to deny anyone to be on this list.
+ The TrustedFirmware.org have the rights to deny anyone to be on this list.
We also have the rights to remove people on the list if there should be a
reason to do so.
@@ -126,7 +126,7 @@
'medium' (see :ref:`severity_table` below), we have the rights to decide whether
to upstream patches as soon as they are ready. If the reporter or the some of
the trustworthy stakeholders knowing about the security issue disagrees, then
-they must inform the core team and Linaro about it as soon as possible and then
+they must inform the TrustedFirmware.org about it as soon as possible and then
we will come up with an alternate plan.
0day exploits
diff --git a/general/releases.rst b/general/releases.rst
index bf17109..df27a1f 100644
--- a/general/releases.rst
+++ b/general/releases.rst
@@ -8,10 +8,6 @@
Cadence
*******
New versions of OP-TEE are released four times a year, i.e., quarterly releases.
-The releases have historically lined up with Linaro Connect events. I.e., a
-release has been made right after Linaro Connect and one release somewhere
-between two Linaro Connects. I.e., typically there has been releases in January,
-April, July and October.
.. _releases_changelog: