Align stack correctly when initializing a context #230
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
peadar
force-pushed
the
fix-stack-align
branch
from
7c5e59c to
f6e575f
Compare
For now, this just tests stack alignment in a context's entry point This test shows a problem when building on i386 with `-msse2`, where the compiler is allowed use some instructions that move data in and out of the xmm0-7 registers, requiring them to be aligned on 16-byte boundaries. Because the compiler will generally assume the stack is correctly aligned on entering a function, the misalignment will propagate through the stack until something uses an instruction that requires 16-byte alignment, and we get a segmentation fault. The misalignment happens because the stack is heap-allocated (and the heap allocator provides a properly aligned pointer), but we push the argument for the async task onto the stack as we call it, leaving the stack 4 bytes below proper alignment. The test is equally valid on x86_64, but the stack alignment is correct there - nothing is pushed onto the stack prior to calling the task function, as it's passed in a register.
In `my_context_spawn`, assuming the allocated stack pointer is 16-bye
aligned (as it will be from malloc, etc), align the stack correctly
before calling the target function of the context.
For i686 platform, The Linux ABI requires that the stack is aligned on a
16-byte boundary at the time that a call is made, and the compiler
attempts to maintain that alignment by adjusting the stack as required
to meet the alignment requirements for data, and any subsequent calls.
This is particularly important when compiling for i386 platform with
-msse2, The compiler can emit code to use SSE2 instructions like
`movaps`, which will actually fault on unalgned access. This causes the
mariadb test suite to fail with the following error, for example:
```
main.non_blocking_api w4 [ fail ]
Test ended at 2023-08-18 00:33:40
CURRENT_TEST: main.non_blocking_api
mysqltest got signal 11
read_command_buf (0x89a2a88): connect (con_nonblock,localhost,root,,test)
conn->name (0x89c7208):
Attempting backtrace...
stack_bottom = 0x0 thread_stack 0x10000
mysys/stacktrace.c:213(my_print_stacktrace)[0x80a7348]
bits/stdio2.h:97(fprintf)[0x80615f2]
addr2line: '': No such file
[0xf7ee8560]
??:0(BIO_f_buffer)[0xf7bc1ca1]
??:0(BIO_vsnprintf)[0xf7bc2aa1]
??:0(BIO_snprintf)[0xf7bc2af4]
??:0(ASN1_UTCTIME_adj)[0xf7be0875]
??:0(X509_time_adj_ex)[0xf7c062dd]
??:0(X509_time_adj)[0xf7c06312]
??:0(X509_cmp_time)[0xf7c06516]
??:0(X509_cmp_time)[0xf7c06720]
??:0(X509_verify_cert)[0xf7c08641]
??:0(ssl_verify_cert_chain)[0xf7d172e1]
??:0(ssl3_get_server_certificate)[0xf7cefc96]
??:0(ssl3_connect)[0xf7cf520b]
??:0(ssl23_connect)[0xf7cfee42]
secure/openssl.c:487(ma_tls_connect)[0x808ac22]
libmariadb/ma_tls.c:83(ma_pvio_tls_connect)[0x807d82d]
libmariadb/ma_pvio.c:531(ma_pvio_start_ssl)[0x807d553]
auth/my_auth.c:318(send_client_reply_packet)[0x808f5db]
auth/my_auth.c:94(native_password_auth_client)[0x808f84e]
auth/my_auth.c:620(run_plugin_auth)[0x808fb5c]
libmariadb/mariadb_lib.c:1665(mthd_my_real_connect)[0x807a121]
libmariadb/mariadb_async.c:332(mysql_real_connect_start_internal)[0x808b3d9]
libmariadb/ma_context.c:440(my_context_spawn)[0x808ed69]
libmariadb/mariadb_lib.c:3927(mariadb_get_socket)[0x8078c6f]
tests/nonblock-wrappers.h:96(wait_for_mysql(st_mysql*, int))[0x806117e]
```
In this case, the eventual crash is in openssl code, but this is a
conseqeunce of a `movaps` instruction in `BIO_f_buffer` acting on an
unaligned stack location, which is in turn a result of the unaligned
stack from `my_context_spawn`. Any use of SSE2 instructions requiring
alignment will fail in the same way
peadar
force-pushed
the
fix-stack-align
branch
from
f6e575f to
2f5df4c
Compare
|
@knielsen, would you like to take a look at that? |
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.
In
my_context_spawn, assuming the allocated stack pointer is 16-bye aligned (as it will be from malloc, etc), align the stack correctly before calling the target function of the context.For i686 platform, The Linux ABI requires that the stack is aligned on a 16-byte boundary at the time that a call is made, and the compiler attempts to maintain that alignment by adjusting the stack as required to meet the alignment requirements for data, and any subsequent calls.
This is particularly important when compiling for i386 platform with -msse2, The compiler can use SSE2 instructions like
movaps, This instruction will actually fault on unalgned access. This causes the mariadb test suite to fail with the following error, for example:In this case, the eventual crash is in openssl code, but this is a conseqeunce of a
movapsinstruction inBIO_f_bufferacting on an unaligned stack location, which is in turn a result of the unaligned stack from my_context_spawn. Any use of SSE2 instructions requiring alignment will fail in the same way