Branches

rust-spmc

WARNING This is an experimental project.

The project implements an S-EL1 Secure Partition Manager Core component as defined in the FF-A specification. Its main goal is to compartmentalize S-EL0 secure partitions (SP) and process the messages between SPs and the normal world. The projects aims for utilizing the safety guarantees offered by the Rust language in a secure world component.

The rust-spmc can work as a drop in replacement of OP-TEE SPMC and run the S-EL0 SPs of Trusted Services.

Additional features

SP loading from TF-A's FIP package
Raw binary format SP support
SP manifest handling (memory/device regions)
Multi-core support
UART log output

Supported platforms

Arm FVP

Prerequisites

Stable Rust toolchain (tested with rustc 1.74.0 (79e9716c9 2023-11-13))
cargo-binutils
cargo-make
Prerequisites of OP-TEE build

Build and run

The reference build uses the OP-TEE SPMC's build system to build the complete environment including Trusted Firmware A, Trusted Services and Linux. By setting the necessary environment variables the build system is instructed to place rust-spmc's binary into the FIP image and start the FVP.

Build rust-spmc

Clone the rust-spmc into a directory. The project has two build targets. build-debug builds rust-spmc with the debug cargo profile. build-release first builds and runs the tests and then builds rust-spmc using the release cargo profile. The output binary will be rust-spmc.bin and it will be placed in the root directory of the project.

cd /path/to/rust-spmc
cargo make build-debug
# or
cargo make build-release

Build system images and run the SPMC with trusted-services

This example hooks OP-TEE's build system and configures it to include rust-spmc instead of OP-TEE SPMC. The script below contains the following steps.

Fetch OP-TEE build system into a separate directory
Fetch toolchains
Configure, build and run the system
- FVP_PATH - Should point to a directory which contains the FVP
- DEFAULT_SP_CONFIG=default-sp - Select 'flat binary' format for the secure partitions of Trusted Services.
- SP_PACKAGING_METHOD=fip - Use TF-A's FIP image to store secure partitions
- OPTEE_OS_PAGER_V2_BIN=/path/to/rust-spmc/rust-spmc.bin - Replace OP-TEE binary with rust-spmc. It should point to the rust-spmc binary as built in the previous section.
- The run target builds both normal and secure world components and then starts the FVP.

For more detailed description see OP-TEE's or Trusted Services' build documentation.

# Fetch project
mkdir /path/to/optee
cd /path/to/optee
repo init -u https://github.com/OP-TEE/manifest.git -b 4.0.0 -m fvp-ts.xml
repo sync

# Fetch toolchains
cd build
make -j2 toolchains

# Build and run
FVP_PATH=/path/to/fvp/Base_RevC_AEMvA_pkg/models/Linux64_GCC-9.3 \
DEFAULT_SP_CONFIG=default-sp \
SP_PACKAGING_METHOD=fip \
OPTEE_OS_PAGER_V2_BIN=/path/to/rust-spmc/rust-spmc.bin \
make run -j`nproc`

After booting the system log in to the system as root:[no password] and run Trusted Services test as described here.

Test

Build and run the host tests by running the test target.

cargo make test

Clippy

Run the Rust linter (clippy) for the target code and host test code.

cargo make clippy

Documentation

Generate documentation which includes this file and all the module descriptions by running the doc target. The rendered documentation will be available at rust-spmc/target/aarch64-unknown-none-softfloat/doc/rust_spmc/index.html.

cargo make doc

License

The project is MIT and Apache-2.0 dual licensed, see LICENSE-APACHE and LICENSE-MIT.

Maintainers

rust-spmc is a trustedfirmware.org maintained project. All contributions are ultimately merged by the maintainers listed below. Technical ownership of some parts of the code-base is delegated to the code owners listed below. An acknowledgment from these code maintainers may be required before the maintainers merge a contribution.

Main maintainers

Bálint Dobszay balint.dobszay@arm.com balint-dobszay-arm
György Szing gyorgy.szing@arm.com gyuri-szing
Imre Kis imre.kis@arm.com imre-kis-arm

Code owners

Bálint Dobszay balint.dobszay@arm.com balint-dobszay-arm
Imre Kis imre.kis@arm.com imre-kis-arm

Contributing

Reporting Security Issues

Please follow the directions of the Trusted Firmware Security Center

Getting Started

Make sure you have a GitHub account and you are logged on developer.trustedfirmware.org.
Send an email to the maintainers about your work.
Clone the repository on your own machine.

Making Changes

Make commits of logical units. See these general Git guidelines for contributing to a project.
Keep the commits on topic. If you need to fix another bug or make another enhancement, please create a separate change.
Avoid long commit series. If you do have a long series, consider whether some commits should be squashed together or addressed in a separate topic.
Make sure your commit messages are in the proper format. Please keel the 50/72 rule (for details see Tim Popes blog entry)
Where appropriate, please update the documentation.
- Consider which documents or other in-source documentation needs updating.
- Ensure that each changed file has the correct copyright and license information. Files that entirely consist of contributions to this project should have a copyright notice and license identifier. Files that contain changes to imported Third Party IP files should retain their original copyright and license notices. For significant contributions you may add your own copyright notice in following format
```
// SPDX-FileCopyrightText: Copyright [XXXX-]YYYY <OWNER>
// SPDX-License-Identifier: MIT OR Apache-2.0
```
  where XXXX is the year of first contribution (if different to YYYY) and YYYY is the year of most recent contribution. <OWNER> is your name or your company name.
- For any change, ensure that YYYY is updated if a contribution is made in a year more recent than the previous YYYY.
- If you are submitting new files that you intend to be the technical sub-maintainer for (for example, a new platform port), then also update the MAINTAINERS file.
- For topics with multiple commits, you should make all documentation changes (and nothing else) in the last commit of the series. Otherwise, include the documentation changes within the single commit.
Please test your changes.

Submitting Changes

Ensure that each commit in the series has at least one Signed-off-by: line, using your real name and email address. The names in the Signed-off-by: and Author: lines must match. If anyone else contributes to the commit, they must also add their own Signed-off-by: line. By adding this line the contributor certifies the contribution is made under the terms of the dco.txt.
More details may be found in the Gerrit Signed-off-by Lines guidelines.
Ensure that each commit also has a unique Change-Id: line. If you have cloned the repository with the "Clone with commit-msg hook" clone method, this should already be the case.
More details may be found in the Gerrit Change-Ids documentation.
Submit your changes for review at https://review.trustedfirmware.org targeting the integration branch.
- The changes will then undergo further review and testing by the maintainers. Any review comments will be made directly on your patch. This may require you to do some rework.
Refer to the Gerrit Uploading Changes documentation for more details.
When the changes are accepted, the maintainers will integrate them.
- Typically, the maintainers will merge the changes into the integration branch.
- If the changes are not based on a sufficiently-recent commit, or if they cannot be automatically rebased, then the maintainers may rebase it on the main branch or ask you to do so.
- After final integration testing, the changes will make their way into the main branch. If a problem is found during integration, the merge commit will be removed from the integration branch and the maintainers will ask you to create a new patch set to resolve the problem.

FF-A S-EL1 SPMC prototype implemented in Rust