Enable x86_64 Linux stack guard for OP-TEE TAs

[sangho2]

This PR enables stack guard for OP-TEE TAs. Currently, we use x86_64 Linux toolchains to build OP-TEE TA binaries with -fstack-protector (enabled by default), which expects glibc/musl stores a stack canary value in %fs:0x28. However, OP-TEE TAs don't use glibc/musl such that no code prepares memory for this. This PR lets the OP-TEE shim allocate, initialize (with a random number), and protect a stack guard page.

[github-actions]

🤖 SemverChecks 🤖 No breaking API changes detected

Note: this does not mean API is unchanged, or even that there are no breaking changes; simply, none of the detections triggered.

[wdcui]

@CvvT , can you also take a look at this PR? The current approach feels a little hacky to me. It would be good to see if you have any suggestions.

[CvvT]

Looks like the fix is about setting the canary and page permission properly; I don't see why the rest of the change (i.e., renaming stuffs) is necessary. I feel allocate_guest_tls is more accurate than allocate_stack_guard_page (the later one sounds like we allocate a guard page for stack, but the page is for tls; we just initialize the canary in it).

[CvvT]

@CvvT , can you also take a look at this PR? The current approach feels a little hacky to me. It would be good to see if you have any suggestions.

I don't have a better idea. The hardcoded offset looks fine to me (it's a fixed value per target ABI). If we cannot control how to compile the TAs, I don't think there is other way around it.

[sangho2]

Looks like the fix is about setting the canary and page permission properly; I don't see why the rest of the change (i.e., renaming stuffs) is necessary. I feel allocate_guest_tls is more accurate than allocate_stack_guard_page (the later one sounds like we allocate a guard page for stack, but the page is for tls; we just initialize the canary in it).

The reference OP-TEE version (which is outdated btw) doesn't use thread pointers at all. That's why I thought the guest TLS is misleading. I've checked the lasted OP-TEE (for Arm) and confirmed that it now has guest TLS just for compiler compatibility (like this PR). In that sense, allocate_guest_tls does make sense. Let me revert this name change.

[sangho2]

@CvvT , can you also take a look at this PR? The current approach feels a little hacky to me. It would be good to see if you have any suggestions.

I don't have a better idea. The hardcoded offset looks fine to me (it's a fixed value per target ABI). If we cannot control how to compile the TAs, I don't think there is other way around it.

The latest OP-TEE (for Arm) now does this TLS allocation in user-mode libutee for compiler compatibility (like this PR). Our reference OP-TEE (for x86) is, unfortunately, pretty outdated and thus doesn't have this code. We could get rid of this hack once our toolchain gets updated (no ETA AFAIK).