Re: clang address sanitizer findings
On Sun, May 05, 2019 at 08:49:10PM +0200, Willy Tarreau wrote: > Bingo! Alignment was forced to 2^5 when using the sanitizer, which > causes it not only to detect issues, but may even cause some crashes > upon startup when trying to dereference padding as function pointers. > > You may want to try to apply the following change, though I'm not much > convinced : (...) OK no need to waste your time on this one, I could reproduce the problem and it's indeed when clang or gcc uses -fsanitize=address tht this problem arises. And haproxy cannot even detect it since the size of the symbols themselves doesn't include the padding. So in this case you need to switch to USE_OBSOLETE_LINKER=1. Willy
Re: clang address sanitizer findings
On Sun, May 05, 2019 at 11:36:46PM +0500, ??? wrote: > with sanitizer: > 27 init_STG_POOL 0800 00afb3a0 00afb3a0 006fa3a0 > 2**5 > CONTENTS, ALLOC, LOAD, DATA > 28 init_STG_LOCK 02c0 00afbba0 00afbba0 006faba0 > 2**5 > CONTENTS, ALLOC, LOAD, DATA > 29 init_STG_REGISTER 23c0 00afbe60 00afbe60 > 006fae60 2**5 > CONTENTS, ALLOC, LOAD, DATA > 30 init_STG_PREPARE 0100 00afe220 00afe220 > 006fd220 2**5 > CONTENTS, ALLOC, LOAD, DATA (...) > without sanitizer: > 25 init_STG_POOL 0100 005c3090 005c3090 001c2090 > 2**3 > CONTENTS, ALLOC, LOAD, DATA > 26 init_STG_LOCK 0058 005c3190 005c3190 001c2190 > 2**3 > CONTENTS, ALLOC, LOAD, DATA > 27 init_STG_REGISTER 0478 005c31e8 005c31e8 > 001c21e8 2**3 > CONTENTS, ALLOC, LOAD, DATA > 28 init_STG_PREPARE 0020 005c3660 005c3660 > 001c2660 2**3 Bingo! Alignment was forced to 2^5 when using the sanitizer, which causes it not only to detect issues, but may even cause some crashes upon startup when trying to dereference padding as function pointers. You may want to try to apply the following change, though I'm not much convinced : diff --git a/include/common/initcall.h b/include/common/initcall.h index 6da752c..f19d91c 100644 --- a/include/common/initcall.h +++ b/include/common/initcall.h @@ -104,7 +104,7 @@ struct initcall { __GLOBL(__start_init_##stg ); \ __GLOBL(__stop_init_##stg ); \ static const struct initcall *__initcb_##linenum \ - __attribute__((__used__,HA_SECTION(stg))) =\ + __attribute__((__used__,aligned(8),HA_SECTION(stg))) = \ (stg < STG_SIZE) ? &(const struct initcall) { \ .fct = (void (*)(void *,void *,void *))function, \ .arg1 = (void *)(a1), \ Otherwise you may simply prefer to build with USE_OBSOLETE_LINKER=1 when building with the address sanitizer as this one will make use of larger linked lists but will be insensitive to alignment. Cheers, willy
Re: clang address sanitizer findings
with sanitizer: $ objdump -h haproxy haproxy: file format elf64-x86-64 Sections: Idx Name Size VMA LMA File off Algn 0 .interp 001c 004002e0 004002e0 02e0 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .note.ABI-tag 0020 004002fc 004002fc 02fc 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .note.gnu.build-id 0024 0040031c 0040031c 031c 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .gnu.hash 62b4 00400340 00400340 0340 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .dynsym 00015918 004065f8 004065f8 65f8 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .dynstr 00012388 0041bf10 0041bf10 0001bf10 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .gnu.version 1cc2 0042e298 0042e298 0002e298 2**1 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .gnu.version_r 01d0 0042ff60 0042ff60 0002ff60 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 8 .rela.dyn 03f0 00430130 00430130 00030130 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 9 .rela.plt 2940 00430520 00430520 00030520 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 10 .init 001b 00433000 00433000 00033000 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 11 .plt 1b90 00433020 00433020 00033020 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 12 .text 00531882 00434bb0 00434bb0 00034bb0 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 13 .fini 000d 00966434 00966434 00566434 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 14 .rodata 000cd406 00967000 00967000 00567000 2**5 CONTENTS, ALLOC, LOAD, READONLY, DATA 15 .eh_frame_hdr a06c 00a34408 00a34408 00634408 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 16 .eh_frame 00036ec8 00a3e478 00a3e478 0063e478 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 17 .tdata0080 00a77110 00a77110 00676110 2**4 CONTENTS, ALLOC, LOAD, DATA, THREAD_LOCAL 18 .tbss a854 00a77190 00a77190 00676190 2**4 ALLOC, THREAD_LOCAL 19 .preinit_array 0008 00a77190 00a77190 00676190 2**3 CONTENTS, ALLOC, LOAD, DATA 20 .init_array 03a8 00a77198 00a77198 00676198 2**3 CONTENTS, ALLOC, LOAD, DATA 21 .fini_array 02f8 00a77540 00a77540 00676540 2**3 CONTENTS, ALLOC, LOAD, DATA 22 .data.rel.ro 03a8 00a77840 00a77840 00676840 2**5 CONTENTS, ALLOC, LOAD, DATA 23 .dynamic 02b0 00a77be8 00a77be8 00676be8 2**3 CONTENTS, ALLOC, LOAD, DATA 24 .got 0150 00a77e98 00a77e98 00676e98 2**3 CONTENTS, ALLOC, LOAD, DATA 25 .got.plt 0dd8 00a78000 00a78000 00677000 2**3 CONTENTS, ALLOC, LOAD, DATA 26 .data 000825c0 00a78de0 00a78de0 00677de0 2**5 CONTENTS, ALLOC, LOAD, DATA 27 init_STG_POOL 0800 00afb3a0 00afb3a0 006fa3a0 2**5 CONTENTS, ALLOC, LOAD, DATA 28 init_STG_LOCK 02c0 00afbba0 00afbba0 006faba0 2**5 CONTENTS, ALLOC, LOAD, DATA 29 init_STG_REGISTER 23c0 00afbe60 00afbe60 006fae60 2**5 CONTENTS, ALLOC, LOAD, DATA 30 init_STG_PREPARE 0100 00afe220 00afe220 006fd220 2**5 CONTENTS, ALLOC, LOAD, DATA 31 .bss 009c6990 00afe340 00afe340 006fd320 2**6 ALLOC 32 .comment 0087 006fd320 2**0 CONTENTS, READONLY 33 .gnu.build.attributes 00038af4 014c6cd0 014c6cd0 006fd3a8 2**2 CONTENTS, READONLY 34 .debug_info 002b4bf1 00735e9c 2**0 CONTENTS, READONLY, DEBUGGING 35 .debug_abbrev 000142b8 009eaa8d 2**0 CONTENTS, READONLY, DEBUGGING 36 .debug_line 001bcd73 009fed45 2**0 CONTENTS, READONLY, DEBUGGING 37 .debug_str0001e422 00bbbab8 2**0
Re: clang address sanitizer findings
On Sun, May 05, 2019 at 03:04:22PM +0500, ??? wrote: > Hello, > > I run fedora 30, it includes clang-8, I built haproxy using > > make CC=clang V=1 TARGET=$TARGET $FLAGS DEBUG_CFLAGS="-fsanitize=address > -ggdb" LDFLAGS="-fsanitize=address" > > when running reg-tests, the following is caught > > ==6340==ERROR: AddressSanitizer: global-buffer-overflow on address > 0x00ab61c8 at pc 0x007360f5 bp 0x7ffc56ce9f90 sp 0x7ffc56ce9f88 > READ of size 8 at 0x00ab61c8 thread T0 > #0 0x7360f4 (/home/ilia/haproxy/haproxy+0x7360f4) > #1 0x7f3952660f32 (/lib64/libc.so.6+0x23f32) > #2 0x434b7d (/home/ilia/haproxy/haproxy+0x434b7d) > > 0x00ab61c8 is located 56 bytes to the left of global variable > '__initcb_486' defined in 'src/task.c:486:1' (0xab6200) of size 8 > 0x00ab61c8 is located 0 bytes to the right of global variable > '__initcb_1865' defined in 'src/log.c:1865:1' (0xab61c0) of size 8 > SUMMARY: AddressSanitizer: global-buffer-overflow > (/home/ilia/haproxy/haproxy+0x7360f4) This one is quite strange, it looks as if the linker had intentionally left holes in the init_* sections by aligning each pointer on 64 bytes. Maybe this is an artefact of using -fsanitize=address, though it seems a bit unlikely. Could you please run "objdump -h" on your haproxy executable with and without this build option ? I suspect we'll see "2**6" at the end of some init_* columns at least in one case. If so we may try to add "aligned(8)" or even "packed" to the attributes when declaring the initcalls. Thanks, Willy