-
Notifications
You must be signed in to change notification settings - Fork 11.8k
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
Stack misalignment on AVX-512 with asan + detect_stack_use_after_return=0 #91565
Comments
Actually, I just had an epiphany and ended up reproducing with
GCC properly aligns the stack. |
@llvm/issue-subscribers-backend-x86 Author: Mike Hommey (glandium)
Self-sufficient reproducer:
```
void qux(int& y);
struct alignas(64) Foo {
int a[16] = {};
};
void hoge(Foo x);
void foo() {
int x, y, z;
qux(x);
qux(y);
qux(z);
hoge(Foo());
}
```
Call the above `foo.cc`, and add the following as `main.cc` for an executable reproducer:
```
extern "C" const char *__asan_default_options() {
return "detect_stack_use_after_return=0";
}
void qux(int& y) {} struct alignas(64) Foo { void hoge(Foo x) {} void foo(); int main() {
Program received signal SIGSEGV, Segmentation fault.
(...)
%MyAlloca = alloca i8, i64 96, align 32
%MyAlloca = alloca i8, i64 224, align 64
|
Whatever issues there were with detect_stack_use_after_return during the clang trunk cycle for clang 15 seem to be gone. On the other hand, changes in clang 18 trigger a bug[1] that causes stack misalignment in AVX-512 code when detect_stack_use_after_return is disabled. 1. llvm/llvm-project#91565 Differential Revision: https://phabricator.services.mozilla.com/D209907
Whatever issues there were with detect_stack_use_after_return during the clang trunk cycle for clang 15 seem to be gone. On the other hand, changes in clang 18 trigger a bug[1] that causes stack misalignment in AVX-512 code when detect_stack_use_after_return is disabled. 1. llvm/llvm-project#91565 Differential Revision: https://phabricator.services.mozilla.com/D209907
Whatever issues there were with detect_stack_use_after_return during the clang trunk cycle for clang 15 seem to be gone. On the other hand, changes in clang 18 trigger a bug[1] that causes stack misalignment in AVX-512 code when detect_stack_use_after_return is disabled. 1. llvm/llvm-project#91565 Differential Revision: https://phabricator.services.mozilla.com/D209907
Whatever issues there were with detect_stack_use_after_return during the clang trunk cycle for clang 15 seem to be gone. On the other hand, changes in clang 18 trigger a bug[1] that causes stack misalignment in AVX-512 code when detect_stack_use_after_return is disabled. 1. llvm/llvm-project#91565 Differential Revision: https://phabricator.services.mozilla.com/D209907
Whatever issues there were with detect_stack_use_after_return during the clang trunk cycle for clang 15 seem to be gone. On the other hand, changes in clang 18 trigger a bug[1] that causes stack misalignment in AVX-512 code when detect_stack_use_after_return is disabled. 1. llvm/llvm-project#91565 Differential Revision: https://phabricator.services.mozilla.com/D209907
Self-sufficient reproducer:
Call the above
foo.cc
, and add the following asmain.cc
for an executable reproducer:Compile with
clang++ -o foo foo.cc main.cc -fsanitize=address -O2 -mavx512f -g
. Running the program crashes:vmovaps with zmm registers requires 64-bytes alignment but rsp does not have enough alignment.
The relevant parts of the assembly code path:
This started with 51fbab1 (#77210) and
-mllvm -asan-use-stack-safety=0
fixes it.This all comes down to the asan pass setting the alloca to 32-bytes alignment:
With
-mllvm -asan-use-stack-safety=0
, the alloca becomes:It's worth noting that it's only 32 because that's the default value of asan-realign-stack. With
-mllvm -asan-realign-stack=1
it gets down to 16.Essentially, this kind of worked by chance before because the stack poisoner was doing the argument passing alloca too, so MyAlloca was sized and aligned for it. But now that's not the case anymore with stack-safety, MyAlloca doesn't contain and is not aligned for that alloca.
The function call to
hoge
has a properalign 64
annotation on thebyval
. I guess one way to look at the problem is that the function call should take that into account and realign the stack pointer. In theory, I guess this could happen in other scenarios than ASan, but I couldn't get it to happen using an actualalloca()
call in C/C++. The alloca for the call tohoge
always ends up before the manualalloca()
in the IR in my attempts.Another way to look at it is that MyAlloca should have extra alignment based on all the allocas, including the "non interesting" ones, but that sounds hackish.
Cc: @MaskRay
The text was updated successfully, but these errors were encountered: