public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return
@ 2023-05-29 20:18 sneves at dei dot uc.pt
2023-05-29 20:54 ` [Bug target/110027] " pinskia at gcc dot gnu.org
` (25 more replies)
0 siblings, 26 replies; 27+ messages in thread
From: sneves at dei dot uc.pt @ 2023-05-29 20:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
Bug ID: 110027
Summary: Misaligned vector store on
detect_stack_use_after_return
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: sneves at dei dot uc.pt
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org
Target Milestone: ---
(As reported by Jack O'Connor, along with reproducibility instructions, at
https://gist.github.com/oconnor663/69176654f1db1bb96077d6ff4141a022)
Given the following snippet,
#include <immintrin.h>
int main() {
__m512i v = _mm512_set1_epi32(0);
// It doesn't really matter what we do next, as long as we convince the
// compiler to put v on the stack. Here we just read an int from it.
return *((int *)&v);
}
compiled with `gcc repro.c -g -mavx512f -fsanitize=address` results in a
segfault due to a misaligned AVX-512 store. The assembly output is visible at
https://gist.github.com/oconnor663/69176654f1db1bb96077d6ff4141a022#file-repro-s.
Specifically, we have the relevant sequence
andq $-64, %rsp
subq $192, %rsp
leaq 32(%rsp), %rbx
...
cmpl $0, __asan_option_detect_stack_use_after_return(%rip)
je .L1
...
call __asan_stack_malloc_1@PLT
...
movq %rax, %rbx
...
.L1:
leaq 160(%rbx), %rax
movq %rax, %rcx
...
vmovdqa64 %zmm0, -128(%rcx)
Now, if `__asan_option_detect_stack_use_after_return` is 0, the variable at
%rcx-128 is correctly aligned to 64. However, if it is 1, __asan_stack_malloc_1
returns something aligned to 64 << 1 (as per
https://github.com/gcc-mirror/gcc/blob/master/gcc/asan.cc#L1917) and adding 160
results in %rcx-128 being only aligned to 32. And thus the segfault.
Interestingly this seems to be only reproducible on Arch Linux. Other gcc
13.1.1 builds, Fedora for instance, seem to behave correctly. It is unclear to
me what the reason for this is.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug target/110027] Misaligned vector store on detect_stack_use_after_return
2023-05-29 20:18 [Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return sneves at dei dot uc.pt
@ 2023-05-29 20:54 ` pinskia at gcc dot gnu.org
2023-05-30 8:06 ` rguenth at gcc dot gnu.org
` (24 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-05-29 20:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target| |x86_64-linux-gnu
Ever confirmed|0 |1
Component|sanitizer |target
Last reconfirmed| |2023-05-29
Status|UNCONFIRMED |NEW
Keywords| |wrong-code
Known to work| |7.5.0
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Samuel Neves from comment #0)
> Interestingly this seems to be only reproducible on Arch Linux. Other gcc
> 13.1.1 builds, Fedora for instance, seem to behave correctly. It is unclear
> to me what the reason for this is.
So I figured out where the difference comes from: -fstack-protector-strong .
That is Arch linux defaults to enabling -fstack-protector-strong while Fedora
does not.
apinski@xeond:~/src/upstream-gcc$ ~/upstream-gcc/bin/gcc t.c -mavx512f
-fsanitize=address -g
apinski@xeond:~/src/upstream-gcc$ LD_LIBRARY_PATH=~/upstream-gcc/lib64 ./a.out
;echo $?
0
apinski@xeond:~/src/upstream-gcc$ ~/upstream-gcc/bin/gcc t.c -mavx512f
-fsanitize=address -g -fstack-protector-strong
apinski@xeond:~/src/upstream-gcc$ LD_LIBRARY_PATH=~/upstream-gcc/lib64 ./a.out
;echo $?
AddressSanitizer:DEADLYSIGNAL
=================================================================
==22803==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x000000400929 bp
0x7fff1989a900 sp 0x7fff1989a800 T0)
==22803==The signal is caused by a READ memory access.
==22803==Hint: this fault was caused by a dereference of a high value address
(see register values below). Disassemble the provided pc to learn which
register was used.
#0 0x400929 in main /home/apinski/src/upstream-gcc/t.c:5
#1 0x7ff88bf72c86 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x21c86) (BuildId:
f7307432a8b162377e77a182b6cc2e53d771ec4b)
#2 0x400769 in _start (/bajas/pinskia/src/upstream-gcc/a.out+0x400769)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/apinski/src/upstream-gcc/t.c:5 in main
==22803==ABORTING
1
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug target/110027] Misaligned vector store on detect_stack_use_after_return
2023-05-29 20:18 [Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return sneves at dei dot uc.pt
2023-05-29 20:54 ` [Bug target/110027] " pinskia at gcc dot gnu.org
@ 2023-05-30 8:06 ` rguenth at gcc dot gnu.org
2023-05-30 14:49 ` oconnor663 at gmail dot com
` (23 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-05-30 8:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
I can't reproduce it.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug target/110027] Misaligned vector store on detect_stack_use_after_return
2023-05-29 20:18 [Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return sneves at dei dot uc.pt
2023-05-29 20:54 ` [Bug target/110027] " pinskia at gcc dot gnu.org
2023-05-30 8:06 ` rguenth at gcc dot gnu.org
@ 2023-05-30 14:49 ` oconnor663 at gmail dot com
2023-10-22 18:06 ` gcc at sicherha dot de
` (22 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: oconnor663 at gmail dot com @ 2023-05-30 14:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
Jack O'Connor <oconnor663 at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |oconnor663 at gmail dot com
--- Comment #3 from Jack O'Connor <oconnor663 at gmail dot com> ---
Thanks to Andrew Pinski's comment about -fstack-protector-strong, I can now
reproduce this issue on Godbolt: https://godbolt.org/z/47a695sWY. So the
minimal set of flags to reproduce on most distros (other than Arch Linux) is:
-mavx512f -fsanitize=address -fstack-protector-strong
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug target/110027] Misaligned vector store on detect_stack_use_after_return
2023-05-29 20:18 [Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return sneves at dei dot uc.pt
` (2 preceding siblings ...)
2023-05-30 14:49 ` oconnor663 at gmail dot com
@ 2023-10-22 18:06 ` gcc at sicherha dot de
2023-12-01 17:42 ` pinskia at gcc dot gnu.org
` (21 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: gcc at sicherha dot de @ 2023-10-22 18:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
Christoph Erhardt <gcc at sicherha dot de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gcc at sicherha dot de
--- Comment #4 from Christoph Erhardt <gcc at sicherha dot de> ---
Created attachment 56169
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56169&action=edit
Reproducer program
Here's a program that can reproduce this issue more reliably - tested on Fedora
38, Ubuntu 23.04 and Ubuntu 23.10.
I have stripped down the code as far as possible. This is how far I could get
without losing reproducibility.
Sources are in a GitHub repo:
https://github.com/sicherha/gcc-asan-stack-misalign
$ gcc -Wall -Wextra -g -Og -fsanitize=address -fno-stack-protector -mavx512f
a-repro.i
$ ./a.out
AddressSanitizer:DEADLYSIGNAL
=================================================================
==3618==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x000000401789 bp
0x7ffeabbcda00 sp 0x7ffeabbcd580 T0)
==3618==The signal is caused by a READ memory access.
==3618==Hint: this fault was caused by a dereference of a high value address
(see register values below). Disassemble the provided pc to learn which
register was used.
#0 0x401789 in blake3_compress_subtree_wide
/home/ul26967/Projects/gcc-asan-stack-misalign/a-repro.i:481
#1 0x40189b in main
/home/ul26967/Projects/gcc-asan-stack-misalign/a-repro.i:488
#2 0x7f77a0210b89 in __libc_start_call_main (/lib64/libc.so.6+0x27b89)
(BuildId: 3ebe8d97a0ed3e1f13476a02665c5a9442adcd78)
#3 0x7f77a0210c4a in __libc_start_main_alias_2 (/lib64/libc.so.6+0x27c4a)
(BuildId: 3ebe8d97a0ed3e1f13476a02665c5a9442adcd78)
#4 0x4010f4 in _start
(/home/ul26967/Projects/gcc-asan-stack-misalign/a.out+0x4010f4) (BuildId:
e25b3ac48fa6dd8cff5d228e201834fa1b0cd18a)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV
/home/ul26967/Projects/gcc-asan-stack-misalign/a-repro.i:481 in
blake3_compress_subtree_wide
==3618==ABORTING
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug target/110027] Misaligned vector store on detect_stack_use_after_return
2023-05-29 20:18 [Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return sneves at dei dot uc.pt
` (3 preceding siblings ...)
2023-10-22 18:06 ` gcc at sicherha dot de
@ 2023-12-01 17:42 ` pinskia at gcc dot gnu.org
2023-12-01 17:46 ` pinskia at gcc dot gnu.org
` (20 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-12-01 17:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tonyb at cybernetics dot com
--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 112812 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug target/110027] Misaligned vector store on detect_stack_use_after_return
2023-05-29 20:18 [Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return sneves at dei dot uc.pt
` (4 preceding siblings ...)
2023-12-01 17:42 ` pinskia at gcc dot gnu.org
@ 2023-12-01 17:46 ` pinskia at gcc dot gnu.org
2023-12-17 23:24 ` pinskia at gcc dot gnu.org
` (19 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-12-01 17:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sadko4u at gmail dot com
--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 112510 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug target/110027] Misaligned vector store on detect_stack_use_after_return
2023-05-29 20:18 [Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return sneves at dei dot uc.pt
` (5 preceding siblings ...)
2023-12-01 17:46 ` pinskia at gcc dot gnu.org
@ 2023-12-17 23:24 ` pinskia at gcc dot gnu.org
2024-03-08 4:13 ` pinskia at gcc dot gnu.org
` (18 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-12-17 23:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pobrn at protonmail dot com
--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 113053 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug target/110027] Misaligned vector store on detect_stack_use_after_return
2023-05-29 20:18 [Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return sneves at dei dot uc.pt
` (6 preceding siblings ...)
2023-12-17 23:24 ` pinskia at gcc dot gnu.org
@ 2024-03-08 4:13 ` pinskia at gcc dot gnu.org
2024-03-08 11:41 ` elrodc at gmail dot com
` (17 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-03-08 4:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |elrodc at gmail dot com
--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 114276 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug target/110027] Misaligned vector store on detect_stack_use_after_return
2023-05-29 20:18 [Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return sneves at dei dot uc.pt
` (7 preceding siblings ...)
2024-03-08 4:13 ` pinskia at gcc dot gnu.org
@ 2024-03-08 11:41 ` elrodc at gmail dot com
2024-03-08 18:10 ` gcc at sicherha dot de
` (16 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: elrodc at gmail dot com @ 2024-03-08 11:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
--- Comment #9 from Chris Elrod <elrodc at gmail dot com> ---
> Interestingly this seems to be only reproducible on Arch Linux. Other gcc 13.1.1 builds, Fedora for instance, seem to behave correctly.
I haven't tried that reproducer on Fedora with gcc 13.2.1, which could have
regressed since 13.1.1.
However, the dup example in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114276
does reproduce on Fedora with gcc-13.2.1 once you add extra compile flags
`-std=c++23 -fstack-protector-strong`.
I'll try the original reproducer later, it may be the case that adding/removing
these flags fuzzes the alignment.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug target/110027] Misaligned vector store on detect_stack_use_after_return
2023-05-29 20:18 [Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return sneves at dei dot uc.pt
` (8 preceding siblings ...)
2024-03-08 11:41 ` elrodc at gmail dot com
@ 2024-03-08 18:10 ` gcc at sicherha dot de
2024-03-08 18:52 ` [Bug target/110027] [11/12/13/14 regression] " sjames at gcc dot gnu.org
` (15 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: gcc at sicherha dot de @ 2024-03-08 18:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
--- Comment #10 from Christoph Erhardt <gcc at sicherha dot de> ---
I have just verified that the reproducer program I attached above
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027#c4) still crashes as
expected on Fedora 39 with GCC 13.2.1. It's not super-tiny, but it fails
reliably. :-)
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug target/110027] [11/12/13/14 regression] Misaligned vector store on detect_stack_use_after_return
2023-05-29 20:18 [Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return sneves at dei dot uc.pt
` (9 preceding siblings ...)
2024-03-08 18:10 ` gcc at sicherha dot de
@ 2024-03-08 18:52 ` sjames at gcc dot gnu.org
2024-03-11 3:28 ` liuhongt at gcc dot gnu.org
` (14 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: sjames at gcc dot gnu.org @ 2024-03-08 18:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
--- Comment #11 from Sam James <sjames at gcc dot gnu.org> ---
Calling it a 11..14 regression as we know 14 is bad and 7.5 is OK, but I can't
test 11/12 on an avx512 machine right now.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug target/110027] [11/12/13/14 regression] Misaligned vector store on detect_stack_use_after_return
2023-05-29 20:18 [Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return sneves at dei dot uc.pt
` (10 preceding siblings ...)
2024-03-08 18:52 ` [Bug target/110027] [11/12/13/14 regression] " sjames at gcc dot gnu.org
@ 2024-03-11 3:28 ` liuhongt at gcc dot gnu.org
2024-03-12 5:10 ` liuhongt at gcc dot gnu.org
` (13 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: liuhongt at gcc dot gnu.org @ 2024-03-11 3:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
--- Comment #12 from Hongtao Liu <liuhongt at gcc dot gnu.org> ---
(In reply to Sam James from comment #11)
> Calling it a 11..14 regression as we know 14 is bad and 7.5 is OK, but I
> can't test 11/12 on an avx512 machine right now.
I can't reproduce that with 11/12, but with gcc13 for the case in PR114276.
It looks like the codegen is already wrong in .expand, the offensive part is
mentioned in #c0
>Now, if `__asan_option_detect_stack_use_after_return` is 0, the variable at >%rcx-128 is correctly aligned to 64. However, if it is 1, __asan_stack_malloc_1 >returns something aligned to 64 << 1 (as per https://github.com/gcc->mirror/gcc/blob/master/gcc/asan.cc#L1917) and adding 160 results in %rcx-128 >being only aligned to 32. And thus the segfault.
;; Function foo (_Z3foov, funcdef_no=14, decl_uid=3962, cgraph_uid=10,
symbol_order=9)
(note 1 0 37 NOTE_INSN_DELETED)
;; basic block 2, loop depth 0, maybe hot
;; prev block 0, next block 3, flags: (NEW, REACHABLE, RTL, MODIFIED)
;; pred: ENTRY (FALLTHRU)
(note 37 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 37 3 2 (parallel [
(set (reg:DI 105)
(plus:DI (reg/f:DI 19 frame)
(const_int -160 [0xffffffffffffff60])))
(clobber (reg:CC 17 flags))
]) "test1.cc":7:12 247 {*adddi_1}
(nil))
(insn 3 2 4 2 (set (reg:DI 106)
(reg:DI 105)) "test1.cc":7:12 82 {*movdi_internal}
(nil))
(insn 4 3 5 2 (set (reg:CCZ 17 flags)
(compare:CCZ (mem/c:SI (symbol_ref:DI
("__asan_option_detect_stack_use_after_return") [flags 0x40] <var_decl
0x7f8d26f37900 __asan_option_detect_stack_use_after_return>) [4
__asan_option_detect_stack_use_after_return+0 S4 A32])
(const_int 0 [0]))) "test1.cc":7:12 7 {*cmpsi_ccno_1}
(nil))
(jump_insn 5 4 93 2 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref 11)
(pc))) "test1.cc":7:12 995 {*jcc}
(nil)
-> 11)
;; succ: 5
;; 3 (FALLTHRU)
;; basic block 3, loop depth 0, maybe hot
;; prev block 2, next block 4, flags: (NEW, REACHABLE, RTL, MODIFIED)
;; pred: 2 (FALLTHRU)
(note 93 5 6 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn 6 93 7 3 (set (reg:DI 5 di)
(const_int 128 [0x80])) "test1.cc":7:12 82 {*movdi_internal}
(nil))
(call_insn 7 6 8 3 (set (reg:DI 0 ax)
(call (mem:QI (symbol_ref:DI ("__asan_stack_malloc_1") [flags 0x41]
<function_decl 0x7f8d26fa2400 __asan_stack_malloc_1>) [0 S1 A8])
(const_int 0 [0]))) "test1.cc":7:12 1013 {*call_value}
(expr_list:REG_EH_REGION (const_int -2147483648 [0xffffffff80000000])
(nil))
(expr_list (use (reg:DI 5 di))
(nil)))
(insn 8 7 9 3 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:DI 0 ax)
(const_int 0 [0]))) "test1.cc":7:12 8 {*cmpdi_ccno_1}
(nil))
(jump_insn 9 8 94 3 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref 11)
(pc))) "test1.cc":7:12 995 {*jcc}
(nil)
-> 11)
;; succ: 5
;; 4 (FALLTHRU)
;; basic block 4, loop depth 0, maybe hot
;; prev block 3, next block 5, flags: (NEW, REACHABLE, RTL, MODIFIED)
;; pred: 3 (FALLTHRU)
(note 94 9 10 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn 10 94 11 4 (set (reg:DI 105)
(reg:DI 0 ax)) "test1.cc":7:12 82 {*movdi_internal}
(nil))
;; succ: 5 (FALLTHRU)
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug target/110027] [11/12/13/14 regression] Misaligned vector store on detect_stack_use_after_return
2023-05-29 20:18 [Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return sneves at dei dot uc.pt
` (11 preceding siblings ...)
2024-03-11 3:28 ` liuhongt at gcc dot gnu.org
@ 2024-03-12 5:10 ` liuhongt at gcc dot gnu.org
2024-03-12 6:35 ` liuhongt at gcc dot gnu.org
` (12 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: liuhongt at gcc dot gnu.org @ 2024-03-12 5:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
--- Comment #13 from Hongtao Liu <liuhongt at gcc dot gnu.org> ---
So the stack is like
----------- stack top
-32
--------- (offset -32)
-64 (32 bytes redzone)
--------- (offset -64)
-128 (64 bytes __m512)
-------- (offset -128)
(32-bytes redzone)
-------(offset -160) <--- __asan_stack_malloc_128 try to allocate an buffer
/* Emit the prologue sequence. */
if (asan_frame_size > 32 && asan_frame_size <= 65536 && pbase
&& param_asan_use_after_return)
{
use_after_return_class = floor_log2 (asan_frame_size - 1) - 5;
/* __asan_stack_malloc_N guarantees alignment
N < 6 ? (64 << N) : 4096 bytes. */
if (alignb > (use_after_return_class < 6
? (64U << use_after_return_class) : 4096U))
use_after_return_class = -1;
else if (alignb > ASAN_RED_ZONE_SIZE && (asan_frame_size & (alignb - 1)))
base_align_bias = ((asan_frame_size + alignb - 1)
& ~(alignb - HOST_WIDE_INT_1)) - asan_frame_size;
}
/* Align base if target is STRICT_ALIGNMENT. */
if (STRICT_ALIGNMENT)
{
const HOST_WIDE_INT align
= (GET_MODE_ALIGNMENT (SImode) / BITS_PER_UNIT) << ASAN_SHADOW_SHIFT;
base = expand_binop (Pmode, and_optab, base, gen_int_mode (-align,
Pmode),
NULL_RTX, 1, OPTAB_DIRECT);
}
if (use_after_return_class == -1 && pbase)
emit_move_insn (pbase, base);
base = expand_binop (Pmode, add_optab, base,
gen_int_mode (base_offset - base_align_bias, Pmode),
NULL_RTX, 1, OPTAB_DIRECT); ---------- suspicious add
orig_base = NULL_RTX;
if (use_after_return_class != -1)
{
...
ret = emit_library_call_value (ret, NULL_RTX, LCT_NORMAL, ptr_mode,
GEN_INT (asan_frame_size
+ base_align_bias),
TYPE_MODE (pointer_sized_int_node));
/* __asan_stack_malloc_[n] returns a pointer to fake stack if succeeded
and NULL otherwise. Check RET value is NULL here and jump over the
BASE reassignment in this case. Otherwise, reassign BASE to RET. */
emit_cmp_and_jump_insns (ret, const0_rtx, EQ, NULL_RTX,
VOIDmode, 0, lab,
profile_probability:: very_unlikely ());
ret = convert_memory_address (Pmode, ret);
emit_move_insn (base, ret);
emit_label (lab);
emit_move_insn (pbase, expand_binop (Pmode, add_optab, base,
gen_int_mode (base_align_bias
- base_offset, Pmode),
NULL_RTX, 1, OPTAB_DIRECT));
base_align_bias is calculated to make (asan_frame_size(128) +
base_align_bias(0)) be multiple of alignb (64), but didn't make `base_offset
(160) - base_align_bias (0)` be multiple of 64, so when __asan_stack_malloc_128
return an address aligned to 64, and then plus (base_offset (160) -
base_align_bias (0)), it's misaligned.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug target/110027] [11/12/13/14 regression] Misaligned vector store on detect_stack_use_after_return
2023-05-29 20:18 [Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return sneves at dei dot uc.pt
` (12 preceding siblings ...)
2024-03-12 5:10 ` liuhongt at gcc dot gnu.org
@ 2024-03-12 6:35 ` liuhongt at gcc dot gnu.org
2024-03-15 1:51 ` liuhongt at gcc dot gnu.org
` (11 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: liuhongt at gcc dot gnu.org @ 2024-03-12 6:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
--- Comment #14 from Hongtao Liu <liuhongt at gcc dot gnu.org> ---
diff --git a/gcc/cfgexpand.cc b/gcc/cfgexpand.cc
index 0de299c62e3..92062378d8e 100644
--- a/gcc/cfgexpand.cc
+++ b/gcc/cfgexpand.cc
@@ -1214,7 +1214,7 @@ expand_stack_vars (bool (*pred) (size_t), class
stack_vars_data *data)
{
if (data->asan_vec.is_empty ())
{
- align_frame_offset (ASAN_RED_ZONE_SIZE);
+ align_frame_offset (MAX (alignb, ASAN_RED_ZONE_SIZE));
prev_offset = frame_offset.to_constant ();
}
prev_offset = align_base (prev_offset,
This can fix the issue, but not sure if it's the correct way.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug target/110027] [11/12/13/14 regression] Misaligned vector store on detect_stack_use_after_return
2023-05-29 20:18 [Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return sneves at dei dot uc.pt
` (13 preceding siblings ...)
2024-03-12 6:35 ` liuhongt at gcc dot gnu.org
@ 2024-03-15 1:51 ` liuhongt at gcc dot gnu.org
2024-03-25 12:34 ` rguenth at gcc dot gnu.org
` (10 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: liuhongt at gcc dot gnu.org @ 2024-03-15 1:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
--- Comment #15 from Hongtao Liu <liuhongt at gcc dot gnu.org> ---
A patch is posted at
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647604.html
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug target/110027] [11/12/13/14 regression] Misaligned vector store on detect_stack_use_after_return
2023-05-29 20:18 [Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return sneves at dei dot uc.pt
` (14 preceding siblings ...)
2024-03-15 1:51 ` liuhongt at gcc dot gnu.org
@ 2024-03-25 12:34 ` rguenth at gcc dot gnu.org
2024-04-08 15:43 ` xry111 at gcc dot gnu.org
` (9 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-03-25 12:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |11.5
Priority|P3 |P2
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug target/110027] [11/12/13/14 regression] Misaligned vector store on detect_stack_use_after_return
2023-05-29 20:18 [Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return sneves at dei dot uc.pt
` (15 preceding siblings ...)
2024-03-25 12:34 ` rguenth at gcc dot gnu.org
@ 2024-04-08 15:43 ` xry111 at gcc dot gnu.org
2024-04-09 18:25 ` [Bug target/110027] [11/12/13/14 regression] Stack objects with extended alignments (vectors etc) misaligned " jakub at gcc dot gnu.org
` (8 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: xry111 at gcc dot gnu.org @ 2024-04-08 15:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
Xi Ruoyao <xry111 at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |teodor_spaeren at riseup dot net
--- Comment #16 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
*** Bug 114637 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug target/110027] [11/12/13/14 regression] Stack objects with extended alignments (vectors etc) misaligned on detect_stack_use_after_return
2023-05-29 20:18 [Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return sneves at dei dot uc.pt
` (16 preceding siblings ...)
2024-04-08 15:43 ` xry111 at gcc dot gnu.org
@ 2024-04-09 18:25 ` jakub at gcc dot gnu.org
2024-04-10 10:25 ` [Bug middle-end/110027] " jakub at gcc dot gnu.org
` (7 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-04-09 18:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Both of the posted patches are incorrect, this needs to be fixed in
asan_emit_stack_protection, account for the different offsets[0] which happens
when a stack pointer guard is created.
I'll deal with it tomorrow.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug middle-end/110027] [11/12/13/14 regression] Stack objects with extended alignments (vectors etc) misaligned on detect_stack_use_after_return
2023-05-29 20:18 [Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return sneves at dei dot uc.pt
` (17 preceding siblings ...)
2024-04-09 18:25 ` [Bug target/110027] [11/12/13/14 regression] Stack objects with extended alignments (vectors etc) misaligned " jakub at gcc dot gnu.org
@ 2024-04-10 10:25 ` jakub at gcc dot gnu.org
2024-04-11 6:53 ` liuhongt at gcc dot gnu.org
` (6 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-04-10 10:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 57915
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57915&action=edit
gcc14-pr110027.patch
So far lightly tested patch (make check-gcc check-g++ RUNTESTFLAGS=asan.exp on
x86_64-linux and i686-linux).
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug middle-end/110027] [11/12/13/14 regression] Stack objects with extended alignments (vectors etc) misaligned on detect_stack_use_after_return
2023-05-29 20:18 [Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return sneves at dei dot uc.pt
` (18 preceding siblings ...)
2024-04-10 10:25 ` [Bug middle-end/110027] " jakub at gcc dot gnu.org
@ 2024-04-11 6:53 ` liuhongt at gcc dot gnu.org
2024-04-11 8:16 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: liuhongt at gcc dot gnu.org @ 2024-04-11 6:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
--- Comment #19 from Hongtao Liu <liuhongt at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #17)
> Both of the posted patches are incorrect, this needs to be fixed in
> asan_emit_stack_protection, account for the different offsets[0] which
> happens when a stack pointer guard is created.
> I'll deal with it tomorrow.
It seems to me that the only offend place is where I've modifed, are there
other places where align_frame_offset (ASAN_RED_ZONE_SIZE) is also added?
Also, your patch adds a gcc_assert for offset[0], which seems to me there was
an assumption that offset[0] should be a multiple of alignb, thus making my
patch more reasonable?
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug middle-end/110027] [11/12/13/14 regression] Stack objects with extended alignments (vectors etc) misaligned on detect_stack_use_after_return
2023-05-29 20:18 [Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return sneves at dei dot uc.pt
` (19 preceding siblings ...)
2024-04-11 6:53 ` liuhongt at gcc dot gnu.org
@ 2024-04-11 8:16 ` jakub at gcc dot gnu.org
2024-04-11 9:14 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-04-11 8:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Hongtao Liu from comment #19)
> (In reply to Jakub Jelinek from comment #17)
> > Both of the posted patches are incorrect, this needs to be fixed in
> > asan_emit_stack_protection, account for the different offsets[0] which
> > happens when a stack pointer guard is created.
> > I'll deal with it tomorrow.
>
> It seems to me that the only offend place is where I've modifed, are there
> other places where align_frame_offset (ASAN_RED_ZONE_SIZE) is also added?
>
> Also, your patch adds a gcc_assert for offset[0], which seems to me there
> was an assumption that offset[0] should be a multiple of alignb, thus making
> my patch more reasonable?
Your first patch aligned offsets[0] to maximum of alignb and
ASAN_RED_ZONE_SIZE.
But as I wrote in the reply to that mail, alignb there is the alignment of just
a single variable which is the first one to appear in the sorted list and is
placed in the highest spot in the stack frame.
That is not necessarily the largest alignment, the sorting ensures that it is a
variable with the largest size in the frame (and only if several of them have
equal size, largest alignment from the same sized ones).
Your second patch used maximum of BIGGEST_ALIGNMENT / BITS_PER_UNIT and
ASAN_RED_ZONE_SIZE. That doesn't change anything at all when using
-mno-avx512f - offsets[0] is still just 32-byte aligned in that case relative
to top of frame, just changes the -mavx512f case to be 64-byte aligned
offsets[0] (aka offsets[0] is then either 0 or -64 instead of either 0 or -32).
That will not help if any variable in the frame needs 128-byte, 256-byte,
512-byte ... 4096-byte alignment.
If you want to fix the bug in the spot you've touched, you'd need to walk all
the
stack_vars[stack_vars_sorted[si2]] for si2 [si + 1, n - 1] and for those where
the
loop would do anything (i.e.
stack_vars[i2].representative == i2
&& TREE_CODE (decl2) == SSA_NAME
? SA.partition_to_pseudo[var_to_partition (SA.map, decl2)] == NULL_RTX
: DECL_RTL (decl2) == pc_rtx
and the pred applies (but that means also walking the earlier ones! because
with -fstack-protector* the vars can be processed in several calls) and
alignb2 * BITS_PER_UNIT <= MAX_SUPPORTED_STACK_ALIGNMENT
and compute maximum of those alignments.
That maximum is already computed,
data->asan_alignb = MAX (data->asan_alignb, alignb);
computes that, but you get the final result only after you do all the
expand_stack_vars
calls. You'd need to compute it before.
Though, that change would be still in the wrong place.
The thing is, it would be a waste of the precious stack space when it isn't
needed at all (e.g. when asan will not at compile time do the use after return
checking, or if it won't do it at runtime, or even if it will do at runtime it
will waste the space on the stack).
My patch enlarges if needed just the __asan_stack_malloc_N allocated chunk, not
the stack frame size.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug middle-end/110027] [11/12/13/14 regression] Stack objects with extended alignments (vectors etc) misaligned on detect_stack_use_after_return
2023-05-29 20:18 [Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return sneves at dei dot uc.pt
` (20 preceding siblings ...)
2024-04-11 8:16 ` jakub at gcc dot gnu.org
@ 2024-04-11 9:14 ` cvs-commit at gcc dot gnu.org
2024-04-11 10:06 ` [Bug middle-end/110027] [11/12/13 " jakub at gcc dot gnu.org
` (3 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-04-11 9:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
--- Comment #21 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:467898d513e602f5b5fc4183052217d7e6d6e8ab
commit r14-9913-g467898d513e602f5b5fc4183052217d7e6d6e8ab
Author: Jakub Jelinek <jakub@redhat.com>
Date: Thu Apr 11 11:12:11 2024 +0200
asan, v3: Fix up handling of > 32 byte aligned variables with
-fsanitize=address -fstack-protector* [PR110027]
On Tue, Mar 26, 2024 at 02:08:02PM +0800, liuhongt wrote:
> > > So, try to add some other variable with larger size and smaller
alignment
> > > to the frame (and make sure it isn't optimized away).
> > >
> > > alignb above is the alignment of the first partition's var, if
> > > align_frame_offset really needs to depend on the var alignment, it
probably
> > > should be the maximum alignment of all the vars with alignment
> > > alignb * BITS_PER_UNIT <=3D MAX_SUPPORTED_STACK_ALIGNMENT
> > >
>
> In asan_emit_stack_protection, when it allocated fake stack, it assume
> bottom of stack is also aligned to alignb. And the place violated this
> is the first var partition. which is 32 bytes offsets, it should be
> BIGGEST_ALIGNMENT / BITS_PER_UNIT.
> So I think we need to use MAX (BIGGEST_ALIGNMENT /
> BITS_PER_UNIT, ASAN_RED_ZONE_SIZE) for the first var partition.
Your first patch aligned offsets[0] to maximum of alignb and
ASAN_RED_ZONE_SIZE. But as I wrote in the reply to that mail, alignb there
is the alignment of just a single variable which is the first one to appear
in the sorted list and is placed in the highest spot in the stack frame.
That is not necessarily the largest alignment, the sorting ensures that it
is a variable with the largest size in the frame (and only if several of
them have equal size, largest alignment from the same sized ones). Your
second patch used maximum of BIGGEST_ALIGNMENT / BITS_PER_UNIT and
ASAN_RED_ZONE_SIZE. That doesn't change anything at all when using
-mno-avx512f - offsets[0] is still just 32-byte aligned in that case
relative to top of frame, just changes the -mavx512f case to be 64-byte
aligned offsets[0] (aka offsets[0] is then either 0 or -64 instead of
either
0 or -32). That will not help if any variable in the frame needs 128-byte,
256-byte, 512-byte ... 4096-byte alignment. If you want to fix the bug in
the spot you've touched, you'd need to walk all the
stack_vars[stack_vars_sorted[si2]] for si2 [si + 1, n - 1] and for those
where the loop would do anything (i.e.
stack_vars[i2].representative == i2
&& TREE_CODE (decl2) == SSA_NAME
? SA.partition_to_pseudo[var_to_partition (SA.map, decl2)] == NULL_RTX
: DECL_RTL (decl2) == pc_rtx
and the pred applies (but that means also walking the earlier ones!
because with -fstack-protector* the vars can be processed in several calls)
and
alignb2 * BITS_PER_UNIT <= MAX_SUPPORTED_STACK_ALIGNMENT
and compute maximum of those alignments.
That maximum is already computed,
data->asan_alignb = MAX (data->asan_alignb, alignb);
computes that, but you get the final result only after you do all the
expand_stack_vars calls. You'd need to compute it before.
Though, that change would be still in the wrong place.
The thing is, it would be a waste of the precious stack space when it isn't
needed at all (e.g. when asan will not at compile time do the use after
return checking, or if it won't do it at runtime, or even if it will do at
runtime it will waste the space on the stack).
The following patch fixes it solely for the __asan_stack_malloc_N
allocations, doesn't enlarge unnecessarily further the actual stack frame.
Because asan is only supported on FRAME_GROWS_DOWNWARD architectures
(mips, rs6000 and xtensa are conditional FRAME_GROWS_DOWNWARD arches, which
for -fsanitize=address or -fstack-protector* use FRAME_GROWS_DOWNWARD 1,
otherwise 0, others supporting asan always just use 1), the assumption for
the dynamic stack realignment is that the top of the stack frame (aka
offset
0) is aligned to alignb passed to the function (which is the maximum of
alignb
of all the vars in the frame). As checked by the assertion in the patch,
offsets[0] is 0 most of the time and so that assumption is correct, the
only
case when it is not 0 is if -fstack-protector* is on together with
-fsanitize=address and cfgexpand.cc (create_stack_guard) created a stack
guard. That is the only variable which is allocated in the stack frame
right away, for all others with -fsanitize=address defer_stack_allocation
(or -fstack-protector*) returns true and so they aren't allocated
immediately but handled during the frame layout phases. So, the original
frame_offset of 0 is changed because of the stack guard to
-pointer_size_in_bytes and later at the
if (data->asan_vec.is_empty ())
{
align_frame_offset (ASAN_RED_ZONE_SIZE);
prev_offset = frame_offset.to_constant ();
}
to -ASAN_RED_ZONE_SIZE. The asan_emit_stack_protection code wasn't
taking this into account though, so essentially assumed in the
__asan_stack_malloc_N allocated memory it needs to align it such that
pointer corresponding to offsets[0] is alignb aligned. But that isn't
correct if alignb > ASAN_RED_ZONE_SIZE, in that case it needs to ensure
that
pointer corresponding to frame offset 0 is alignb aligned.
The following patch fixes that. Unlike the previous case where
we knew that asan_frame_size + base_align_bias falls into the same bucket
as asan_frame_size, this isn't in some cases true anymore, so the patch
recomputes which bucket to use and if going to bucket 11 (because there is
no __asan_stack_malloc_11 function in the library) disables the after
return
sanitization.
2024-04-11 Jakub Jelinek <jakub@redhat.com>
PR middle-end/110027
* asan.cc (asan_emit_stack_protection): Assert offsets[0] is
zero if there is no stack protect guard, otherwise
-ASAN_RED_ZONE_SIZE. If alignb > ASAN_RED_ZONE_SIZE and there is
stack pointer guard, take the ASAN_RED_ZONE_SIZE bytes allocated at
the top of the stack into account when computing base_align_bias.
Recompute use_after_return_class from asan_frame_size +
base_align_bias
and set to -1 if that would overflow to 11.
* gcc.dg/asan/pr110027.c: New test.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug middle-end/110027] [11/12/13 regression] Stack objects with extended alignments (vectors etc) misaligned on detect_stack_use_after_return
2023-05-29 20:18 [Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return sneves at dei dot uc.pt
` (21 preceding siblings ...)
2024-04-11 9:14 ` cvs-commit at gcc dot gnu.org
@ 2024-04-11 10:06 ` jakub at gcc dot gnu.org
2024-04-12 18:09 ` carlos.seo at linaro dot org
` (2 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-04-11 10:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Summary|[11/12/13/14 regression] |[11/12/13 regression] Stack
|Stack objects with extended |objects with extended
|alignments (vectors etc) |alignments (vectors etc)
|misaligned on |misaligned on
|detect_stack_use_after_retu |detect_stack_use_after_retu
|rn |rn
--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk so far.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug middle-end/110027] [11/12/13 regression] Stack objects with extended alignments (vectors etc) misaligned on detect_stack_use_after_return
2023-05-29 20:18 [Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return sneves at dei dot uc.pt
` (22 preceding siblings ...)
2024-04-11 10:06 ` [Bug middle-end/110027] [11/12/13 " jakub at gcc dot gnu.org
@ 2024-04-12 18:09 ` carlos.seo at linaro dot org
2024-04-21 4:09 ` cvs-commit at gcc dot gnu.org
2024-04-23 6:44 ` [Bug middle-end/110027] [11/12 " jakub at gcc dot gnu.org
25 siblings, 0 replies; 27+ messages in thread
From: carlos.seo at linaro dot org @ 2024-04-12 18:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
Carlos Eduardo Seo <carlos.seo at linaro dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |carlos.seo at linaro dot org
--- Comment #23 from Carlos Eduardo Seo <carlos.seo at linaro dot org> ---
FYI, the new test is failing on aarch64-linux-gnu.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug middle-end/110027] [11/12/13 regression] Stack objects with extended alignments (vectors etc) misaligned on detect_stack_use_after_return
2023-05-29 20:18 [Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return sneves at dei dot uc.pt
` (23 preceding siblings ...)
2024-04-12 18:09 ` carlos.seo at linaro dot org
@ 2024-04-21 4:09 ` cvs-commit at gcc dot gnu.org
2024-04-23 6:44 ` [Bug middle-end/110027] [11/12 " jakub at gcc dot gnu.org
25 siblings, 0 replies; 27+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-04-21 4:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
--- Comment #24 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:a16d90ec302e588dab5d7d31ccdd7b3fd5c6214e
commit r13-8630-ga16d90ec302e588dab5d7d31ccdd7b3fd5c6214e
Author: Jakub Jelinek <jakub@redhat.com>
Date: Thu Apr 11 11:12:11 2024 +0200
asan, v3: Fix up handling of > 32 byte aligned variables with
-fsanitize=address -fstack-protector* [PR110027]
On Tue, Mar 26, 2024 at 02:08:02PM +0800, liuhongt wrote:
> > > So, try to add some other variable with larger size and smaller
alignment
> > > to the frame (and make sure it isn't optimized away).
> > >
> > > alignb above is the alignment of the first partition's var, if
> > > align_frame_offset really needs to depend on the var alignment, it
probably
> > > should be the maximum alignment of all the vars with alignment
> > > alignb * BITS_PER_UNIT <=3D MAX_SUPPORTED_STACK_ALIGNMENT
> > >
>
> In asan_emit_stack_protection, when it allocated fake stack, it assume
> bottom of stack is also aligned to alignb. And the place violated this
> is the first var partition. which is 32 bytes offsets, it should be
> BIGGEST_ALIGNMENT / BITS_PER_UNIT.
> So I think we need to use MAX (BIGGEST_ALIGNMENT /
> BITS_PER_UNIT, ASAN_RED_ZONE_SIZE) for the first var partition.
Your first patch aligned offsets[0] to maximum of alignb and
ASAN_RED_ZONE_SIZE. But as I wrote in the reply to that mail, alignb there
is the alignment of just a single variable which is the first one to appear
in the sorted list and is placed in the highest spot in the stack frame.
That is not necessarily the largest alignment, the sorting ensures that it
is a variable with the largest size in the frame (and only if several of
them have equal size, largest alignment from the same sized ones). Your
second patch used maximum of BIGGEST_ALIGNMENT / BITS_PER_UNIT and
ASAN_RED_ZONE_SIZE. That doesn't change anything at all when using
-mno-avx512f - offsets[0] is still just 32-byte aligned in that case
relative to top of frame, just changes the -mavx512f case to be 64-byte
aligned offsets[0] (aka offsets[0] is then either 0 or -64 instead of
either
0 or -32). That will not help if any variable in the frame needs 128-byte,
256-byte, 512-byte ... 4096-byte alignment. If you want to fix the bug in
the spot you've touched, you'd need to walk all the
stack_vars[stack_vars_sorted[si2]] for si2 [si + 1, n - 1] and for those
where the loop would do anything (i.e.
stack_vars[i2].representative == i2
&& TREE_CODE (decl2) == SSA_NAME
? SA.partition_to_pseudo[var_to_partition (SA.map, decl2)] == NULL_RTX
: DECL_RTL (decl2) == pc_rtx
and the pred applies (but that means also walking the earlier ones!
because with -fstack-protector* the vars can be processed in several calls)
and
alignb2 * BITS_PER_UNIT <= MAX_SUPPORTED_STACK_ALIGNMENT
and compute maximum of those alignments.
That maximum is already computed,
data->asan_alignb = MAX (data->asan_alignb, alignb);
computes that, but you get the final result only after you do all the
expand_stack_vars calls. You'd need to compute it before.
Though, that change would be still in the wrong place.
The thing is, it would be a waste of the precious stack space when it isn't
needed at all (e.g. when asan will not at compile time do the use after
return checking, or if it won't do it at runtime, or even if it will do at
runtime it will waste the space on the stack).
The following patch fixes it solely for the __asan_stack_malloc_N
allocations, doesn't enlarge unnecessarily further the actual stack frame.
Because asan is only supported on FRAME_GROWS_DOWNWARD architectures
(mips, rs6000 and xtensa are conditional FRAME_GROWS_DOWNWARD arches, which
for -fsanitize=address or -fstack-protector* use FRAME_GROWS_DOWNWARD 1,
otherwise 0, others supporting asan always just use 1), the assumption for
the dynamic stack realignment is that the top of the stack frame (aka
offset
0) is aligned to alignb passed to the function (which is the maximum of
alignb
of all the vars in the frame). As checked by the assertion in the patch,
offsets[0] is 0 most of the time and so that assumption is correct, the
only
case when it is not 0 is if -fstack-protector* is on together with
-fsanitize=address and cfgexpand.cc (create_stack_guard) created a stack
guard. That is the only variable which is allocated in the stack frame
right away, for all others with -fsanitize=address defer_stack_allocation
(or -fstack-protector*) returns true and so they aren't allocated
immediately but handled during the frame layout phases. So, the original
frame_offset of 0 is changed because of the stack guard to
-pointer_size_in_bytes and later at the
if (data->asan_vec.is_empty ())
{
align_frame_offset (ASAN_RED_ZONE_SIZE);
prev_offset = frame_offset.to_constant ();
}
to -ASAN_RED_ZONE_SIZE. The asan_emit_stack_protection code wasn't
taking this into account though, so essentially assumed in the
__asan_stack_malloc_N allocated memory it needs to align it such that
pointer corresponding to offsets[0] is alignb aligned. But that isn't
correct if alignb > ASAN_RED_ZONE_SIZE, in that case it needs to ensure
that
pointer corresponding to frame offset 0 is alignb aligned.
The following patch fixes that. Unlike the previous case where
we knew that asan_frame_size + base_align_bias falls into the same bucket
as asan_frame_size, this isn't in some cases true anymore, so the patch
recomputes which bucket to use and if going to bucket 11 (because there is
no __asan_stack_malloc_11 function in the library) disables the after
return
sanitization.
2024-04-11 Jakub Jelinek <jakub@redhat.com>
PR middle-end/110027
* asan.cc (asan_emit_stack_protection): Assert offsets[0] is
zero if there is no stack protect guard, otherwise
-ASAN_RED_ZONE_SIZE. If alignb > ASAN_RED_ZONE_SIZE and there is
stack pointer guard, take the ASAN_RED_ZONE_SIZE bytes allocated at
the top of the stack into account when computing base_align_bias.
Recompute use_after_return_class from asan_frame_size +
base_align_bias
and set to -1 if that would overflow to 11.
* gcc.dg/asan/pr110027.c: New test.
(cherry picked from commit 467898d513e602f5b5fc4183052217d7e6d6e8ab)
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug middle-end/110027] [11/12 regression] Stack objects with extended alignments (vectors etc) misaligned on detect_stack_use_after_return
2023-05-29 20:18 [Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return sneves at dei dot uc.pt
` (24 preceding siblings ...)
2024-04-21 4:09 ` cvs-commit at gcc dot gnu.org
@ 2024-04-23 6:44 ` jakub at gcc dot gnu.org
25 siblings, 0 replies; 27+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-04-23 6:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[11/12/13 regression] Stack |[11/12 regression] Stack
|objects with extended |objects with extended
|alignments (vectors etc) |alignments (vectors etc)
|misaligned on |misaligned on
|detect_stack_use_after_retu |detect_stack_use_after_retu
|rn |rn
--- Comment #25 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 13.3 too.
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2024-04-23 6:44 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-05-29 20:18 [Bug sanitizer/110027] New: Misaligned vector store on detect_stack_use_after_return sneves at dei dot uc.pt
2023-05-29 20:54 ` [Bug target/110027] " pinskia at gcc dot gnu.org
2023-05-30 8:06 ` rguenth at gcc dot gnu.org
2023-05-30 14:49 ` oconnor663 at gmail dot com
2023-10-22 18:06 ` gcc at sicherha dot de
2023-12-01 17:42 ` pinskia at gcc dot gnu.org
2023-12-01 17:46 ` pinskia at gcc dot gnu.org
2023-12-17 23:24 ` pinskia at gcc dot gnu.org
2024-03-08 4:13 ` pinskia at gcc dot gnu.org
2024-03-08 11:41 ` elrodc at gmail dot com
2024-03-08 18:10 ` gcc at sicherha dot de
2024-03-08 18:52 ` [Bug target/110027] [11/12/13/14 regression] " sjames at gcc dot gnu.org
2024-03-11 3:28 ` liuhongt at gcc dot gnu.org
2024-03-12 5:10 ` liuhongt at gcc dot gnu.org
2024-03-12 6:35 ` liuhongt at gcc dot gnu.org
2024-03-15 1:51 ` liuhongt at gcc dot gnu.org
2024-03-25 12:34 ` rguenth at gcc dot gnu.org
2024-04-08 15:43 ` xry111 at gcc dot gnu.org
2024-04-09 18:25 ` [Bug target/110027] [11/12/13/14 regression] Stack objects with extended alignments (vectors etc) misaligned " jakub at gcc dot gnu.org
2024-04-10 10:25 ` [Bug middle-end/110027] " jakub at gcc dot gnu.org
2024-04-11 6:53 ` liuhongt at gcc dot gnu.org
2024-04-11 8:16 ` jakub at gcc dot gnu.org
2024-04-11 9:14 ` cvs-commit at gcc dot gnu.org
2024-04-11 10:06 ` [Bug middle-end/110027] [11/12/13 " jakub at gcc dot gnu.org
2024-04-12 18:09 ` carlos.seo at linaro dot org
2024-04-21 4:09 ` cvs-commit at gcc dot gnu.org
2024-04-23 6:44 ` [Bug middle-end/110027] [11/12 " jakub at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).