Repository navigation
Conversation
|
dgarske
force-pushed
the
optee_platform
branch
from
October 29, 2026 20:46
daf5a54 to
45afe97
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Extending the new
WOLFSSL_OPTEEbuild option added in #11919 making a trusted OP-TEE application work without a per-project platform file.types.h- aWOLFSSL_OPTEEbranch in the allocator chain, mappingXMALLOC,XFREEandXREALLOContoTEE_Malloc,TEE_FreeandTEE_Realloc. A trusted application links libutee rather than a C library and has no std heap.TEE_MALLOC_FILL_ZERO, so an allocation never carries another one's bytes. Placed afterXMALLOC_OVERRIDEso an explicit override still wins, and shaped like theWOLFSSL_TELIT_M2MBbranch beside it, including theWOLFSSL_XFREE_NO_NULLNESS_CHECKvariant.random.c- awc_GenerateSeedforWOLFSSL_OPTEEonTEE_GenerateRandom, plus the matching entry in the platform include chain. It seeds the DRBG rather than replacing it, so a build that would rather use the TEE RNG directly can still setCUSTOM_RAND_GENERATE_BLOCK.internal.c,tls13.c,benchmark.c-LowResTimer, bothTimeNowInMillisecondsvariants andcurrent_timefromTEE_GetSystemTime, which is monotonic for the life of the trusted application and is not the normal world's clock, so it cannot be steered from outside.settings.hno longer forcesUSER_TICKS, which existed only because nothing supplied these; a project can still define it to override.wc_port.h,wc_port.c-XTIMEfromTEE_GetREETime. That is the only wall clock a trusted application can reach and the normal world owns it, so it is fit for freshness and logging, not for deciding certificate validity. TheWOLFSSL_OPTEEblock keepsNO_ASN_TIMEfor that reason, and a port that turns it off is choosing to trust the rich OS clock.Testing
Validated on an NVIDIA Jetson Orin Nano (L4T R36.4.4), building the wolfTPM firmware TPM into an OP-TEE trusted application. With these changes the trusted application drops its platform file and its allocator and RNG overrides entirely, and still passes RSA, ECC, AES-CFB, NV, SHA-256, HMAC, PCR and ML-DSA / ML-KEM sign, verify, encapsulate and decapsulate, including the tampered-signature and tampered-ciphertext negative cases.
The time arms sit inside
#ifndef NO_ASN_TIME, which theWOLFSSL_OPTEEblock sets, so a default OP-TEE build does not reach them. They were compiled against the OP-TEE headers with the trusted application toolchain to confirm the TEE API use. TLS has not been run inside a trusted application.--enable-allbuilds clean on Linux withWOLFSSL_OPTEEundefined, which is where all of this is inert.