Clean TA build environment about incubator-teaclave-trustzone-sdk

[DemesneGH]

Hi @syedelec

Thanks for your advice.

• avoid patching rust-lang, compiler-builtins and libc?
• use latest rust toolchains

The patching of rust-lang and other submodules are necessary for building TAs running on OP-TEE OS. In addition, the other solution is to release these dependencies as prebuilt libraries. But AFAIK Rust and cargo don't support the pre-built libraries yet.

• use pre-built optee libutee.a/libutils.a and libteec.so libraries (to avoid pull optee os/client)

The OP-TEE libraries(for building TA,aka ta_dev_kit) are built when building OP-TEE OS. If you have already built OP-TEE OS, you can avoid building the OP-TEE libraries using export OPTEE_DIR=[YOUR_OPTEE_DIR], see the instructions here.

[syedelec]

Thanks for your inputs.

The patching of rust-lang and other submodules are necessary for building TAs running on OP-TEE OS. In addition, the other solution is to release these dependencies as pre-built libraries. But AFAIK Rust and cargo don't support the pre-built libraries yet.

I understand.
I am not rust expert, but I would like to suggest some modifications if possible to reduce workarounds.

Regarding this part of the code:

##########################################
# install Rust and select a proper version
curl https://sh.rustup.rs -sSf | sh -s -- -y --default-toolchain nightly-2021-09-20
source $HOME/.cargo/env
rustup component add rust-src && rustup target install aarch64-unknown-linux-gnu arm-unknown-linux-gnueabihf

# install Xargo
rustup default 1.44.0 && cargo +1.44.0 install xargo
# switch to nightly
rustup default nightly-2021-09-20

is it possible to use the latest nightly version (nightly-x86_64-unknown-linux-gnu) ? or why not the stable version (stable-x86_64-unknown-linux-gnu)?
Also why install xargo from specific 1.44.0 version and not use the stable/nightly version
Currently the script installs 2 toolchains (1.44.0 and nightly-2021-09-20) but only nightly-2021-09-20 is used for compilation and 1.44.0 is used to install xargo.

The OP-TEE libraries(for building TA,aka ta_dev_kit) are built when building OP-TEE OS. If you have already built OP-TEE OS, you can avoid building the OP-TEE libraries using export OPTEE_DIR=[YOUR_OPTEE_DIR], see the instructions here.

I agree. This a viable solution and I am using my own OP-TEE repos to build and it's working fine.

Finally, the source code is for rust, compiler-builtins and libc are taken from https://github.com/mesalock-linux org and these specific repos seems not updated. It would be great if the repos could be updated to a stable version and apply the single commit on top to get it working.

Again, these are suggestions and I would like to know if this is doable because I may get into it to clean repos and make it working with minimal workarounds.

Thanks

[DemesneGH]

Hi @syedelec

is it possible to use the latest nightly version (nightly-x86_64-unknown-linux-gnu) ?

Yes but not yet. When upgrading toolchains, the std should be upgraded to a proper version at the same time. Because the std code can only be compiled in a certain range of versions of the Rust toolchain.

why not the stable version (stable-x86_64-unknown-linux-gnu)?

No. The nightly version is needed for building customized std.

Also why install xargo from specific 1.44.0 version and not use the stable/nightly version

The toolchain for installing xargo can be upgraded to a newer version but we've not tested for it.

Finally, the source code is for rust, compiler-builtins and libc are taken from https://github.com/mesalock-linux org and these specific repos seems not updated. It would be great if the repos could be updated to a stable version and apply the single commit on top to get it working.

The rust, compiler-builtins and libc ported for OP-TEE are based on the stable Rust version 1.56.1. And the patch for OP-TEE is in mesalock-linux/rust@6abda66.

these are suggestions and I would like to know if this is doable because I may get into it to clean repos and make it working with minimal workarounds.

For simplification of the building environment, one considerable way is to add the aarch64-unknown-optee-trustzone target into the upstream Rust compiler repo. Then we can build binaries for this target by rustup target add aarch64-unknown-optee-trustzone.
But this needs more work to integrate the customized std into the Rust repo.

What are your needs for the minimal building environment? Any thoughts would be appreciated.

Thanks
Yuan

[syedelec]

Hi @DemesneGH

Sorry for late answer.
Thank you again for your valuable inputs/clarifications.

What are your needs for the minimal building environment? Any thoughts would be appreciated.

I already have a building environment for a library in Rust and I would like to integrate the TA (host + ta) and not build them separately. This is the main reason.

Thanks

[DemesneGH]

Hi @syedelec

I already have a building environment for a library in Rust and I would like to integrate the TA (host + ta) and not build them separately.

The toolchains for building host applications can be upgraded to the new version or changed to the other architecture(such as Android) as you want, because those are normal Linux binaries.
As for building TAs, the specific toolchains and the modified std are needed as stated above. Maybe you can try to include the source code of your library as the third-party crate in TA's Cargo.toml.

[syedelec]

Hi @DemesneGH

Thanks for your inputs! It's very helpful.