From 53e6ae69054c69b674c797ef52e48821016a5ee6 Mon Sep 17 00:00:00 2001
From: Martyn Welch <martyn.welch@collabora.com>
Date: Wed, 3 Feb 2021 14:37:57 +0000
Subject: [PATCH] Update OP-TEE document to use preferred spelling
Update the OP-TEE document to use the preferred spelling (US English),
adding words to dictionary where appropriate.
Signed-off-by: Martyn Welch <martyn.welch@collabora.com>
---
content/concepts/op-tee.md | 30 +++++++++++++++---------------
dictionary.aspell | 24 +++++++++++++++++++++++-
2 files changed, 38 insertions(+), 16 deletions(-)
diff --git a/content/concepts/op-tee.md b/content/concepts/op-tee.md
index 56c0d807c..9321fb824 100644
--- a/content/concepts/op-tee.md
+++ b/content/concepts/op-tee.md
@@ -23,7 +23,7 @@ The Apertis application requests that functionality in the secure environment si
The signed challenge is then returned to the cloud service, which checks the validity of the signature using the public key that it holds to authenticate the user.
Such systems may additionally require the state of the system to be verified (typically by building a [chain of trust](https://en.wikipedia.org/wiki/Chain_of_trust)) before use of the secure keys is allowed, thus ensuring the device hasn't been altered in ways which may compromise protection of the keys.
-Whilst a system could be architected to utilise a separate processor to perform such tasks, this significantly drives up system complexity and cost.
+Whilst a system could be architected to utilize a separate processor to perform such tasks, this significantly drives up system complexity and cost.
Some platforms provide a mechanism to enable a secure, trusted environment or "[Trusted Execution Environment](https://en.wikipedia.org/wiki/Trusted_execution_environment)" (TEE) to be setup.
A TEE runs on the application processor, but with mechanisms in place to isolate the code or data of the two running systems (the TEE and the main OS) from each other.
ARM provides an implementation of such security mechanisms, known as [ARM TrustZone](https://developer.arm.com/ip-products/security-ip/trustzone), mainly on Cortex-A processors.
@@ -33,7 +33,7 @@ ARM provides an implementation of such security mechanisms, known as [ARM TrustZ
A TEE exists as a separate environment running in parallel with the main operating system.
-At boot, both of these environments need to be loaded and initialised, this is achieved by running special boot firmware which enables the TrustZone security features and loads the required software elements.
+At boot, both of these environments need to be loaded and initialized, this is achieved by running special boot firmware which enables the TrustZone security features and loads the required software elements.
When enabled, a "secure monitor" runs in the highest privilege level provided by the processor.
The secure monitor supports switching between the trusted and untrusted environments and enabling messages to be passed from one environment to the other.
ARM provide a reference secure monitor as part of the [ARM Trusted Firmware](https://github.com/ARM-software/arm-trusted-firmware) (ATF) project.
@@ -42,12 +42,12 @@ OP-TEE provides a trusted environment which can run [Trusted Applications]( {{<
As well as starting up a trusted OS in the trusted environment, ATF typically starts a standard OS such as Linux on the untrusted side, known as the rich operating system or "Rich Execution Environment" (REE), by running the firmware normally used for this OS.
It is necessary for the OS to have drivers capable of interfacing with the secure monitor and that understands how to format messages for the trusted OS used on the trusted side.
-Linux contains a [TEE subsystem](https://www.kernel.org/doc/Documentation/tee.txt) which provides a standardised way to communicate with TEE environments.
+Linux contains a [TEE subsystem](https://www.kernel.org/doc/Documentation/tee.txt) which provides a standardized way to communicate with TEE environments.
The OP-TEE project have upstreamed a [driver](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/tee/optee) to this subsystem to enable communications with the OP-TEE trusted environment.
OP-TEE relies on the REE to provide a number of remote services, such as file system access, as it does not have drivers for this functionality itself.
The OP-TEE project provides a Linux user space [supplicant daemon](https://github.com/OP-TEE/optee_client) which supplies the services required by the trusted environment.
-A library is also provided which implements a standardised mechanism, documented in the [GlobalPlatform TEE Client API Specification v1.0](https://globalplatform.org/specs-library/tee-client-api-specification/), for communicating with the TEE.
+A library is also provided which implements a standardized mechanism, documented in the [GlobalPlatform TEE Client API Specification v1.0](https://globalplatform.org/specs-library/tee-client-api-specification/), for communicating with the TEE.
It is expected for this library to be used by applications needing to communicate with the TAs.
## Boot Process
@@ -61,7 +61,7 @@ The process used to perform a secure boot is dependent on the mechanisms provide
Typically it requires the boot process to be locked down to boot from known storage (such as a specific flash device) and for the boot binaries to be signed so that they can be verified at boot.
The keys used for verification are usually read-only and held in fuses within the SoC.
-The signed binaries comprise a series of bootloaders which progressively bring up the system, each being able to perform a bit more of the process utilising support enabled by earlier bootloaders.
+The signed binaries comprise a series of bootloaders which progressively bring up the system, each being able to perform a bit more of the process utilizing support enabled by earlier bootloaders.
This series of bootloaders will load the secure monitor (known as `EL3 Runtime Software` in this context), OP-TEE (the `Secure-EL1 Payload`) and finally U-Boot (the `Non-trusted Firmware`), which loads Linux.
The ARMv8 architecture provides 4 privilege levels.
@@ -86,7 +86,7 @@ The OP-TEE project provides a number of [TA examples](https://github.com/linaro-
Trusted Applications provide immense flexibility in the functionality that can be provided from the TEE environment.
This flexibility is such that a proof of concept has been completed implementing a [TPM 2.0 implementation](https://github.com/Microsoft/ms-tpm-20-ref) that can be [used in OP-TEE](https://github.com/jbech-linaro/manifest/tree/ftpm).
-## Virtualisation Support
+## Virtualization Support
As the hypervisor and secure monitor each have a separate privilege level, it is possible for the TEE to co-exist with systems running a hypervisor.
OP-TEE currently has [experimental support](https://optee.readthedocs.io/en/latest/architecture/virtualization.html) for the XEN hypervisor running on an emulated ARMv8 system.
@@ -101,7 +101,7 @@ A number of steps need to be taken in order to enable TEE support in Apertis.
## Secure Boot
-Secure boot provides an initial important step in initialisation of the TEE by ensuring that the initialisation process is able to proceed without interference.
+Secure boot provides an initial important step in initialization of the TEE by ensuring that the initialization process is able to proceed without interference.
Unfortunately this fundamental step is very platform dependent and can not be solved as a general case.
Apertis has already taken steps to [document and demonstrate secure boot]( {{< ref "secure-boot.md" >}} ).
At the moment, Apertis only ships some support for secure on the SABRE Lite platform. This provides a good reference for the overall process but, unfortunately, the SABRE Lite is not a good choice as a technology demonstrator for TEE due to its age.
@@ -143,7 +143,7 @@ The TA-devkit will need to be packaged so that it can be provided as a build dep
## Linux Kernel
-Debian (and thus the Apertis config) does already enable the TEE subsystem on arm64 where ATF can be used.
+Debian (and thus the Apertis configuration) does already enable the TEE subsystem on arm64 where ATF can be used.
It is understood that this should be sufficient and thus no extra modifications to the kernel will be required.
## OP-TEE Supplicant and User Space Libraries
@@ -156,7 +156,7 @@ As these components run in the REE they don't need to be signed.
## Sample TAs
To enable early investigation of TEEs on Apertis, the [example TAs](https://github.com/linaro-swg/optee_examples) should be packaged.
-For simple use cases, it may be that these examples either fulfil or provide a framework for development of the TEE requirements.
+For simple use cases, it may be that these examples either fulfill or provide a framework for development of the TEE requirements.
They will provide a useful reference of how to package TAs for Apertis even for the use cases that are not covered by the examples.
The sample TAs will be signed with the key provided by the Apertis TA-devkit package (which will be a build dependency) and thus will be usable with the OP-TEE OS built for Apertis.
@@ -164,7 +164,7 @@ The sample TAs will be signed with the key provided by the Apertis TA-devkit pac
## Test Suite
A [test suite](https://github.com/OP-TEE/optee_test) exists for OP-TEE.
-Providing this in Apertis would enable developers to gain some confidence that OP-TEE was installed and initialised correctly.
+Providing this in Apertis would enable developers to gain some confidence that OP-TEE was installed and initialized correctly.
## Debos Scripting
@@ -183,16 +183,16 @@ We therefore advise following up this document with adding the support to Aperti
## Choice of Reference Platform
The OP-TEE project is specifically targeted towards the ARM ecosystem, specifically those that provide ARM TrustZone.
-ARM TrustZone has been improved in later iterations of the technology and standardised with a reference implementation available to for using TEEs as part of the ATF project.
-We recommend that a platform that is capable of utilising ATF is chosen for this reference.
-An advantage of implementing the TEE using ATF is that this provides a standardised interface for the trusted OS and thus allows Apertis to potentially be used with alternative trusted OS implementations.
+ARM TrustZone has been improved in later iterations of the technology and standardized with a reference implementation available to for using TEEs as part of the ATF project.
+We recommend that a platform that is capable of utilizing ATF is chosen for this reference.
+An advantage of implementing the TEE using ATF is that this provides a standardized interface for the trusted OS and thus allows Apertis to potentially be used with alternative trusted OS implementations.
## Test Integration
The availability of a test suite provides some coverage of the OP-TEE functionality with minimal effort as this should be usable from automated testing.
-Whilst the test suite will test operation of OP-TEE itself, an important part of initialising a TEE is the platform specific secure boot.
+Whilst the test suite will test operation of OP-TEE itself, an important part of initializing a TEE is the platform specific secure boot.
Unless using a platform very closely aligned with an Apertis reference platform, this step will be the responsibility of the product team.
-To ensure that this is properly implemented, tests could be developed that attempt to utilise incorrectly signed binaries at the different stages of the boot process to ensure that each step is properly validated, providing a reference for how to test secure boot.
+To ensure that this is properly implemented, tests could be developed that attempt to utilize incorrectly signed binaries at the different stages of the boot process to ensure that each step is properly validated, providing a reference for how to test secure boot.
Experience with the SABRE Lite has shown that whilst devices may be set up to emulate a secured configuration, their behavior differs from the behavior of devices locked via its embedded fuses. Since boards locked in a secure boot configuration no longer allow some operations, they become less useful for general development. For this reason, a dedicated set of boards locked via fuses may be required to fully test that secure boot restrictions are being enforced.
diff --git a/dictionary.aspell b/dictionary.aspell
index da27a4fe5..11461fa48 100644
--- a/dictionary.aspell
+++ b/dictionary.aspell
@@ -1,24 +1,44 @@
-personal_ws-1.1 en 32 utf-8
+personal_ws-1.1 en 49 utf-8
+ARMv
+ATF
Apertis
Debos
Flatpak
Flatpaks
GitLab
+GlobalPlatform
HMI
HTML
LFS
+MX
OpenSSL
PDF
PDFs
+REE
SDK
+SoC
+TAs
+TEE
+TEEs
+TPM
+TrustZone
UI
+UUID
+VM
+VMs
WIP
+Xen
YAML
+architected
backport
backported
+bootloader
+bootloaders
+cryptographic
deduplicate
deduplicated
deployable
+devkit
downstreams
hotfix
namespace
@@ -31,3 +51,5 @@ shortcode
snapshotted
snapshotting
submitters
+untrusted
+upstreamed
--
GitLab