Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changes continue_execution to not clobber stack that may be in use. #217

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

deeglaze
Copy link
Contributor

We use the exception handler to implement cpuid. To get that to work we have to ensure more of the stack is available. continue_execution should not store the instruction address for resumption in a part
of the stack that is likely in use. Otherwise, it stores it at the next stack location, which at least OPENSSL_cpuid has in use at the time of CPUID execution, corrupting important information.

@lzha101
Copy link
Contributor

lzha101 commented Mar 2, 2018

Do you have a sample to reproduce this? The ssa_gpr->xsp saves the stack pointer of the function in which the exception happens. Suppose the code should not save data to the stack area that above the top of the stack. So it should be OK for trts exception handling to setup a new stack frame for continue_execution and save the ip on it. It is weird that your code needs to access the stack area above the top of the stack.

BTW, are you trying to use OpenSSL inside enclave? FYI, we have an SGXSSL for that use.

@deeglaze
Copy link
Contributor Author

deeglaze commented Mar 2, 2018

We're using BoringSSL, Google's vetted SSL library. It weirdly uses stack beyond RSP. I'll confer with my team about what exactly is the problem and update you tomorrow.

@deeglaze
Copy link
Contributor Author

deeglaze commented Mar 2, 2018

This change is to support programs that are compiled with stack red zones. I can see about making a repro test if y'all need.

Signed-off-by: Dionna Glaze <dionnaglaze@google.com>
@deeglaze
Copy link
Contributor Author

deeglaze commented Mar 5, 2018

I pushed an update to this PR that explains the red zone situation a bit more. I think at the very least internal_handle_exception should be annotated with __attribute__((interrupt)) to play nicely with red zones when the compiler can handle it.

@lzha101
Copy link
Contributor

lzha101 commented Mar 9, 2018

The changes may cause problem for 32 bit mode as 32 bit doesn't have red zone. Could you help verify if this commit works for you? lzha101@f361038

@deeglaze
Copy link
Contributor Author

deeglaze commented Mar 9, 2018

That commit causes a crash for us. Externalizing a repro would probably be more work than just roundtripping with me at this time, unfortunately.

@lzha101
Copy link
Contributor

lzha101 commented Mar 12, 2018

It's weird. Of cause, could you provide a test repo?

# Offset the stack to avoid the red zone, which interrupts are allowed to
# write into. Using the __attribute__((interrupt)) on internal_handle_exception
# is hostile to older compilers.
mov %xcx, -128(%xax) # save xip to the new stack
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The patch doesn't really avoid the red zone, right? From this line, it saves the xip at the bottom of the red zone but it is still inside the red zone.

@deeglaze
Copy link
Contributor Author

Okay, I just double and triple checked y'all's suggested patch and it indeed works for us. Sorry for the mixup.

@lzha101
Copy link
Contributor

lzha101 commented Mar 16, 2018

I create another PR #231 for the red zone fix. Could you help review it? If it is OK, we will merge it later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants