aboutsummaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorKevin Peng <kevin.peng@arm.com>2020-03-04 16:55:37 +0800
committerKevin Peng <kevin.peng@arm.com>2020-06-12 13:28:21 +0800
commitc6d7450aa7bdffd92c28555808083d9e06f72efe (patch)
tree0ba01437c298e54d52b7f9b89c79e43cd95010af /docs
parent894e642e20ed371a088e7e6d59205e85e826ed35 (diff)
downloadtrusted-firmware-m-c6d7450aa7bdffd92c28555808083d9e06f72efe.tar.gz
SST: Rename SST(Secure STorage) to PS(Protected Storage)
This patches renames SST(Secure STorage) to PS(Protected Storage) for files, folders and any contents in files to align with the PSA Storage API spec. Change-Id: Icf991f59512875780c159f22737b521b3b2d4924 Signed-off-by: Kevin Peng <kevin.peng@arm.com>
Diffstat (limited to 'docs')
-rw-r--r--docs/about/maintainers.rst4
-rw-r--r--docs/design_documents/ps_key_management.rst (renamed from docs/design_documents/sst_key_management.rst)62
-rw-r--r--docs/glossary.rst10
-rw-r--r--docs/user_guides/services/tfm_its_integration_guide.rst4
-rw-r--r--docs/user_guides/services/tfm_ps_integration_guide.rst (renamed from docs/user_guides/services/tfm_sst_integration_guide.rst)202
-rw-r--r--docs/user_guides/services/tfm_secure_partition_addition.rst10
-rw-r--r--docs/user_guides/tfm_build_instruction.rst2
-rw-r--r--docs/user_guides/tfm_integration_guide.rst14
-rw-r--r--docs/user_guides/tfm_ns_client_identification.rst4
-rw-r--r--docs/user_guides/tfm_secure_boot.rst8
-rw-r--r--docs/user_guides/tfm_user_guide.rst64
11 files changed, 194 insertions, 190 deletions
diff --git a/docs/about/maintainers.rst b/docs/about/maintainers.rst
index c75d7ad42e..e17795225e 100644
--- a/docs/about/maintainers.rst
+++ b/docs/about/maintainers.rst
@@ -33,8 +33,8 @@ Tamas Ban
:email: `Tamas.Ban@arm.com <Tamas.Ban@arm.com>`__
:github: `tamban01 <https://github.com/tamban01>`__
-Secure Storage
-~~~~~~~~~~~~~~
+Secure Storage (ITS & PS)
+~~~~~~~~~~~~~~~~~~~~~~~~~
Jamie Fox
:email: `jamie.fox@arm.com <jamie.fox@arm.com>`__
diff --git a/docs/design_documents/sst_key_management.rst b/docs/design_documents/ps_key_management.rst
index 0f617e8bfe..80a39be492 100644
--- a/docs/design_documents/sst_key_management.rst
+++ b/docs/design_documents/ps_key_management.rst
@@ -1,6 +1,6 @@
-=====================================
-Secure Storage service key management
-=====================================
+========================================
+Protected Storage service key management
+========================================
:Author: Jamie Fox
:Organization: Arm Limited
@@ -21,13 +21,13 @@ the root of trust (RoT) for confidentiality in the system. It must have at least
128 bits of entropy (and a 128 bit data size), and be accessible only to Trusted
code or Trusted hardware that acts on behalf of Trusted code. [TBSA-M]_
-In the current implementation, the Secure Storage (SST) service reads the HUK
+In the current implementation, the Protected Storage (PS) service reads the HUK
directly and imports it into the Crypto partition for further use. This has
multiple drawbacks:
-- If there were a flaw in SST that allowed an attacker to obtain its key, then
+- If there were a flaw in PS that allowed an attacker to obtain its key, then
the HUK would be exposed, and so the attacker would be able to decrypt not
- just secure storage but also anything else encrypted with the HUK or a key
+ just protected storage but also anything else encrypted with the HUK or a key
derived from the HUK.
- Using the same key for two or more different cryptographic algorithms may
reduce the security provided by one or more of them.
@@ -38,21 +38,21 @@ multiple drawbacks:
Proposal
========
-Each time the system boots, SST will request that the Crypto service uses a key
+Each time the system boots, PS will request that the Crypto service uses a key
derivation function (KDF) to derive a storage key from the HUK. The storage key
could be kept in on-chip volatile memory private to the Crypto partition, or it
-could remain inside a secure element. Either way it will not be returned to SST.
+could remain inside a secure element. Either way it will not be returned to PS.
-For each call to the PSA Protected Storage APIs, SST will make requests to the
+For each call to the PSA Protected Storage APIs, PS will make requests to the
Crypto service to perform AEAD encryption and/or decryption operations using the
storage key (providing a fresh nonce for each encryption).
-At no point will SST access the key material itself, only referring to the HUK
+At no point will PS access the key material itself, only referring to the HUK
and storage key by their handles in the Crypto service.
Key derivation
==============
-SST will make key derivation requests to the Crypto service with calls to the
+PS will make key derivation requests to the Crypto service with calls to the
PSA Crypto APIs. In order to derive the storage key, the following calls will be
made::
@@ -62,33 +62,33 @@ made::
&huk_key_handle)
/* Set up a key derivation operation with the HUK as the input key */
- psa_key_derivation(&sst_key_generator,
+ psa_key_derivation(&ps_key_generator,
huk_key_handle,
TFM_CRYPTO_ALG_HUK_DERIVATION,
- SST_KEY_SALT, SST_KEY_SALT_LEN_BYTES,
- SST_KEY_LABEL, SST_KEY_LABEL_LEN_BYTES,
- SST_KEY_LEN_BYTES)
+ PS_KEY_SALT, PS_KEY_SALT_LEN_BYTES,
+ PS_KEY_LABEL, PS_KEY_LABEL_LEN_BYTES,
+ PS_KEY_LEN_BYTES)
/* Create the storage key from the key generator */
- psa_generator_import_key(sst_key_handle,
- SST_KEY_TYPE,
- PSA_BYTES_TO_BITS(SST_KEY_LEN_BYTES),
- &sst_key_generator)
+ psa_generator_import_key(ps_key_handle,
+ PS_KEY_TYPE,
+ PSA_BYTES_TO_BITS(PS_KEY_LEN_BYTES),
+ &ps_key_generator)
.. note:: ``TFM_CRYPTO_KEY_ID_HUK`` is a PSA Crypto key ID that is assumed in
this design to identify the hardware unique key.
- ``sst_key_handle`` is a PSA Crypto key handle to a volatile key, set
+ ``ps_key_handle`` is a PSA Crypto key handle to a volatile key, set
up in the normal way. After the call to ``psa_generator_import_key``,
it contains the storage key.
- ``SST_KEY_SALT`` can be ``NULL``, as it is only used in the 'extract'
+ ``PS_KEY_SALT`` can be ``NULL``, as it is only used in the 'extract'
step of HKDF, which is redundant when the input key material is a
cryptographically strong key. [RFC5869]_ It must be constant so that
the same key can be derived each boot, to decrypt previously-stored
data.
- ``SST_KEY_LABEL`` can be any string that is independent of the input
+ ``PS_KEY_LABEL`` can be any string that is independent of the input
key material and different to the label used in any other derivation
from the same input key. It prevents two different contexts from
deriving the same output key from the same input key.
@@ -109,7 +109,7 @@ hash function. HKDF is suitable because:
case here).
- The trade-off is that HKDF is only suitable when the input key material has at
least as much entropy as required for the output key material. But this is the
- case here, as the HUK has 128 bits of entropy, the same as required by SST.
+ case here, as the HUK has 128 bits of entropy, the same as required by PS.
- HKDF is standardised in RFC 5869 [RFC5869]_ and its security has been formally
analysed. [HKDF]_
- It is supported by the TF-M Crypto service.
@@ -119,8 +119,8 @@ a modern standardised algorithm, considered to be secure and supported by TF-M
Crypto. This narrows it down to just the SHA-2 family. Of the hash functions in
the family, SHA-256 is the simplest and provides more than enough output length.
-Keeping the storage key private to SST
---------------------------------------
+Keeping the storage key private to PS
+-------------------------------------
The salt and label fields are not generally secret, so an Application RoT
service could request the Crypto service to derive the same storage key from the
HUK, which violates isolation between Application RoT partitions to some extent.
@@ -128,10 +128,10 @@ This could be fixed in a number of ways:
- Only PSA RoT partitions can request Crypto to derive keys from the HUK.
- - But then either SST has to be in the PSA RoT or request a service in the PSA
+ - But then either PS has to be in the PSA RoT or request a service in the PSA
RoT to do the derivation on its behalf.
-- SST has a secret (pseudo)random salt, accessible only to it, that it uses to
+- PS has a secret (pseudo)random salt, accessible only to it, that it uses to
derive the storage key.
- Where would this salt be stored? It cannot be generated fresh each boot
@@ -150,13 +150,13 @@ is the one that is proposed.
Key use
=======
-To encrypt and decrypt data, SST will call the PSA Crypto AEAD APIs in the same
-way as the current implementation, but ``sst_key_handle`` will refer to the
+To encrypt and decrypt data, PS will call the PSA Crypto AEAD APIs in the same
+way as the current implementation, but ``ps_key_handle`` will refer to the
storage key, rather than the imported HUK. For each encryption operation, the
following call is made (and analogously for decryption)::
- psa_aead_encrypt(sst_key_handle, SST_CRYPTO_ALG,
- crypto->ref.iv, SST_IV_LEN_BYTES,
+ psa_aead_encrypt(ps_key_handle, PS_CRYPTO_ALG,
+ crypto->ref.iv, PS_IV_LEN_BYTES,
add, add_len,
in, in_len,
out, out_size, out_len)
diff --git a/docs/glossary.rst b/docs/glossary.rst
index 6f27f33358..73e91aa749 100644
--- a/docs/glossary.rst
+++ b/docs/glossary.rst
@@ -80,9 +80,13 @@ TF-M related
A component within the TEE that is atomic from a security/trust point of
view, i.e. which is viewed as a single entity from a TF-M point of view.
- SST : TF-M related
- Secure Storage Service
- Secure storage service provided by TF-M.
+ PS : TF-M related
+ Protected Storage
+ Protected storage service provided by TF-M.
+
+ ITS : TF-M related
+ Internal Trusted Storage
+ Internal Trusted Storage service provided by TF-M.
TFM
TF-M
diff --git a/docs/user_guides/services/tfm_its_integration_guide.rst b/docs/user_guides/services/tfm_its_integration_guide.rst
index f668913561..f6b2dec408 100644
--- a/docs/user_guides/services/tfm_its_integration_guide.rst
+++ b/docs/user_guides/services/tfm_its_integration_guide.rst
@@ -115,7 +115,7 @@ Core Files
- ``tfm_internal_trusted_storage.c`` - Contains the TF-M internal trusted
storage API implementations which are the entry points to the ITS service.
Allocates a filesystem context for ITS and makes appropriate fs calls. Also
- handles requests from the SST partition with a separate fs context.
+ handles requests from the PS partition with a separate fs context.
- ``its_utils.c`` - Contains common and basic functionalities used across the
ITS service code.
@@ -170,7 +170,7 @@ Flash Interface
- ``flash/its_flash_info_external.c`` - Defines an instance of the
``struct its_flash_info_t`` type for the external flash device, used only to
- handle requests from the SST partition.
+ handle requests from the PS partition.
The CMSIS flash interface **must** be implemented for each target based on its
flash controller.
diff --git a/docs/user_guides/services/tfm_sst_integration_guide.rst b/docs/user_guides/services/tfm_ps_integration_guide.rst
index 6c860d2bb2..1f47204cbd 100644
--- a/docs/user_guides/services/tfm_sst_integration_guide.rst
+++ b/docs/user_guides/services/tfm_ps_integration_guide.rst
@@ -1,21 +1,21 @@
-########################################
-Secure Storage Service Integration Guide
-########################################
+###########################################
+Protected Storage Service Integration Guide
+###########################################
************
Introduction
************
-TF-M Secure Storage (SST) service implements PSA Protected Storage APIs.
+TF-M Protected Storage (PS) service implements PSA Protected Storage APIs.
The service is backed by hardware isolation of the flash access domain and, in
the current version, relies on hardware to isolate the flash area from
non-secure access. In absence of hardware level isolation, the secrecy and
integrity of data is still maintained.
-The SST service implements an AES-GCM based AEAD encryption policy, as a
+The PS service implements an AES-GCM based AEAD encryption policy, as a
reference, to protect data integrity and authenticity.
-SST reuses the non-hierarchical filesystem provided by the TF-M Internal Trusted
+PS reuses the non-hierarchical filesystem provided by the TF-M Internal Trusted
Storage service to store encrypted, authenticated objects on the external flash
device.
@@ -29,7 +29,7 @@ The design addresses the following high level requirements as well:
- **Integrity** - Resistant to tampering by either the normal users of a product,
package, or system or others with physical access to it. If the content of the
- secure storage is changed maliciously, the service is able to detect it.
+ protected storage is changed maliciously, the service is able to detect it.
- **Reliability** - Resistant to power failure scenarios and incomplete write
cycles.
@@ -42,9 +42,9 @@ The design addresses the following high level requirements as well:
very small silicon footprint, the PPA (power, performance, area) should be
optimal.
-*******************************
-Current SST Service Limitations
-*******************************
+******************************
+Current PS Service Limitations
+******************************
- **Fragmentation** - The current design does not support fragmentation, as an
asset is stored in a contiguous space in a block. This means that the maximum
asset size can only be up-to a block size. Detailed information about the
@@ -91,19 +91,19 @@ Current SST Service Limitations
**************
Code Structure
**************
-Secure storage service code is located in ``secure_fw/partitions/secure_storage/``
-and is divided as follows:
+Protected storage service code is located in
+``secure_fw/partitions/protected_storage/`` and is divided as follows:
- Core files
- Cryptographic interfaces
- Non-volatile (NV) counters interfaces
-The PSA PS interfaces for SST service are located in ``interface/include/psa``
+The PSA PS interfaces for PS service are located in ``interface/include/psa``
PSA Protected Storage Interfaces
================================
-The SST service exposes the following mandatory PSA PS interfaces, version 1.0:
+The PS service exposes the following mandatory PSA PS interfaces, version 1.0:
.. code-block:: c
@@ -115,41 +115,41 @@ The SST service exposes the following mandatory PSA PS interfaces, version 1.0:
For the moment, it does not support the extended version of those APIs.
-These PSA PS interfaces and SST TF-M types are defined and documented in
+These PSA PS interfaces and PS TF-M types are defined and documented in
``interface/include/psa/protected_storage.h``,
``interface/include/psa/storage_common.h`` and
-``interface/include/tfm_sst_defs.h``
+``interface/include/tfm_ps_defs.h``
Core Files
==========
-- ``tfm_sst_req_mngr.c`` - Contains the SST request manager implementation which
+- ``tfm_ps_req_mngr.c`` - Contains the PS request manager implementation which
handles all requests which arrive to the service. This layer extracts the
arguments from the input and output vectors, and it calls the protected
storage layer with the provided parameters.
- ``tfm_protected_storage.c`` - Contains the TF-M protected storage API
- implementations which are the entry points to the SST service.
+ implementations which are the entry points to the PS service.
-- ``sst_object_system.c`` - Contains the object system implementation to manage
- all objects in SST area.
+- ``ps_object_system.c`` - Contains the object system implementation to manage
+ all objects in PS area.
-- ``sst_object_table.c`` - Contains the object system table implementation which
- complements the object system to manage all object in the SST area.
+- ``ps_object_table.c`` - Contains the object system table implementation which
+ complements the object system to manage all object in the PS area.
The object table has an entry for each object stored in the object system
and keeps track of its version and owner.
-- ``sst_encrypted_object.c`` - Contains an implementation to manipulate
- encrypted objects in the SST object system.
+- ``ps_encrypted_object.c`` - Contains an implementation to manipulate
+ encrypted objects in the PS object system.
-- ``sst_utils.c`` - Contains common and basic functionalities used across the
- SST service code.
+- ``ps_utils.c`` - Contains common and basic functionalities used across the
+ PS service code.
Flash Filesystem and Flash Interfaces
=====================================
-The SST service reuses the non-hierarchical filesystem and flash interfaces
+The PS service reuses the non-hierarchical filesystem and flash interfaces
provided by the TF-M Internal Trusted Storage service. It stores encrypted,
authenticated objects on the external flash device by making service calls to
-the ITS service. When the ITS service receives requests from the SST partition,
+the ITS service. When the ITS service receives requests from the PS partition,
it handles the request by using a separate filesystem context initialised to use
the external flash device.
@@ -161,81 +161,81 @@ information about the filesystem and flash interfaces can be found in the
</docs/user_guides/services/tfm_its_integration_guide>`.
The structure containing info about the external flash device, used by the ITS
-service to handle requests from the SST partition, is defined in
+service to handle requests from the PS partition, is defined in
``secure_fw/partitions/internal_trusted_storage/flash/its_flash_info_external.c``,
which depends on target-specific definitions from
``platform/ext/target/<TARGET_NAME>/partition/flash_layout.h``. Please see the
-`Secure Storage Service Definitions` section for details.
+`Protected Storage Service Definitions` section for details.
Cryptographic Interface
=======================
-- ``crypto/sst_crypto_interface.h`` - Abstracts the cryptographic operations for
- the secure storage service.
+- ``crypto/ps_crypto_interface.h`` - Abstracts the cryptographic operations for
+ the protected storage service.
-- ``crypto/sst_crypto_interface.c`` - Implements the SST service cryptographic
+- ``crypto/ps_crypto_interface.c`` - Implements the PS service cryptographic
operations with calls to the TF-M Crypto service.
Non-volatile (NV) Counters Interface
====================================
-The current SST service provides rollback protection based on NV
+The current PS service provides rollback protection based on NV
counters.
-SST defines and implements the following NV counters functionalities:
+PS defines and implements the following NV counters functionalities:
-- ``nv_counters/sst_nv_counters.h`` - Abstracts SST non-volatile
+- ``nv_counters/ps_nv_counters.h`` - Abstracts PS non-volatile
counters operations. This API detaches the use of NV counters from the TF-M NV
counters implementation, provided by the platform, and provides a mechanism to
- compile in a different API implementation for test purposes. A SST test suite
- **may** provide its own custom implementation to be able to test different SST
+ compile in a different API implementation for test purposes. A PS test suite
+ **may** provide its own custom implementation to be able to test different PS
service use cases.
-- ``nv_counters/sst_nv_counters.c`` - Implements the SST NV counters interfaces
+- ``nv_counters/ps_nv_counters.c`` - Implements the PS NV counters interfaces
based on TF-M NV counters implementation provided by the platform.
-*****************************
-SST Service Integration Guide
-*****************************
+****************************
+PS Service Integration Guide
+****************************
This section describes mandatory (i.e. **must** implement) or optional
(i.e. **may** implement) interfaces which the system integrator have to take
-in to account in order to integrate the secure storage service in a new
+in to account in order to integrate the protected storage service in a new
platform.
Maximum Asset Size
==================
An asset is stored in a contiguous space in a block/sector. The maximum
size of an asset can be up-to the size of the data block/sector minus the object
-header size (``SST_OBJECT_HEADER_SIZE``) which is defined in
-``sst_object_defs.h``. The ``SST_OBJECT_HEADER_SIZE`` changes based on the
-``SST_ENCRYPTION`` flag status.
+header size (``PS_OBJECT_HEADER_SIZE``) which is defined in
+``ps_object_defs.h``. The ``PS_OBJECT_HEADER_SIZE`` changes based on the
+``PS_ENCRYPTION`` flag status.
-Secure Storage Service Definitions
-==================================
-The SST service requires the following platform definitions:
+Protected Storage Service Definitions
+=====================================
+The PS service requires the following platform definitions:
-- ``SST_FLASH_AREA_ADDR`` - Defines the flash address where the secure storage
+- ``PS_FLASH_AREA_ADDR`` - Defines the flash address where the protected storage
area starts.
-- ``SST_FLASH_AREA_SIZE`` - Defines the size of the dedicated flash area
- for secure storage in bytes.
-- ``SST_SECTOR_SIZE`` - Defines the size of the flash sectors (the smallest
+- ``PS_FLASH_AREA_SIZE`` - Defines the size of the dedicated flash area
+ for protected storage in bytes.
+- ``PS_SECTOR_SIZE`` - Defines the size of the flash sectors (the smallest
erasable unit) in bytes.
-- ``SST_SECTORS_PER_BLOCK`` - Defines the number of contiguous SST_SECTOR_SIZE
+- ``PS_SECTORS_PER_BLOCK`` - Defines the number of contiguous PS_SECTOR_SIZE
to form a logical block in the filesystem.
-- ``SST_FLASH_DEV_NAME`` - Specifies the flash device used by SST to store the
+- ``PS_FLASH_DEV_NAME`` - Specifies the flash device used by PS to store the
data.
-- ``SST_FLASH_PROGRAM_UNIT`` - Defines the smallest flash programmable unit in
- bytes. Valid values are powers of two between 1 and ``SST_SECTOR_SIZE``
+- ``PS_FLASH_PROGRAM_UNIT`` - Defines the smallest flash programmable unit in
+ bytes. Valid values are powers of two between 1 and ``PS_SECTOR_SIZE``
inclusive.
-- ``SST_MAX_ASSET_SIZE`` - Defines the maximum asset size to be stored in the
- SST area. This size is used to define the temporary buffers used by SST to
+- ``PS_MAX_ASSET_SIZE`` - Defines the maximum asset size to be stored in the
+ PS area. This size is used to define the temporary buffers used by PS to
read/write the asset content from/to flash. The memory used by the temporary
- buffers is allocated statically as SST does not use dynamic memory allocation.
-- ``SST_NUM_ASSETS`` - Defines the maximum number of assets to be stored in the
- SST area. This number is used to dimension statically the object table size in
+ buffers is allocated statically as PS does not use dynamic memory allocation.
+- ``PS_NUM_ASSETS`` - Defines the maximum number of assets to be stored in the
+ PS area. This number is used to dimension statically the object table size in
RAM (fast access) and flash (persistent storage). The memory used by the
- object table is allocated statically as SST does not use dynamic memory
+ object table is allocated statically as PS does not use dynamic memory
allocation.
-The sectors reserved to be used as secure storage **must** be contiguous sectors
-starting at ``SST_FLASH_AREA_ADDR``.
+The sectors reserved to be used as protected storage **must** be contiguous
+sectors starting at ``PS_FLASH_AREA_ADDR``.
The design requires either 2 blocks, or any number of blocks greater than or
equal to 4. Total number of blocks can not be 0, 1 or 3. This is a design choice
@@ -245,7 +245,7 @@ Target must provide a header file, called ``flash_layout.h``, which defines the
information explained above. The defines must be named as they are specified
above.
-More information about the ``flash_layout.h`` content, not SST related, is
+More information about the ``flash_layout.h`` content, not PS related, is
available in :doc:`platform readme </platform/ext/readme>` along with other
platform information.
@@ -256,7 +256,7 @@ platform NV counter interface. For API specification, please check:
``platform/include/tfm_plat_nv_counters.h``
The system integrators **may** implement this interface based on the target
-capabilities and set the ``SST_ROLLBACK_PROTECTION`` flag to compile in
+capabilities and set the ``PS_ROLLBACK_PROTECTION`` flag to compile in
the rollback protection code.
Secret Platform Unique Key
@@ -279,7 +279,7 @@ which performs the service request.
:doc:`NS client identification documentation </docs/user_guides/tfm_ns_client_identification>`
provides further details on how client identification works.
-SST service uses that TF-M core API to retrieve the client ID and associate it
+PS service uses that TF-M core API to retrieve the client ID and associate it
as the owner of an asset. Only the owner can read, write or delete that asset
based on the creation flags.
@@ -291,46 +291,46 @@ Cryptographic Interface
The reference encryption policy is built on AES-GCM, and it **may** be replaced
by a vendor specific implementation.
-The SST service abstracts all the cryptographic requirements and specifies the
+The PS service abstracts all the cryptographic requirements and specifies the
required cryptographic interface in
-``secure_fw/partitions/secure_storage/crypto/sst_crypto_interface.h``
+``secure_fw/partitions/protected_storage/crypto/ps_crypto_interface.h``
-The SST service cryptographic operations are implemented in
-``secure_fw/partitions/secure_storage/crypto/sst_crypto_interface.c``, using calls
-to the TF-M Crypto service.
+The PS service cryptographic operations are implemented in
+``secure_fw/partitions/protected_storage/crypto/ps_crypto_interface.c``, using
+calls to the TF-M Crypto service.
-SST Service Features Flags
-==========================
-SST service defines a set of flags that can be used to compile in/out certain
-SST service features. The ``CommonConfig.cmake`` file sets the default values
+PS Service Features Flags
+=========================
+PS service defines a set of flags that can be used to compile in/out certain
+PS service features. The ``CommonConfig.cmake`` file sets the default values
of those flags. However, those flags values can be overwritten by setting them
in ``platform/ext/<TARGET_NAME>.cmake`` based on the target capabilities or
-needs. The list of SST services flags are:
-
-- ``SST_ENCRYPTION``- this flag allows to enable/disable encryption
- option to encrypt the secure storage data.
-- ``SST_CREATE_FLASH_LAYOUT``- this flag indicates that it is required
- to create a SST flash layout. If this flag is set, SST service will
- generate an empty and valid SST flash layout to store assets. It will
- erase all data located in the assigned SST memory area before generating
- the SST layout. This flag is required to be set if the SST memory area
- is located in a non-persistent memory. This flag can be set if the SST
- memory area is located in a persistent memory without a valid SST flash
+needs. The list of PS services flags are:
+
+- ``PS_ENCRYPTION``- this flag allows to enable/disable encryption
+ option to encrypt the protected storage data.
+- ``PS_CREATE_FLASH_LAYOUT``- this flag indicates that it is required
+ to create a PS flash layout. If this flag is set, PS service will
+ generate an empty and valid PS flash layout to store assets. It will
+ erase all data located in the assigned PS memory area before generating
+ the PS layout. This flag is required to be set if the PS memory area
+ is located in a non-persistent memory. This flag can be set if the PS
+ memory area is located in a persistent memory without a valid PS flash
layout in it. That is the case when it is the first time in the device
- life that the SST service is executed.
-- ``SST_VALIDATE_METADATA_FROM_FLASH``- this flag allows to
+ life that the PS service is executed.
+- ``PS_VALIDATE_METADATA_FROM_FLASH``- this flag allows to
enable/disable the validation mechanism to check the metadata store in flash
every time the flash data is read from flash. This validation is required
if the flash is not hardware protected against malicious writes. In case
the flash is protected against malicious writes (i.e embedded flash, etc),
this validation can be disabled in order to reduce the validation overhead.
-- ``SST_ROLLBACK_PROTECTION``- this flag allows to enable/disable
- rollback protection in secure storage service. This flag takes effect only
- if the target has non-volatile counters and ``SST_ENCRYPTION`` flag is on.
-- ``SST_RAM_FS``- this flag allows to enable/disable the use of RAM
- instead of the flash to store the FS in secure storage service. This flag
+- ``PS_ROLLBACK_PROTECTION``- this flag allows to enable/disable
+ rollback protection in protected storage service. This flag takes effect only
+ if the target has non-volatile counters and ``PS_ENCRYPTION`` flag is on.
+- ``PS_RAM_FS``- this flag allows to enable/disable the use of RAM
+ instead of the flash to store the FS in protected storage service. This flag
is set by default in the regression tests, if it is not defined by the
- platform. The SST regression tests reduce the life of the flash memory
+ platform. The PS regression tests reduce the life of the flash memory
as they write/erase multiple times in the memory.
.. Note::
@@ -340,16 +340,16 @@ needs. The list of SST services flags are:
specific (QSPI, eFlash, etc.) and it is described in corresponding
flash_layout.h
-- ``SST_TEST_NV_COUNTERS``- this flag enables the virtual
- implementation of the SST NV counters interface in
- ``test/suites/sst/secure/nv_counters``, which emulates NV counters in
+- ``PS_TEST_NV_COUNTERS``- this flag enables the virtual
+ implementation of the PS NV counters interface in
+ ``test/suites/ps/secure/nv_counters``, which emulates NV counters in
RAM, and disables the hardware implementation of NV counters provided by
the secure service. This flag is enabled by default when building the
regression tests and disabled by default otherwise. This flag can be
overridden to ``OFF`` when building the regression tests. In this case,
- the SST rollback protection test suite will not be built, as it relies
+ the PS rollback protection test suite will not be built, as it relies
on extra functionality provided by the virtual NV counters to simulate
- different rollback scenarios. The remainder of the SST test suites will
+ different rollback scenarios. The remainder of the PS test suites will
run using the hardware NV counters. Please note that running the tests in
this configuration will quickly increase the hardware NV counter values,
which cannot be decreased again.
diff --git a/docs/user_guides/services/tfm_secure_partition_addition.rst b/docs/user_guides/services/tfm_secure_partition_addition.rst
index 174ae4e973..774220a4a8 100644
--- a/docs/user_guides/services/tfm_secure_partition_addition.rst
+++ b/docs/user_guides/services/tfm_secure_partition_addition.rst
@@ -152,7 +152,7 @@ Here is the Secure Partition ID table used in TF-M.
**Partition name** **Partition ID**
=============================== =================
Reserved 0-255
- TFM_SP_STORAGE 256
+ TFM_SP_PS 256
TFM_SP_ITS 257
TFM_SP_AUDIT_LOG 258
TFM_SP_CRYPTO 259
@@ -164,7 +164,7 @@ Here is the Secure Partition ID table used in TF-M.
TFM_SP_IPC_SERVICE_TEST 265
TFM_SP_IPC_CLIENT_TEST 266
TFM_IRQ_TEST_1 267
- TFM_SP_SST_TEST 268
+ TFM_SP_PS_TEST 268
=============================== =================
About where to add the definition, please refer to the chapter `Add
@@ -188,7 +188,7 @@ Here is the RoT Service ID table used in TF-M.
audit_logging 0x00000 0x000-0x01F
initial_attestation 0x00000 0x020-0x03F
platform 0x00000 0x040-0x05F
- secure_storage 0x00000 0x060-0x07F
+ protected_storage 0x00000 0x060-0x07F
crypto 0x00000 0x080-0x09F
internal_trusted_storage 0x00000 0x0A0-0x0BF
test_secure_service 0x0000F 0x000-0x01F
@@ -197,7 +197,7 @@ Here is the RoT Service ID table used in TF-M.
tfm_ipc_client 0x0000F 0x060-0x07F
tfm_ipc_service 0x0000F 0x080-0x09F
tfm_irq_test_service_1 0x0000F 0x0A0-0x0BF
- tfm_sst_test_service 0x0000F 0x0C0-0x0DF
+ tfm_ps_test_service 0x0000F 0x0C0-0x0DF
=========================== ====================== ========================
mmio_regions
@@ -349,4 +349,4 @@ Reference
--------------
-*Copyright (c) 2019-2020, Arm Limited. All rights reserved.* \ No newline at end of file
+*Copyright (c) 2019-2020, Arm Limited. All rights reserved.*
diff --git a/docs/user_guides/tfm_build_instruction.rst b/docs/user_guides/tfm_build_instruction.rst
index 8ed8c2db0b..de910adde6 100644
--- a/docs/user_guides/tfm_build_instruction.rst
+++ b/docs/user_guides/tfm_build_instruction.rst
@@ -91,7 +91,7 @@ API compliance NS test libraries when using the ``ConfigPsaApiTest.cmake``,
file. The build system assumes that the PSA API compliance test suite is checked
out at the same level of the TF-M root folder and the default name for the build
folder has been used when compiling the PSA API compliance tests. Each set of
-tests for the Internal Trusted Storage, Secure Storage, Crypto and Attestation
+tests for the Internal Trusted Storage, Protected Storage, Crypto and Attestation
services needs to be enabled at the build configuration step by defining::
-DPSA_API_TEST_INTERNAL_TRUSTED_STORAGE=ON
diff --git a/docs/user_guides/tfm_integration_guide.rst b/docs/user_guides/tfm_integration_guide.rst
index d320a0e088..09e43a0e85 100644
--- a/docs/user_guides/tfm_integration_guide.rst
+++ b/docs/user_guides/tfm_integration_guide.rst
@@ -67,7 +67,7 @@ have to be provided, e.g. to blink LEDs or count time in the MPS2 board.
.. Note::
- Currently SST and BL2 bootloader use different flash interface
+ Currently ITS, PS and BL2 bootloader use different flash interface
Target configuration files
==========================
@@ -104,13 +104,13 @@ The files needed for the interface with TF-M are exported at the
``<build_dir>/install/export/tfm`` path. The NS side is only allowed to call
TF-M secure functions (veneers) from the NS Thread mode. For this reason, the
API is a collection of functions in the ``<build_dir>/install/export/tfm/inc``
-directory. For example, the interface for the Secure STorage (SST) service
-is described in the file ``psa_sst_api.h`` as a collection of functions that
+directory. For example, the interface for the Protected Storage (PS) service
+is described in the file ``psa_ps_api.h`` as a collection of functions that
call service veneer functions. This API is a wrapper for the secure veneers,
and returns the return value from the service to the caller.
-The secure storage service uses a numerical ID, to identify the clients that use
-the service. For details see
+The protected storage service uses a numerical ID, to identify the clients that
+use the service. For details see
:doc:`ns client identification documentation <tfm_ns_client_identification>`.
Interface with non-secure world regression tests
@@ -123,7 +123,7 @@ i.e. ``<build_dir>/install/export/tfm/test/inc``. The non-secure regression
tests are precompiled and delivered as a static library which is available in
``<build_dir>/install/export/tfm/test/lib``, so that the non-secure application
needs to link against the library to be able to invoke the
-``tfm_non_secure_client_run_tests()`` function. The SST non-secure side
+``tfm_non_secure_client_run_tests()`` function. The PS non-secure side
regression tests rely on some OS functionality e.g. threads, mutexes etc. These
functions comply with CMSIS RTOS2 standard and have been exported as thin
wrappers defined in ``os_wrapper.h`` contained in
@@ -148,4 +148,4 @@ interrupt.
--------------
-*Copyright (c) 2017-2019, Arm Limited. All rights reserved.*
+*Copyright (c) 2017-2020, Arm Limited. All rights reserved.*
diff --git a/docs/user_guides/tfm_ns_client_identification.rst b/docs/user_guides/tfm_ns_client_identification.rst
index 9faccfb243..44fd3435ad 100644
--- a/docs/user_guides/tfm_ns_client_identification.rst
+++ b/docs/user_guides/tfm_ns_client_identification.rst
@@ -1,7 +1,7 @@
###########################
Non-Secure Identity Manager
###########################
-The ID of the current application/thread is known by TF-M, and the SST service
+The ID of the current application/thread is known by TF-M, and the PS service
queries the ID of the currently running client via a dedicated API.
The identity of secure clients can be tracked by TF-M core, because it also
@@ -40,4 +40,4 @@ client ID to it automatically.
--------------
-*Copyright (c) 2018-2019, Arm Limited. All rights reserved.*
+*Copyright (c) 2018-2020, Arm Limited. All rights reserved.*
diff --git a/docs/user_guides/tfm_secure_boot.rst b/docs/user_guides/tfm_secure_boot.rst
index a62d836759..917d018700 100644
--- a/docs/user_guides/tfm_secure_boot.rst
+++ b/docs/user_guides/tfm_secure_boot.rst
@@ -568,7 +568,7 @@ The following message will be shown in case of successful firmware upgrade:
[Sec Thread] Secure image initializing!
#### Execute test suites for the Secure area ####
- Running Test Suite PSA protected storage S interface tests (TFM_SST_TEST_2XXX)...
+ Running Test Suite PSA protected storage S interface tests (TFM_PS_TEST_2XXX)...
...
To update the secure and non-secure images separately (multiple image boot),
@@ -617,7 +617,7 @@ following message will be shown in case of successful firmware upgrades:
[Sec Thread] Jumping to non-secure code...
#### Execute test suites for the Secure area ####
- Running Test Suite PSA protected storage S interface tests (TFM_SST_TEST_2XXX)...
+ Running Test Suite PSA protected storage S interface tests (TFM_PS_TEST_2XXX)...
...
Swapping firmware upgrade
@@ -646,7 +646,7 @@ swapped:
[Sec Thread] Secure image initializing!
#### Execute test suites for the Secure area ####
- Running Test Suite PSA protected storage S interface tests (TFM_SST_TEST_2XXX)...
+ Running Test Suite PSA protected storage S interface tests (TFM_PS_TEST_2XXX)...
...
Non-swapping firmware upgrade
@@ -723,7 +723,7 @@ notice that image with higher version number (``version=1.2.3.5``) is executed:
[Sec Thread] Secure image initializing!
#### Execute test suites for the Secure area ####
- Running Test Suite PSA protected storage S interface tests (TFM_SST_TEST_2XXX)...
+ Running Test Suite PSA protected storage S interface tests (TFM_PS_TEST_2XXX)...
...
Executing firmware upgrade on CoreLink SSE-200 Subsystem for MPS3 (AN524)
diff --git a/docs/user_guides/tfm_user_guide.rst b/docs/user_guides/tfm_user_guide.rst
index 11061a2ca7..eaf33f66af 100644
--- a/docs/user_guides/tfm_user_guide.rst
+++ b/docs/user_guides/tfm_user_guide.rst
@@ -131,30 +131,30 @@ port (baud 115200 8n1) the following messages::
[INF] Jumping to the first image slot
[Sec Thread] Secure image initializing!
- #### Execute test suites for the secure storage service ####
- Running Test Suite SST secure interface tests (TFM_SST_TEST_2XXX)...
+ #### Execute test suites for the protected storage service ####
+ Running Test Suite PS secure interface tests (TFM_PS_TEST_2XXX)...
- > Executing 'TFM_SST_TEST_2001'
+ > Executing 'TFM_PS_TEST_2001'
Description: 'Create interface'
TEST PASSED!
- > Executing 'TFM_SST_TEST_2002'
+ > Executing 'TFM_PS_TEST_2002'
Description: 'Get handle interface (DEPRECATED)'
This test is DEPRECATED and the test execution was SKIPPED
TEST PASSED!
- > Executing 'TFM_SST_TEST_2003'
+ > Executing 'TFM_PS_TEST_2003'
Description: 'Get handle with null handle pointer (DEPRECATED)'
This test is DEPRECATED and the test execution was SKIPPED
TEST PASSED!
- > Executing 'TFM_SST_TEST_2004'
+ > Executing 'TFM_PS_TEST_2004'
Description: 'Write interface'
TEST PASSED!
- > Executing 'TFM_SST_TEST_2005'
+ > Executing 'TFM_PS_TEST_2005'
Description: 'Read interface'
....
.. Note::
- SST reliability tests take a few minutes to run on the MPS2.
+ PS reliability tests take a few minutes to run on the MPS2.
Example application without BL2 bootloader
------------------------------------------
@@ -187,24 +187,24 @@ port (baud 115200 8n1) the following messages::
[Sec Thread] Secure image initializing!
- #### Execute test suites for the secure storage service ####
- Running Test Suite SST secure interface tests (TFM_SST_TEST_2XXX)...
+ #### Execute test suites for the protected storage service ####
+ Running Test Suite PS secure interface tests (TFM_PS_TEST_2XXX)...
- > Executing 'TFM_SST_TEST_2001'
+ > Executing 'TFM_PS_TEST_2001'
Description: 'Create interface'
TEST PASSED!
- > Executing 'TFM_SST_TEST_2002'
+ > Executing 'TFM_PS_TEST_2002'
Description: 'Get handle interface (DEPRECATED)'
This test is DEPRECATED and the test execution was SKIPPED
TEST PASSED!
- > Executing 'TFM_SST_TEST_2003'
+ > Executing 'TFM_PS_TEST_2003'
Description: 'Get handle with null handle pointer (DEPRECATED)'
This test is DEPRECATED and the test execution was SKIPPED
TEST PASSED!
- > Executing 'TFM_SST_TEST_2004'
+ > Executing 'TFM_PS_TEST_2004'
Description: 'Write interface'
TEST PASSED!
- > Executing 'TFM_SST_TEST_2005'
+ > Executing 'TFM_PS_TEST_2005'
Description: 'Read interface'
....
@@ -286,23 +286,23 @@ DAPLink UART (baud 115200 8n1)::
[INF] Jumping to the first image slot
[Sec Thread] Secure image initializing!
- #### Execute test suites for the secure storage service ####
- Running Test Suite SST secure interface tests (TFM_SST_TEST_2XXX)...
- > Executing 'TFM_SST_TEST_2001'
+ #### Execute test suites for the protected storage service ####
+ Running Test Suite PS secure interface tests (TFM_PS_TEST_2XXX)...
+ > Executing 'TFM_PS_TEST_2001'
Description: 'Create interface'
TEST PASSED!
- > Executing 'TFM_SST_TEST_2002'
+ > Executing 'TFM_PS_TEST_2002'
Description: 'Get handle interface (DEPRECATED)'
This test is DEPRECATED and the test execution was SKIPPED
TEST PASSED!
- > Executing 'TFM_SST_TEST_2003'
+ > Executing 'TFM_PS_TEST_2003'
Description: 'Get handle with null handle pointer (DEPRECATED)'
This test is DEPRECATED and the test execution was SKIPPED
TEST PASSED!
- > Executing 'TFM_SST_TEST_2004'
+ > Executing 'TFM_PS_TEST_2004'
Description: 'Get attributes interface'
TEST PASSED!
- > Executing 'TFM_SST_TEST_2005'
+ > Executing 'TFM_PS_TEST_2005'
Description: 'Get attributes with null attributes struct pointer'
....
@@ -396,17 +396,17 @@ port (baud 115200 8n1) the following messages::
[Sec Thread] Secure image initializing!
#### Execute test suites for the Secure area ####
- Running Test Suite PSA protected storage S interface tests (TFM_SST_TEST_2XXX)...
- > Executing 'TFM_SST_TEST_2001'
+ Running Test Suite PSA protected storage S interface tests (TFM_PS_TEST_2XXX)...
+ > Executing 'TFM_PS_TEST_2001'
Description: 'Set interface'
TEST PASSED!
- > Executing 'TFM_SST_TEST_2002'
+ > Executing 'TFM_PS_TEST_2002'
Description: 'Set interface with create flags'
TEST PASSED!
- > Executing 'TFM_SST_TEST_2003'
+ > Executing 'TFM_PS_TEST_2003'
Description: 'Set interface with NULL data pointer'
TEST PASSED!
- > Executing 'TFM_SST_TEST_2004'
+ > Executing 'TFM_PS_TEST_2004'
Description: 'Set interface with invalid data length'
TEST PASSED!
....
@@ -449,17 +449,17 @@ port (baud 115200 8n1) the following messages::
[Sec Thread] Secure image initializing!
#### Execute test suites for the Secure area ####
- Running Test Suite PSA protected storage S interface tests (TFM_SST_TEST_2XXX)...
- > Executing 'TFM_SST_TEST_2001'
+ Running Test Suite PSA protected storage S interface tests (TFM_PS_TEST_2XXX)...
+ > Executing 'TFM_PS_TEST_2001'
Description: 'Set interface'
TEST PASSED!
- > Executing 'TFM_SST_TEST_2002'
+ > Executing 'TFM_PS_TEST_2002'
Description: 'Set interface with create flags'
TEST PASSED!
- > Executing 'TFM_SST_TEST_2003'
+ > Executing 'TFM_PS_TEST_2003'
Description: 'Set interface with NULL data pointer'
TEST PASSED!
- > Executing 'TFM_SST_TEST_2004'
+ > Executing 'TFM_PS_TEST_2004'
Description: 'Set interface with invalid data length'
TEST PASSED!
....