-
Notifications
You must be signed in to change notification settings - Fork 692
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
Fix for a crasher due to misaligned stack on x86-32. #32
Merged
Conversation
This file contains 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
Full information on reproduction (using Python's ctypes available here: http://bugs.python.org/issue17423)
ghost
assigned atgreen
Mar 16, 2013
atgreen
added a commit
that referenced
this pull request
Mar 16, 2013
Fix for a crasher due to misaligned stack on x86-32.
atgreen
added a commit
that referenced
this pull request
Mar 16, 2013
Fix for a crasher due to misaligned stack on x86-32.
This was referenced Jul 19, 2019
billatarm
added a commit
to billatarm/libffi
that referenced
this pull request
May 10, 2024
The debug stack gets corrupted between the frame and stack pivots, update the CFI directives so the call stack stays correct in the debugger. str x9, [x1, libffi#32] // stack is ffi_call_SYSV() -> ffi_call_int() -> ffi_call_int() -> main() (good) mov x29, x1 // stack is ffi_call_SYSV() -> ffi_call_int() -> ffi_call_int() -> ffi_call() -> main() (bad) mov sp, x0 // stack is ffi_call_SYSV() -> ffi_call_int() -> ffi_call_int() -> main() (good) The CFA data needs to be updated around the pivots, after this patch the callstack stays correct. Signed-off-by: Bill Roberts <bill.roberts@arm.com>
atgreen
pushed a commit
that referenced
this pull request
Jun 1, 2024
* aarch64: fix callstack in ffi_call_SYSV The debug stack gets corrupted between the frame and stack pivots, update the CFI directives so the call stack stays correct in the debugger. str x9, [x1, #32] // stack is ffi_call_SYSV() -> ffi_call_int() -> ffi_call_int() -> main() (good) mov x29, x1 // stack is ffi_call_SYSV() -> ffi_call_int() -> ffi_call_int() -> ffi_call() -> main() (bad) mov sp, x0 // stack is ffi_call_SYSV() -> ffi_call_int() -> ffi_call_int() -> main() (good) The CFA data needs to be updated around the pivots, after this patch the callstack stays correct. Signed-off-by: Bill Roberts <bill.roberts@arm.com> * aarch64: remove uneeded CFI directive This directive doesn't actually set the CFA to anything valid, and during unwinding this isn't even used. Note that the PAC/Darwin usage is quite suspect as well, as the CFA is either x1 or x29 after the frame pivot, and the CFA address is what's used as the modifier when verifying the PAC. At least this is the behavior on Linux with PAC, I need to verify ARME ABI unwinding. So for now leave Darwin as is. Signed-off-by: Bill Roberts <bill.roberts@arm.com> * ptrauth: rename define for clarity Rename the HAVE_PTRAUTH define for clarity that its associated with the ARM64E ABI and not the ARM64 ABI that can be supported on Linux and enabled with -mbranch-protection=standard. Signed-off-by: Bill Roberts <bill.roberts@arm.com> * aarch64: add PAC support to ffi_call_SYSV Support AARCH64 Pointer Authentication Codes (PAC) within ffi_call_SYSV and support exception unwinding. The Linux ABI for PAC is to use paciasp/autiasp instructions which also have hint space equivelent instructions. They sign the LR (x30) with the A key and the current stack pointer as the salt. Note that this can also be configured to use the B key and will use pacibsp/autibsp hint instructions. The Linux ABI for exception frame data when PAC is enabled assumes that the Connonical Frame Address, or CFA is equal to the stack pointer. I.E sp is equal to x29 (fp). When the unwinder is invoked the cfa will point to the frame which will include the *signed* return address from the LR. This will then be passed to __builtin_aarch64_autia1716 where the CFA will be used as the salt and stored to register x16 and register x17 will contain the signed address to demangle. This can be noted in: - https://github.com/gcc-mirror/gcc/blob/d6d7afcdbc04adb0ec42a44b2d7e05600945af42/libgcc/config/aarch64/aarch64-unwind.h#L56 The other required portion of this is to indicate to the unwinder that this is a signed address that needs to go the special demangle route in the unwinder. This is accomplished by using CFI directive "cfi_window_save" which marks that frame as being signed. Putting all of this together is a bit tricky, as the internals of ffi_call_SYSV the callee allocates its stack and frame and passes it in arg1 (x0) and arg2 (x1) to the called function, where that function pivots its stack, so care must be taken to get the sp == fp before paciasp is called and also restore that state before autiasp is called. Signed-off-by: Bill Roberts <bill.roberts@arm.com> --------- Signed-off-by: Bill Roberts <bill.roberts@arm.com>
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.
Full information on reproduction (using Python's ctypes available here: http://bugs.python.org/issue17423)