Initial commit for the official OP-TEE documentation
This initial commit brings in all existing documentation found across
various gits making up the documentation for the OP-TEE project. So in
summary what this includes and what has been done is:
- Import all old documentation (optee_os, optee_client, optee_test and
so on).
- Convert everything from markdown (*.md) to reStructuredText (*.rst).
- Add a couple of new pages (optee_docs, disclosure policy to name a
few).
- Add Sphinx configuration.
- Add Travis configuration to enable automatic testing of future
documentation patches.
- Finally, a general clean-up and verification of content,
links as well as verification of build instructions etc has also been
done.
diff --git a/general/about.rst b/general/about.rst
new file mode 100644
index 0000000..fa8f56e
--- /dev/null
+++ b/general/about.rst
@@ -0,0 +1,90 @@
+############
+About OP-TEE
+############
+OP-TEE is a Trusted Execution Environment (TEE) designed as companion to a
+non-secure Linux kernel running on Arm; Cortex-A cores using the TrustZone
+technology. OP-TEE implements :ref:`tee_internal_core_api` v1.1.x which is the
+API exposed to Trusted Applications and the :ref:`tee_client_api` v1.0, which is
+the API describing how to communicate with a TEE. Those APIs are defined in the
+:ref:`globalplatform_api` specifications.
+
+The non-secure OS is referred to as the Rich Execution Environment (REE) in TEE
+specifications. It is typically a Linux OS flavor as a GNU/Linux distribution or
+the AOSP.
+
+OP-TEE is designed primarily to rely on the Arm TrustZone technology as the
+underlying hardware isolation mechanism. However, it has been structured to be
+compatible with any isolation technology suitable for the TEE concept and goals,
+such as running as a virtual machine or on a dedicated CPU.
+
+The main design goals for OP-TEE are:
+
+ - **Isolation** - the TEE provides isolation from the non-secure OS and
+ protects the loaded Trusted Applications (TAs) from each other using
+ underlying hardware support,
+
+ - **Small footprint** - the TEE should remain small enough to reside in a
+ reasonable amount of on-chip memory as found on Arm based systems,
+
+ - **Portability** - the TEE aims at being easily pluggable to different
+ architectures and available HW and has to support various setups such as
+ multiple client OSes or multiple TEEs.
+
+
+OP-TEE components
+*****************
+OP-TEE is divided in various components:
+
+ - A secure privileged layer, executing at Arm secure PL-1 (v7-A) or EL-1
+ (v8-A) level.
+ - A set of secure user space libraries designed for Trusted Applications
+ needs.
+ - A Linux kernel TEE framework and driver (merged to the official tree in
+ v4.12).
+ - A Linux user space library designed upon the GlobalPlatform
+ :ref:`tee_client_api` specifications.
+ - A Linux user space supplicant daemon (tee-supplicant) responsible for
+ remote services expected by the TEE OS.
+ - A test suite (xtest), for doing regression testing and testing the
+ consistency of the API implementations.
+ - An example git containing a couple of simple host- and TA-examples.
+ - And some build scripts, debugging tools to ease its integration and the
+ development of Trusted Applications and secure services.
+
+These components are available from several git repositories. The main ones are
+:ref:`build`, :ref:`optee_os`, :ref:`optee_client`, :ref:`optee_test`,
+:ref:`optee_examples` and the :ref:`linux_kernel`.
+
+History
+*******
+OP-TEE was initially developed by ST-Ericsson (and later on by
+STMicroelectronics), but this was before OP-TEE got the name "OP-TEE" and was
+turned into an open source project. Back then it was a closed source and a
+proprietary TEE project. In 2013, ST-Ericsson obtained GlobalPlatform’s
+compliance qualification with this implementation, proving that the APIs were
+behaving as expected according to the GlobalPlatform specifications.
+
+Later on the same year (2013) Linaro was about to form Security Working Group
+(SWG) and one of the initial key tasks for SWG was to work on an open source
+TEE project. After talking to various TEE vendors Linaro ended up working with
+STMicroelectronics TEE project. But before being able to open source it there
+was a need to replace some proprietary components with open source components.
+For a couple of months Linaro/SWG together with engineers from
+STMicroelectronics re-wrote major parts (crypto library, secure monitor, build
+system etc), cleaned up the project by enforcing :ref:`coding_standards`,
+running checkpatch_ etc.
+
+June 12 2014 was the day when OP-TEE was "born" as an open source project. At
+that day the OP-TEE team pushed the `first commit
+<https://github.com/OP-TEE/optee_os/commit/b01047730e77127c23a36591643eeb8bb0487d68>`_
+to GitHub. A bit after this Linaro also made a `press release
+<https://www.linaro.org/blog/op-tee-open-source-security-mass-market/>`_ about
+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.
+
+.. _checkpatch: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/scripts/checkpatch.pl
diff --git a/general/coding_standards.rst b/general/coding_standards.rst
new file mode 100644
index 0000000..88fd5c3
--- /dev/null
+++ b/general/coding_standards.rst
@@ -0,0 +1,37 @@
+.. _coding_standards:
+
+Coding standards
+################
+
+In this project we are trying to adhere to the same coding convention as used
+in the Linux kernel (see CodingStyle_). We achieve this by running
+checkpatch_ from Linux kernel. However there are a few exceptions that we had
+to make since the code also follows GlobalPlatform standards. The exceptions
+are as follows:
+
+ 1. **CamelCase** for GlobalPlatform types is allowed.
+
+ 2. We **do not** run checkpatch on third party code that we might use in
+ this project, such as LibTomCrypt, MPA, newlib etc. The reason for that
+ and not doing checkpatch fixes for third party code is because we would
+ probably deviate too much from upstream and therefore it would be hard to
+ rebase against those projects later on and we don't expect that it is
+ easy to convince other software projects to change coding style.
+
+ 3. **All** variables **shall be** initialized to a well known value in one
+ or another way. The reason for that is that we have had potential
+ security issues in the past that originated from not having variables
+ initialized with a well defined value. We have also investigate various
+ toolchain flags that are supposed to help out finding uninitialized
+ variables. Unfortunately our conclusion is that you cannot trust the
+ compilers here, since there are corner cases where compilers cannot
+ reliably give a warning.
+
+Regarding the checkpatch tool, it is not included directly into this project.
+Please use checkpatch.pl from the Linux kernel git in combination with the local
+`checkpatch script`_.
+
+.. _checkpatch script: https://github.com/OP-TEE/optee_os/blob/master/scripts/checkpatch.sh
+.. _checkpatch: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/scripts/checkpatch.pl
+.. _CodingStyle: https://www.kernel.org/doc/html/latest/process/coding-style.html
+.. _repository-structure: fixme::after-sphinks-updates
diff --git a/general/contact.rst b/general/contact.rst
new file mode 100644
index 0000000..eb20037
--- /dev/null
+++ b/general/contact.rst
@@ -0,0 +1,69 @@
+.. _contact:
+
+#######
+Contact
+#######
+
+GitHub
+******
+Our preference is to use GitHub for communication. The reason for that is that
+it is an open source project, so there should be no real reason to hide
+discussions from other people. GitHub also makes it possible for anyone to chime
+in into discussion etc. So besides sending patches as pull requests on GitHub we
+also encourage people to use the "issues_" to report bugs, give suggestions, ask
+questions etc.
+
+Please try to use the "issues" in the relevant git. I.e., if you want to discuss
+something related to optee_client, then use "issues" at :ref:`optee_client` and
+so on. If you have a general question etc about OP-TEE that doesn't really
+belong to a specific git, then please use `issues at optee_os`_ in that case.
+
+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.
+
+For pure Linux kernel patches, please use the appropriate Linux kernel
+mailinglist, basically run the ``get_maintainer.pl`` script in the Linux kernel
+tree to figure out where to send your patches.
+
+.. code-block:: bash
+
+ $ cd <linux-kernel>
+ $ ./scripts/get_maintainer.pl drivers/tee/
+
+
+IRC
+***
+Some of the OP-TEE developers can be reached at Freenode (``chat.freenode.net``)
+at channel ``#linaro-security``. Having that said, the activity there is a bit
+limited, so it is probably **not** the best place to discuss OP-TEE.
+
+.. _vulnerability_reporting:
+
+Vulnerability reporting
+***********************
+Please send an email to the address mentioned above (**not** to TEE-dev). Don't
+include any details at this point, just mention that you'd like to report a
+security issue. An engineer from the core OP-TEE team will get back to you for
+further communication and discussions about your findings. Please also read the
+:ref:`disclosure_policy` page and especially the :ref:`reporting_issues`
+section, so you are aware of the rules we are following.
+
+.. _core_team:
+
+Core Team
+*********
+The core team consists of engineers from Linaro and engineers from Linaro's
+member companies. 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/contribute.rst b/general/contribute.rst
new file mode 100644
index 0000000..54a1935
--- /dev/null
+++ b/general/contribute.rst
@@ -0,0 +1,201 @@
+.. _contribute:
+
+##########
+Contribute
+##########
+Contributions to OP-TEE are managed by the OP-TEE :ref:`core_team` and anyone
+can contribute to OP-TEE as long as it is understood that it will require a
+`Signed-off-by` tag from the one submitting the patch(es). The Signed-off-by tag
+is a simple line at the end of the explanation for the patch, which certifies
+that you wrote it or otherwise have the right to pass it on as an open source
+patch (see below). You thereby assure that you have read and are following the
+rules stated in the ``Developer Certificate of Origin`` as stated below.
+
+.. _DCO:
+
+Developer Certificate of Origin
+*******************************
+
+.. code-block:: none
+
+ Developer Certificate of Origin
+ Version 1.1
+
+ Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
+ 660 York Street, Suite 102,
+ San Francisco, CA 94110 USA
+
+ Everyone is permitted to copy and distribute verbatim copies of this
+ license document, but changing it is not allowed.
+
+
+ Developer's Certificate of Origin 1.1
+
+ By making a contribution to this project, I certify that:
+
+ (a) The contribution was created in whole or in part by me and I
+ have the right to submit it under the open source license
+ indicated in the file; or
+
+ (b) The contribution is based upon previous work that, to the best
+ of my knowledge, is covered under an appropriate open source
+ license and I have the right under that license to submit that
+ work with modifications, whether created in whole or in part
+ by me, under the same open source license (unless I am
+ permitted to submit under a different license), as indicated
+ in the file; or
+
+ (c) The contribution was provided directly to me by some other
+ person who certified (a), (b) or (c) and I have not modified
+ it.
+
+ (d) I understand and agree that this project and the contribution
+ are public and that a record of the contribution (including all
+ personal information I submit with it, including my sign-off) is
+ maintained indefinitely and may be redistributed consistent with
+ this project or the open source license(s) involved.
+
+We have borrowed this procedure from the Linux kernel project to improve
+tracking of who did what, and for legal reasons.
+
+To sign-off a patch, just add a line in the commit message saying:
+
+.. code-block:: none
+
+ Signed-off-by: Random J Developer <random@developer.example.org>
+
+Use your real name or on some rare cases a company email address, but we
+disallow pseudonyms or anonymous contributions.
+
+GitHub
+******
+This section describes how to use GitHub for OP-TEE development and
+contributions.
+
+Setting up an account
+=====================
+You do not need to own a GitHub account in order to clone a repository. But if
+you want to contribute, you need to create an account at GitHub_. Note that a
+free plan is sufficient to collaborate.
+
+SSH is recommended to access your GitHub repositories securely and without
+supplying your username and password each time you pull or push something.
+To configure SSH for GitHub, please refer to `Connecting to GitHub with SSH`_.
+
+Forking
+=======
+Only owners of the OP-TEE projects have write permissions to the git
+repositories of those projects. Contributors **should fork** ``OP-TEE/*.git``
+and/or ``linaro-swg/*.git`` into their own account, then work on this forked
+repository. The complete documentation about **forking** can be found at `fork a
+repo`_.
+
+Creating pull requests
+======================
+When you want to submit a patch to the OP-TEE project, you are supposed to
+create a `pull request`_ to the git where you forked your git from. How that is
+done using GitHub is explained at the GitHub `pull request`_ page.
+
+Commit messages
+===============
+
+ - The **subject line** should explain **what** the patch does as precisely
+ as possible. It is usually prefixed with keywords indicating which part of
+ the code is affected, but not always. Avoid lines longer than 80
+ characters.
+
+ - The **commit description** should give more details on **what** is
+ changed, and explain **why** it is done. Indication on how to enable and
+ use some particular feature can be useful, too. Try to limit line length
+ to 72 characters, except when pasting some error message (compiler
+ diagnostic etc.). Long lines are allowed to accommodate URLs, too
+ (preferably use URLs in a Fixes: or Link: tag).
+
+ - The commit message **must** end with a blank line followed by some tags,
+ including your ``Signed-off-by:`` tag. By applying such a tag to your
+ commit, you are effectively declaring that your contribution follows the
+ terms stated by :ref:`DCO` (in the DCO section there is also a complete
+ example).
+
+ - Other tags may be used, such as:
+
+ - ``Tested-by: Test R <test@r.com>``
+ - ``Acked-by: Acke R <acke@r.com>``
+ - ``Suggested-by: Suggeste R <suggeste@r.com>``
+ - ``Reported-by: Reporte R <reporte@r.com>``
+
+ - When citing a previous commit, whether it is in the text body or in a
+ Fixes: tag, always use the format shown above (12 hexadecimal digits
+ prefix of the commit ``SHA1``, followed by the commit subject in double
+ quotes and parentheses).
+
+Review feedback
+===============
+It is very likely that you will get review comments from other OP-TEE users
+asking you to fix certain things etc. When fixing review comments, do:
+
+ - **Add** `fixup` patches on **top** of your existing branch. **Do not**
+ squash and force push while fixing review comments.
+
+ - When all comments have been addressed, just write a simple messages in the
+ comments field saying something like "All comments have been addressed".
+ By doing so you will notify the maintainers that the fix might be ready
+ for review again.
+
+Finalizing your contribution
+============================
+Once you and reviewers have agreed on the patch set, which is when all the
+people who have commented on the pull request have given their ``Acked-by:`` or
+``Reviewed-by:``, you need to consolidate your commits:
+
+Use ``git rebase -i`` to squash the fixup commits (if any) into the initial
+ones. For instance, suppose the ``git log --oneline`` for you contribution looks
+as follows when the review process ends:
+
+.. code-block:: none
+
+ <sha1-commit4> [Review] Do something
+ <sha1-commit3> [Review] Do something
+ <sha1-commit2> Do something else
+ <sha1-commit1> Do something
+
+Then you would do:
+
+.. code-block:: bash
+
+ $ git rebase -i <sha1-commit1>^
+
+Edit the commit script so it looks like so:
+
+.. code-block:: none
+
+ pick <sha1-commit1> Do something
+ squash <sha1-commit3> [Review] Do something
+ squash <sha1-commit4> [Review] Do something
+ pick <sha1-commit2> Do something else
+
+Add the proper tags (``Acked-by: ...``, ``Reviewed-by: ...``, ``Tested-by:
+...``) to the commit message(s) for each and every commit as provided by the
+people who reviewed and/or tested the patches.
+
+.. hint::
+
+ ``git commit --fixup=<sha1-of-commit-to-fix>`` and later on ``git rebase -i
+ --autosquash <sha1-of-first-commit-in-patch-serie>^1`` is pretty convenient
+ to use when adding review patches and doing the final squash operation.
+
+Once ``rebase -i`` is done, you need to force-push (``-f``) to your GitHub
+branch in order to update the pull request page.
+
+.. code-block:: bash
+
+ $ git push -f <my-remote> <my-branch>
+
+After completing this it is the project maintainers job to apply your patches to
+the master branch.
+
+.. _fork a repo: https://help.github.com/articles/fork-a-repo
+.. _GitHub: https://github.com
+.. _Connecting to GitHub with SSH: https://help.github.com/articles/connecting-to-github-with-ssh
+.. _pull request: https://help.github.com/articles/creating-a-pull-request
+
diff --git a/general/disclosure.rst b/general/disclosure.rst
new file mode 100644
index 0000000..c13d7a9
--- /dev/null
+++ b/general/disclosure.rst
@@ -0,0 +1,529 @@
+.. _disclosure_policy:
+
+#################
+Disclosure policy
+#################
+When a vulnerability has been reported (see :ref:`vulnerability_reporting`) to
+the :ref:`core_team`, it is up to them to implement mitigations and fixes as
+well as report back to stakeholders in a responsible way. This page describes
+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.
+
+Rules
+*****
+To have some kind of ground to stand on we have defined a set of rules and
+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.
+
+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.
+
+Receiving information
+=====================
+The one receiving information about and fixes related to OP-TEE security
+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.
+
+ .. 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.
+
+.. _reporting_issues:
+
+Reporting issues
+================
+The one reporting security vulnerabilities to the core team and Linaro 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
+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.1. This means that the core team and Linaro will re-distribute the
+ information to the stakeholders according to the plan described further
+ down here.
+
+ 1.2. This also means that patches etc will be submitted to the upstream
+ project based on the proposed disclosure day that will be given to the
+ 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.
+
+ 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.
+
+ 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
+ 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
+ thing. If/when that happens, then we will come up with a mutual agreement
+ on a disclosure plan.
+
+ 6. It is appreciated if the reporter have estimated some initial severity
+ scoring as described further down on this page. This is mainly to get an
+ indication whether we share the same view about the severity or not.
+
+
+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:
+
+ - A justification of why you need to know about security issues and should
+ have access to security fixes before they are going public.
+
+ - A company email address (we do not accept gmail, yahoo and similar
+ addresses).
+
+ - 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.
+ We also have the rights to remove people on the list if there should be a
+ reason to do so.
+
+Disclosure deadline
+*******************
+By default we are following the industry standard with 90-days disclosure
+deadline. This applies both when **we** find security issues that needs to be
+fixed in the upstream project, as well as when we are the ones reporting issues
+found in vendor trees (forks of OP-TEE). The reason for 90-days is to give
+companies enough time to patch and deploy updated software to their devices.
+
+Likewise we are going to propose a 90-days disclosure deadline for issues that
+are being reported to us, that we are supposed to fix.
+
+However, for issues that falls in the severity category 'low' and in some cases
+'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
+we will come up with an alternate plan.
+
+0day exploits
+=============
+This is a previously unknown and unpatched vulnerability which is been used
+actively in the wild. As a consequence of that we believe that 0day_ exploits
+require a much more urgent action. I.e., a fix or some kind of mitigation that
+limits the damage needs to be created as soon as possible. Our target for such
+fixes and mitigations are within 14 days from the day when we learned about the
+0day exploit (full weeks, including weekends).
+
+Issue process
+*************
+For **regular** security issues (non 0day) we follow the flow chart below. Note
+that the orange path is when it is a **low** (and maybe medium) severity issue
+we are dealing with, so that is a special case with an alternate path.
+
+.. graphviz::
+
+ digraph issue_process {
+ start [label="Issue reported\nDay 1\n90 day counter starts", shape="box", style=rounded];
+ end [label="Day 90", shape="box", style=rounded];
+ create [label="Create mitigations"];
+ inform [label="Inform stakeholders"];
+ patch_ready [label="Patch ready"];
+ go_public [label="Update security advisories"];
+ upstream_fixes [label="Upstream Fixes"];
+ medhigh_prio [label="Severity >= Low/Medium?", shape="parallelogram"];
+ create_cve [label="Create CVE"];
+ update_cve [label="Update CVE\n(if created)"];
+
+
+ start -> create;
+ start -> inform;
+
+ create -> medhigh_prio;
+ medhigh_prio -> create_cve [label="Yes"];
+ medhigh_prio -> upstream_fixes [label="No", color="orange"];
+
+ create -> patch_ready;
+ patch_ready -> inform [label="Share fixes"];
+ patch_ready -> end;
+ patch_ready -> medhigh_prio [label="Check if patch should go upstream directly", color="orange"];
+
+ end -> inform;
+ end -> go_public;
+ end -> upstream_fixes;
+ end -> update_cve;
+ }
+
+For **0day** exploits we follow this flow chart:
+
+.. graphviz::
+
+ digraph issue_process {
+ start [label="\0day issue reported\nDay 1\n14 day counter starts", shape="box", style=rounded];
+ end [label="Day 14", shape="box", style=rounded];
+ create [label="Create mitigations"];
+ inform [label="Inform stakeholders"];
+ patch_ready [label="Patch ready"];
+ go_public [label="Update security advisories"];
+ upstream_fixes [label="Upstream Fixes"];
+ medhigh_prio [label="Severity >= Medium?", shape="parallelogram"];
+ create_cve [label="Create CVE"];
+ update_cve [label="Update CVE"];
+
+ start -> create;
+ start -> inform;
+
+ create -> medhigh_prio;
+ medhigh_prio -> create_cve [label="Yes"];
+
+ create -> patch_ready;
+ patch_ready -> inform [label="Share fixes"];
+ patch_ready -> end;
+
+ end -> inform;
+ end -> go_public;
+ end -> upstream_fixes;
+ end -> update_cve;
+ }
+
+
+Recognition
+***********
+Once the disclosure deadline has passed and information and mitigations will go
+public we want to give credits to the ones finding, reporting and fixing the
+issues. Typically that is given in two ways. One is in textual form at our
+`security advisories`_ page and the other way is directly in patches applied on
+the upstream project in questions.
+
+For patches we prefer having a real physical person being mentioned (see
+*Reported-by* and *Suggested-by* in the example below), but also a company name
+or group could be used if it was a joint effort finding the security issue or if
+the person finding the issue prefer not being mentioned directly for some
+reason. A patch would typically look like this:
+
+.. code-block:: none
+ :emphasize-lines: 11,12
+
+ core: fixes privilege escalation
+
+ By doing X, one was able to exploit a privilege escalation
+ vulnerability. By changing Y this is no longer a security
+ issue.
+
+ Fixes CVE-20xx-YYYY
+
+ Signed-off-by: John Doe <john.doe@foobar.org>
+ Reviewed-by: Richard Roe <richard.roe@foobar.org>
+ Reported-by: Jane Doe <jane.doe@notable-hackers.com>
+ Suggested-by: Jane Doe <jane.doe@notable-hackers.com>
+
+CVE
+***
+If there is a need to request a CVE identifier, then the `Distributed Weakness
+Filing Project`_ should be used. At that page you will find the current link to
+the DWF project.
+
+Severity scoring
+****************
+When deciding the severity for a vulnerability we start out by doing a scoring
+similar to the DREAD_ scoring system, but tweaked for OP-TEE purposes. This
+mainly serves as a guide to get some kind of indication of the severity. The
+final severity is decided on case by case basis.
+
+.. note::
+ A DREAD score can change over time. The initial analysis could give a
+ certain score, but later on when a vulnerability is well known and exploits
+ are readily available the score will be different (ususally more severe).
+
+**Damage Potential**
+
+This should give an answer to much damage is caused if the vulnerability is
+exploited.
+
+.. list-table::
+ :widths: 1 20
+ :header-rows: 1
+
+ * - Score
+ - Damange potential
+
+ * - 0
+ - No damage.
+
+ * - 1
+ - Normal World User space is compromised and could leak sensitive data.
+
+ * - 1
+ - Denial of service from Normal World.
+
+ * - 2
+ - Normal World Linux kernel space is compromised and could leak sensitive
+ data.
+
+ * - 5
+ - TEE Trusted Application compromised and could leak data only accessible
+ by the Trusted Application.
+
+ * - 7
+ - TEE core (kernel space) compromised and leaking trivial information.
+
+ * - 9
+ - TEE core (kernel space) compromised and leaking sensitive information.
+
+ * - 10
+ - TEE fully compromised and the attacker in full control.
+
+**Reproducibility**
+
+This describes how easy (or hard) it is to reproduce the attack.
+
+.. list-table::
+ :widths: 1 20
+ :header-rows: 1
+
+ * - Score
+ - Reproducibility
+
+ * - 0
+ - Not reproducible.
+
+ * - 1
+ - No proven attack exists.
+
+ * - 1
+ - The attack is very difficult to reproduce, even with knowledge of the
+ security hole (requires special lab equipment for example)
+
+ * - 2
+ - Proof of concept attack exists, but only works in a specially crafted,
+ non-standard configuration.
+
+ * - 4
+ - The attack can be reproduced, but only with tooling / software /
+ knowledge that has **not** been made public (typically the one finding
+ the security issue have created a tool, which hasn't been released yet).
+
+ * - 9
+ - The attack can be reproduced, but only with tooling (JTAG,
+ ChipWhisperer_ etc) / software / knowledge that is readily available to
+ anyone.
+
+ * - 10
+ - The attack can be reproduced every time by a novice user without any
+ need for extra tools.
+
+**Exploitability**
+
+This should answer how easy it is to launch an attack.
+
+.. list-table::
+ :widths: 1 20
+ :header-rows: 1
+
+ * - Score
+ - Exploitability
+
+ * - 0
+ - Not exploitable.
+
+ * - 1
+ - Theoretically exploitable (even with knowledge, there seems to be no
+ viable path for a real exploit).
+
+ * - 7
+ - Only authenticated user(s) can make the attack.
+
+ * - 8
+ - A skilled programmer with in-depth knowledge could make the attack.
+
+ * - 9
+ - A novice programmer could make the attack in a short time.
+
+ * - 10
+ - A novice user could make the attack in a short time (exploits readily
+ available on internet and/or integrated in known hacker/pen-testing
+ tools).
+
+**Affected Users**
+
+This should give a rough answer to how many people are affected by a successful
+attack.
+
+.. list-table::
+ :widths: 1 20
+ :header-rows: 1
+
+ * - Score
+ - Affected Users
+
+ * - 0
+ - No users affected.
+
+ * - 1
+ - All users, running a debug/developer configuration.
+
+ * - 1
+ - A single user.
+
+ * - 10
+ - All users, running a release configuration (key customers).
+
+**Discoverability**
+
+This should answer how easy it is to discover the threat.
+
+.. list-table::
+ :widths: 1 20
+ :header-rows: 1
+
+ * - Score
+ - Discoverability
+
+ * - 0
+ - Not discoverable.
+
+ * - 1
+ - The vulnerability would require other successful exploits in order to be
+ able to discover this bug.
+
+ * - 2
+ - The bug is obscure, and it is unlikely that users will work out damage
+ potential.
+
+ * - 5
+ - Information explaining the attack exists, but is only shared with a
+ small group of people (and it is not intended to be shared publicly in a
+ foreseeable time or until mitigations has been merged).
+
+ * - 10
+ - Published information explains the attack.
+
+.. _severity_table:
+
+Severity table
+==============
+Based on the DREAD score, we get some kind of indication of the severity. In the
+table below you can see how we are mapping things between a DREAD score and
+severity.
+
+.. list-table::
+ :widths: 1 4 1 20
+ :header-rows: 1
+
+ * - Severity
+ - Score
+ - CVE?
+ - Comment
+
+ * - No risk
+ - [0, 1)
+ - No CVE created.
+ - This is not considered as a security issue, it's a regular bug.
+
+ * - Low
+ - [1, 4)
+ - No CVE created.
+ - This could be seen as a security issue, but could probably be treated as
+ general bug.
+
+ * - Medium
+ - [4, 7)
+ - Depends.
+ - This is a security issue, but on the lower side of the score it might be
+ treated as a bug. For the higher end it is likely that a CVE will be
+ created.
+
+ * - High
+ - [7, 9)
+ - CVE created.
+ - It is definitely a security issue.
+
+ * - Critical
+ - [9, 10]
+ - CVE created.
+ - It is definitely a security issue, very urgent to start working with
+ mitigations etc.
+
+
+Example
+=======
+To have a better understanding how this would look like in practice, let's show
+a couple of examples.
+
+**Example 1** - Spectre v2 - Branch Target Injection (CVE-2017-5715_)
+
+Note that this example should be seed from a TrustZone / TEE point of view.
+
+ - **D**: What damage could it cause?
+ - TEE leaking sensitive data, i.e., 9.
+
+ - **R**: Easy to reproduce?
+ - No proven attack exists on TrustZone/TEE software, i.e, 1.
+
+ - **E**: Easy to launch the attack?
+ - Theoretically exploitable, i.e., 1
+
+ - **A**: How many users would be affected by a successful attack?
+ - All users, i.e., 10.
+
+ - **D**: How easy is it to discover this issue?
+ - It's public information, i.e., 10.
+
+This gives the score: (9 + 1 + 1 + 10 + 10) / 5 = **6.2** which *indicates* that
+this would a bit on the higher end of medium severity.
+
+**Example 2** - Bellcore attack on OP-TEE (CVE-2017-1000412_)
+
+ - **D**: What damage could it cause?
+ - TEE leaking sensitive data (private key used to sign and verify
+ Trusted Applications), i.e., 9.
+
+ - **R**: Easy to reproduce?
+ - With a ChipWhisperer_ (readily available) it would be possible for a
+ somewhat skilled engineer to do this on their own on a device running
+ OP-TEE, i.e., 9.
+
+ - **E**: Easy to launch the attack?
+ - A skilled engineer with in-depth knowledge could make the attack, i.e., 8.
+
+ - **A**: How many users would be affected by a successful attack?
+ - All users, i.e., 10.
+
+ - **D**: How easy is it to discover this issue?
+ - It's public information, i.e., 10.
+
+This gives the score: (9 + 9 + 8 + 10 + 10) / 5 = **9.2** which *indicates* that
+this would be a critical issue.
+
+
+.. _0day: https://en.wikipedia.org/wiki/Zero-day_(computing)
+.. _ChipWhisperer: https://newae.com/tools/chipwhisperer/
+.. _core team: https://github.com/orgs/OP-TEE/teams/linaro/members
+.. _Distributed Weakness Filing Project: https://cve.mitre.org/cve/request_id.html
+.. _DREAD: https://wiki.openstack.org/wiki/Security/OSSA-Metrics#DREAD
+.. _CVE-2017-5715: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5715
+.. _CVE-2017-1000412: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000412
+.. _security advisories: https://www.op-tee.org/security-advisories/
diff --git a/general/index.rst b/general/index.rst
new file mode 100644
index 0000000..20f52a2
--- /dev/null
+++ b/general/index.rst
@@ -0,0 +1,17 @@
+Getting started
+###############
+This contains general information about OP-TEE, how to get in contact, how to
+contribute, how to report security issues etc. It is intended for people who are
+new to OP-TEE.
+
+.. toctree::
+ :maxdepth: 2
+
+ about
+ coding_standards
+ contribute
+ contact
+ disclosure
+ license_headers
+ platforms
+ presentations
diff --git a/general/license_headers.rst b/general/license_headers.rst
new file mode 100644
index 0000000..bff7290
--- /dev/null
+++ b/general/license_headers.rst
@@ -0,0 +1,52 @@
+.. todo::
+
+ Joakim: Move this under porting guidelines instead?
+
+.. _license_headers:
+
+###############
+License headers
+###############
+This document defines the format of the copyright and license headers in OP-TEE
+source files. Such headers shall comply with the rules described here, which are
+compatible with the rules adopted by the Linux kernel community.
+
+New source files
+****************
+
+ - **Rule 1.1** Shall contain exactly one SPDX license identifier, which can
+ express a single or multiple licenses (refer to SPDX_ for syntax details).
+
+ - **Rule 1.2** The SPDX license identifier shall be added as a comment line.
+ It shall be the first possible line in the file which can contain a
+ comment. The comment style shall depend on the file type:
+
+ - **Rule 1.2.1** C source: ``// SPDX-License-Identifier: <expression>``
+ - **Rule 1.2.2** C header: ``/* SPDX-License-Identifier: <expression> */``
+ - **Rule 1.2.3** Assembly: ``/* SPDX-License-Identifier: <expression> */``
+ - **Rule 1.2.4** Python, shell: ``# SPDX-License-Identifier: <expression>``
+
+ - **Rule 1.3** Shall contain at least one copyright line
+
+ - **Rule 1.4** Shall not contain the mention 'All rights reserved'
+
+ - **Rule 1.5** Shall not contain any license notice other than the SPDX license
+ identifier
+
+Note that files imported from external projects are not new files. The rules for
+pre-existing files (below) apply.
+
+Pre-existing or imported files
+******************************
+
+ - **Rule 2.1** SPDX license identifiers shall be added according to the
+ license notice(s) in the file and the rules above (1.1 and 1.2*)
+
+ - **Rule 2.2** It is recommended that license notices be removed once the
+ corresponding identifier has been added. Note however that this may only
+ be done by the copyright holder(s) of the file.
+
+ - **Rule 2.3** Similar to 2.2, and subject to the same conditions, the text:
+ "All rights reserved" shall be removed also.
+
+.. _SPDX: https://spdx.org/licenses/
diff --git a/general/platforms.rst b/general/platforms.rst
new file mode 100644
index 0000000..3786a94
--- /dev/null
+++ b/general/platforms.rst
@@ -0,0 +1,251 @@
+.. todo::
+
+ Joakim: Feels like this page is a bit malplaced in the structure. Maybe we
+ should create a separate "main-section" for this?
+
+.. _platforms_supported:
+
+###################
+Platforms supported
+###################
+Several platforms are supported. In order to manage slight differences between
+platforms, a ``PLATFORM_FLAVOR`` flag has been introduced. The ``PLATFORM`` and
+``PLATFORM_FLAVOR`` flags define the whole configuration for a chip the where
+the Trusted OS runs. Note that there is also a composite form which makes it
+possible to append ``PLATFORM_FLAVOR`` directly, by adding a dash in-between the
+names. The composite form is shown below for the different boards. For more
+specific details about build flags etc, please read
+:ref:`configuration_and_flags`. Some platforms have different sub-maintainers,
+please refer to the file MAINTAINERS_ for contact details for various platforms.
+
+.. Please keep this list sorted in alphabetic order
+
+.. list-table:: Platforms officially supported in OP-TEE
+ :header-rows: 1
+
+ * - Platform
+ - Composite PLATFORM flag
+ - Publicly available?
+ - Maintained?
+
+ * - `ARM Juno Board <http://www.arm.com/products/tools/development-boards/versatile-express/juno-arm-development-platform.php>`_
+ - ``PLATFORM=vexpress-juno``
+ - Yes
+ - Yes
+
+ * - `Atmel ATSAMA5D2-XULT Board <http://www.atmel.com/tools/atsama5d2-xult.aspx>`_
+ - ``PLATFORM=sam``
+ - Yes
+ - Yes
+
+ * - `DeveloperBox (Socionext Synquacer SC2A11) <https://www.96boards.org/product/developerbox/>`_
+ - ``PLATFORM=synquacer``
+ - Yes
+ - Yes
+
+ * - `FSL ls1021a <http://www.freescale.com/tools/embedded-software-and-tools/hardware-development-tools/tower-development-boards/mcu-and-processor-modules/powerquicc-and-qoriq-modules/qoriq-ls1021a-tower-system-module:TWR-LS1021A?lang_cd=en>`_
+ - ``PLATFORM=ls-ls1021atwr``
+ - Yes
+ - Yes
+
+ * - `NXP ls1043ardb <http://www.nxp.com/products/microcontrollers-and-processors/power-architecture-processors/qoriq-platforms/developer-resources/qoriq-ls1043a-reference-design-board:LS1043A-RDB>`_
+ - ``PLATFORM=ls-ls1043ardb``
+ - Yes
+ - Yes
+
+ * - `NXP ls1046ardb <http://www.nxp.com/products/microcontrollers-and-processors/power-architecture-processors/qoriq-platforms/developer-resources/qoriq-ls1046a-reference-design-board:LS1046A-RDB>`_
+ - ``PLATFORM=ls-ls1046ardb``
+ - Yes
+ - Yes
+
+ * - `NXP ls1012ardb <http://www.nxp.com/products/microcontrollers-and-processors/power-architecture-processors/qoriq-platforms/developer-resources/qoriq-ls1012a-reference-design-board:LS1012A-RDB>`_
+ - ``PLATFORM=ls-ls1012ardb``
+ - Yes
+ - Yes
+
+ * - `NXP ls1088ardb <http://www.nxp.com/products/microcontrollers-and-processors/power-architecture-processors/qoriq-platforms/developer-resources/qoriq-ls1088a-reference-design-board:LS1088A-RDB>`_
+ - ``PLATFORM=ls-ls1088ardb``
+ - Yes
+ - Yes
+
+ * - `NXP ls2088ardb <http://www.nxp.com/products/microcontrollers-and-processors/power-architecture-processors/qoriq-platforms/developer-resources/qoriq-ls2088a-reference-design-board:LS2088A-RDB>`_
+ - ``PLATFORM=ls-ls2088ardb``
+ - Yes
+ - Yes
+
+ * - `NXP ls1012afrwy <https://www.nxp.com/support/developer-resources/software-development-tools/qoriq-developer-resources/layerscape-frwy-ls1012a-board:FRWY-LS1012A>`_
+ - ``PLATFORM=ls-ls1012afrwy``
+ - Yes
+ - Yes
+
+ * - `FSL i.MX6 Quad SABRE Lite Board <https://boundarydevices.com/product/sabre-lite-imx6-sbc/>`_
+ - ``PLATFORM=imx-mx6qsabrelite``
+ - Yes
+ - Yes
+
+ * - `FSL i.MX6 Quad SABRE SD Board <http://www.nxp.com/products/software-and-tools/hardware-development-tools/sabre-development-system/sabre-board-for-smart-devices-based-on-the-i.mx-6quad-applications-processors:RD-IMX6Q-SABRE>`_
+ - ``PLATFORM=imx-mx6qsabresd``
+ - Yes
+ - Yes
+
+ * - `SolidRun i.MX6 Quad Hummingboard Edge <https://www.solid-run.com/product/hummingboard-edge-imx6q-wa-h/>`_
+ - ``PLATFORM=imx-mx6qhmbedge``
+ - Yes
+ - Yes
+
+ * - `SolidRun i.MX6 Dual Hummingboard Edge <https://www.solid-run.com/product/hummingboard-edge-imx6d-wa-h/>`_
+ - ``PLATFORM=imx-mx6dhmbedge``
+ - Yes
+ - Yes
+
+ * - `SolidRun i.MX6 Dual Lite Hummingboard Edge <https://www.solid-run.com/product/hummingboard-edge-imx6dl-0c-h/>`_
+ - ``PLATFORM=imx-mx6dlhmbedge``
+ - Yes
+ - Yes
+
+ * - `SolidRun i.MX6 Solo Hummingboard Edge <https://www.solid-run.com/product/hummingboard-edge-imx6s-wa-h/>`_
+ - ``PLATFORM=imx-mx6shmbedge``
+ - Yes
+ - Yes
+
+ * - `FSL i.MX6 UltraLite EVK Board <http://www.freescale.com/products/arm-processors/i.mx-applications-processors-based-on-arm-cores/i.mx-6-processors/i.mx6qp/i.mx6ultralite-evaluation-kit:MCIMX6UL-EVK>`_
+ - ``PLATFORM=imx-mx6ulevk``
+ - Yes
+ - Yes
+
+ * - `NXP i.MX7Dual SabreSD Board <http://www.nxp.com/products/software-and-tools/hardware-development-tools/sabre-development-system/sabre-board-for-smart-devices-based-on-the-i.mx-7dual-applications-processors:MCIMX7SABRE>`_
+ - ``PLATFORM=imx-mx7dsabresd``
+ - Yes
+ - Yes
+
+ * - `NXP i.MX7Solo WaRP7 Board <http://www.nxp.com/products/developer-resources/reference-designs/warp7-next-generation-iot-and-wearable-development-platform:WARP7>`_
+ - ``PLATFORM=imx-mx7swarp7``
+ - Yes
+ - Yes
+
+ * - `ARM Foundation FVP <https://developer.arm.com/products/system-design/fixed-virtual-platforms>`_
+ - ``PLATFORM=vexpress-fvp``
+ - Yes
+ - Yes
+
+ * - `HiSilicon D02 <http://open-estuary.org/d02-2>`_
+ - ``PLATFORM=d02``
+ - No
+ - Yes
+
+ * - `HiKey Board (HiSilicon Kirin 620) <https://www.96boards.org/product/hikey>`_
+ - ``PLATFORM=hikey` or `PLATFORM=hikey-hikey``
+ - Yes
+ - Yes
+
+ * - `HiKey960 Board (HiSilicon Kirin 960) <https://www.96boards.org/product/hikey960>`_
+ - ``PLATFORM=hikey-hikey960``
+ - Yes
+ - Yes
+
+ * - `Marvell ARMADA 7K Family <http://www.marvell.com/embedded-processors/armada-70xx/>`_
+ - ``PLATFORM=marvell-armada7k8k``
+ - Yes
+ - Yes
+
+ * - `Marvell ARMADA 8K Family <http://www.marvell.com/embedded-processors/armada-80xx/>`_
+ - ``PLATFORM=marvell-armada7k8k``
+ - Yes
+ - Yes
+
+ * - `Marvell ARMADA 3700 Family <http://www.marvell.com/embedded-processors/armada-3700/>`_
+ - ``PLATFORM=marvell-armada3700``
+ - Yes
+ - Yes
+
+ * - `MediaTek MT8173 EVB Board <https://www.mediatek.com/products/tablets/mt8173>`_
+ - ``PLATFORM=mediatek-mt8173``
+ - No
+ - Yes
+
+ * - `Poplar Board (HiSilicon Hi3798C V200) <https://www.96boards.org/product/poplar>`_
+ - ``PLATFORM=poplar``
+ - Yes
+ - Yes
+
+ * - `QEMU <http://wiki.qemu.org/Main_Page>`_
+ - ``PLATFORM=vexpress-qemu_virt``
+ - Yes
+ - Yes
+
+ * - `QEMUv8 <http://wiki.qemu.org/Main_Page>`_
+ - ``PLATFORM=vexpress-qemu_armv8a``
+ - Yes
+ - Yes
+
+ * - `Raspberry Pi 3 <https://www.raspberrypi.org/products/raspberry-pi-3-model-b>`_
+ - ``PLATFORM=rpi3``
+ - Yes
+ - Yes
+
+ * - `Renesas RCAR <https://www.renesas.com/en-sg/solutions/automotive/products/rcar-h3.html>`_
+ - ``PLATFORM=rcar``
+ - No
+ - Yes
+
+ * - `Rockchip RK322X <http://www.rock-chips.com/a/en/products/RK32_Series/2016/1109/799.html>`_
+ - ``PLATFORM=rockchip-rk322x``
+ - No
+ - Yes
+
+ * - `STMicroelectronics b2260 - h410 (96boards fmt) <http://www.st.com/web/en/catalog/mmc/FM131/SC999/SS1628/PF258776>`_
+ - ``PLATFORM=stm-b2260``
+ - No
+ - Yes
+
+ * - `STMicroelectronics b2120 - h310 / h410 <http://www.st.com/web/en/catalog/mmc/FM131/SC999/SS1628/PF258776>`_
+ - ``PLATFORM=stm-cannes``
+ - No
+ - Yes
+
+ * - STMicroelectronics stm32mp1
+ - ``PLATFORM=stm32mp1``
+ - No
+ - Yes
+
+ * - `Allwinner A64 Pine64 Board <https://www.pine64.org/>`_
+ - ``PLATFORM=sunxi-sun50i_a64``
+ - Yes
+ - Yes
+
+ * - `Texas Instruments AM65x <http://www.ti.com/lit/ug/spruid7/spruid7.pdf>`_
+ - ``PLATFORM=k3-am65x``
+ - Yes
+ - Yes
+
+ * - `Texas Instruments DRA7xx <http://www.ti.com/processors/automotive-processors/drax-infotainment-socs/overview.html>`_
+ - ``PLATFORM=ti-dra7xx``
+ - Yes
+ - Yes
+
+ * - `Texas Instruments AM57xx <http://www.ti.com/processors/sitara/arm-cortex-a15/am57x/overview.html>`_
+ - ``PLATFORM=ti-am57xx``
+ - Yes
+ - Yes
+
+ * - `Texas Instruments AM43xx <http://www.ti.com/processors/sitara/arm-cortex-a9/am438x/overview.html>`_
+ - ``PLATFORM=ti-am43xx``
+ - Yes
+ - Yes
+
+ * - `Xilinx Zynq 7000 ZC702 <http://www.xilinx.com/products/boards-and-kits/ek-z7-zc702-g.html>`_
+ - ``PLATFORM=zynq7k-zc702``
+ - Yes
+ - No (v2.3.0)
+
+ * - `Xilinx Zynq UltraScale+ MPSOC <http://www.xilinx.com/products/silicon-devices/soc/zynq-ultrascale-mpsoc.html>`_
+ - ``PLATFORM=zynqmp-zcu102``
+ - Yes
+ - No (v2.4.0)
+
+ * - `Spreadtrum SC9860 <http://spreadtrum.com/en/SC9860GV.html>`_
+ - ``PLATFORM=sprd-sc9860``
+ - No
+ - No (v2.1.0)
+
+.. _MAINTAINERS: https://github.com/OP-TEE/optee_os/blob/master/MAINTAINERS
diff --git a/general/presentations.rst b/general/presentations.rst
new file mode 100644
index 0000000..2390a52
--- /dev/null
+++ b/general/presentations.rst
@@ -0,0 +1,111 @@
+.. _presentations:
+
+Presentations
+#############
+Below are presentations coming from engineers working with OP-TEE in one or
+another way. Note that the older they are, the less relevant is the information
+in them. So do not trust blindly what was said back in the days, cross check
+with latest version to understand whether things have changed or not.
+
+The links are sorted in chronological order, newest first and oldest at the
+end.
+
+ - YVR18
+ - YVR18-414 - Keymaster and Gatekeeper
+ (`slides <https://s3.amazonaws.com/connect.linaro.org/yvr18/presentations/yvr18-414.pdf>`__,
+ `video <https://youtu.be/UR3io1uCkdo>`__)
+
+ - YVR18-117 - SWG updates since HKG18
+ (`slides <https://s3.amazonaws.com/connect.linaro.org/yvr18/presentations/yvr18-117.pdf>`__,
+ `video <https://youtu.be/FN4J2gB2Kns>`__)
+
+ - HKG18
+ - HKG18-402 - Build secure key management services in OP-TEE
+ (`slides <https://www.slideshare.net/linaroorg/hkg18402-build-secure-key-management-services-in-optee>`__,
+ `video <http://connect.linaro.org.s3.amazonaws.com/hkg18/videos/hkg18-402.mp4>`__)
+
+ - SFO17
+ - SFO17-309 - Secure storage updates
+ (`slides <https://www.slideshare.net/linaroorg/secure-storage-updates-sfo17309>`__,
+ `video <https://youtu.be/k61PiuFrc_U>`__)
+
+ - Webinar
+ - TEE Linux kernel support and open source security
+ (`slides <https://www.slideshare.net/linaroorg/tee-kernel-support-is-now-upstream-what-this-means-for-open-source-security-76943254>`__,
+ `video <https://youtu.be/kk3_DUMJrTI>`__)
+
+ - BUD17
+ - BUD17-416 - Benchmark and profiling in OP TEE
+ (`slides <http://s3.amazonaws.com/connect.linaro.org/bud17/Presentations/BUD17-416%20-%20Benchmark%20and%20Profiling%20in%20OP-TEE.pdf>`__,
+ `video <https://youtu.be/gr6AxvqfDds>`__)
+
+ - BUD17-400 - Secure Data Path with OPTEE
+ (`slides <https://www.slideshare.net/linaroorg/bud17400-secure-data-path-with-optee>`__,
+ `video <https://youtu.be/6JdzsWZq4Ls>`__)
+
+ - LAS16
+ - LAS16-504 - Secure Storage updates in OP-TEE
+ (`slides <http://s3.amazonaws.com/connect.linaro.org/las16/Presentations/Friday/LAS16-504%20-%20Secure%20Storage%20updates%20in%20OP-TEE.pdf>`__,
+ `video <https://youtu.be/9OEt4aG6V5w>`__)
+
+ - LAS16-406 - Android Widevine on OP-TEE
+ (`slides <http://s3.amazonaws.com/connect.linaro.org/las16/Presentations/Thursday/LAS16-406%20-%20Android%20Widevine%20on%20OP-TEE.pdf>`__,
+ `video <https://youtu.be/LEJqTXVs9N8>`__)
+
+ - LAS16-111 - Easing Access to ARM TrustZone OP TEE and Raspberry Pi 3
+ (`slides <https://www.slideshare.net/96Boards/las16-111-raspberry-pi3-optee-and-jtag-debugging>`__,
+ `video <https://youtu.be/3MnLrHoQcyI>`__)
+
+ - BKK16
+ - BKK16-201 - PlayReady OP-TEE Integration with Secure Video Path
+ (`slides <https://www.slideshare.net/linaroorg/bkk16201-play-ready-optee-integration-with-secure-video-path-lhg1>`__,
+ `video <https://youtu.be/04iRIWvxCiw>`__)
+
+ - BKK16-110 - A Gentle Introduction to Trusted Execution and OP-TEE
+ (`slides <https://www.slideshare.net/linaroorg/bkk16110-a-gentle-introduction-to-trusted-execution-and-optee>`__)
+
+ - SFO15
+ - SFO15-503 - Secure storage in OP-TEE
+ (`slides <https://www.slideshare.net/linaroorg/sfo15503-secure-storage-in-optee>`__,
+ `video <https://youtu.be/pChEdObYLRM>`__)
+
+ - SFO15-205 - OP-TEE Content Decryption with Microsoft PlayReady on ARM TrustZone
+ (`slides <https://www.slideshare.net/linaroorg/sfo15205-optee-content-decryption-with-microsoft-playready-on-arm-53111683>`__,
+ `video <https://youtu.be/defbtpsw6h8>`__)
+
+ - SFO15-200 - TEE kernel driver
+ (`slides <https://www.slideshare.net/linaroorg/sfo15200-linux-kernel-generic-tee-driver>`__,
+ `video <https://youtu.be/BhLndLUQamM>`__)
+
+ - HKG15
+ - HKG15-311 - OP-TEE for Beginners and Porting Review
+ (`slides <https://www.slideshare.net/linaroorg/hkg15311-optee-for-beginners-and-porting-review>`__,
+ `video <https://youtu.be/Fksx4-bpHRY>`__)
+
+ - HKG15-307 - OP-TEE pager
+ (`slides <https://www.slideshare.net/linaroorg/hkg15307-optee-paging>`__,
+ `video <https://youtu.be/hCYjlBPxEbY>`__)
+
+ - LCU14
+ - LCU14-306 - OP-TEE Future Enhancements
+ (`slides <https://www.slideshare.net/linaroorg/lcu14-306-optee-future-enhancements>`__)
+
+ - LCU14-302 - How to port OP-TEE to another platform
+ (`slides <https://www.slideshare.net/linaroorg/lcu14-302-how-to-port-optee-to-another-platform>`__,
+ `video <https://youtu.be/QgaGJow7hws>`__)
+
+ - LCU14-107 - OP-TEE on ARMv8-A
+ (`slides <https://www.slideshare.net/linaroorg/lcu14-107-optee-on-ar-mv8>`__,
+ `video <https://youtu.be/JViplz-ah9M>`__)
+
+ - LCU14-103 - How to create and run Trusted Applications on OP-TEE
+ (`slides <https://www.slideshare.net/linaroorg/lcu14103-how-to-create-and-run-trusted-applications-on-optee>`__,
+ `video <https://youtu.be/6fmwhqrOmpc>`__)
+
+ - LCA14
+ - LCA14-502 - The way to a generic TrustZone solution
+ (`slides <https://www.slideshare.net/linaroorg/lca14-502-thewaytoagenerictrustzonesolution>`__)
+
+ - LCA14-418 - Testing a secure framework
+ (`slides <https://www.slideshare.net/linaroorg/lca14-lca14418-testing-a-secure-framework>`__)
+