Enable x86_64 Linux stack guard for OP-TEE TAs - #1003
Enable x86_64 Linux stack guard for OP-TEE TAs#1003Sangho Lee (sangho2) wants to merge 5 commits into
x86_64 Linux stack guard for OP-TEE TAs#1003Conversation
e3d2fee to
95eeab4
Compare
404623d to
e846962
Compare
Sangho Lee (sangho2)
changed the title
x86_64 Linux style stack guard for OP-TEE TAs
Sangho Lee (sangho2)
changed the title
x86_64 Linux style stack guard for OP-TEE TAsx86_64 Linux stack guard for OP-TEE TAs
c1e84e9 to
3ac4e34
Compare
|
🤖 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. |
|
Weiteng Chen (@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. |
Weiteng Chen (CvvT)
left a comment
Weiteng Chen (CvvT)
left a comment
There was a problem hiding this comment.
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).
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 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, |
The latest OP-TEE (for Arm) now does this TLS allocation in user-mode |
Sangho Lee (sangho2)
added
discussion
| self.restore_guest_tls(); | ||
| /// The x86-64 toolchain emits stack-protector accesses to `%fs:0x28`. | ||
| /// Normally glibc or musl initializes that ABI slot before application code | ||
| /// runs. OP-TEE TAs use neither runtime, so the shim must provide and |
There was a problem hiding this comment.
OP-TEE TAs use neither runtime
Is this specific to TAs running in LiteBox?
There was a problem hiding this comment.
this is a stale/draft PR.
The main issue is that libutee we are using is unaware of x86-gcc/libc's convention, such that it does not prepare FSBase as gcc expects. Revising the devkit (or its build configuration) would be a fundamental solution.
| #[cfg(target_arch = "x86_64")] | ||
| fn restore_guest_tls(&self) { | ||
| /// Restore the guest FS base so `%fs:0x28` reads the stack guard page. | ||
| fn restore_stack_guard_fs_base(&self) { |
There was a problem hiding this comment.
nit: As you are setting FSBase register value here, restore in the function name is a bit confusing.
There was a problem hiding this comment.
Using restore here because user-mode LiteBox and guests share FSBase.
4 participants
This PR enables stack guard for OP-TEE TAs. Currently, we use
x86_64Linux 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.