Re: v2 [PATCH 0/X] Introduce HWASAN sanitizer to GCC
On 11/21/19 3:59 PM, Matthew Malcomson wrote: On 21/11/2019 13:10, Martin Liška wrote: On 11/20/19 6:40 PM, Matthew Malcomson wrote: On 20/11/2019 14:29, Martin Liška wrote: On 11/7/19 7:37 PM, Matthew Malcomson wrote: I have rebased this series onto Martin Liska's patches that take the most recent libhwasan from upstream LLVM. https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00340.html a) For ASAN we do have bunch of parameters: gcc --help=param | grep asan asan-stack Enable asan stack protection. asan-instrument-allocas Enable asan allocas/VLAs protection. asan-globals Enable asan globals protection. asan-instrument-writes Enable asan store operations protection. asan-instrument-reads Enable asan load operations protection. asan-memintrin Enable asan builtin functions protection. asan-use-after-return Enable asan detection of use-after-return bugs. asan-instrumentation-with-call-threshold Use callbacks instead of inline code if number of accesses in function becomes greater or equal to this number. We can probably use some of these in order to drive hwaddress in a similar way. Most of them makes sense for hwaddress as well I would prefer to keep the options different but would be happy to share them if others want. Works for me. I figure that there will be some parameters that make sense for hwasan but not for asan. For example hwasan-random-frame-tag doesn't have any analogue for asan. Re-using `asan-stack` for hwasan would mean we would then need to decide between having options with either `hwasan` or `asan` prefix being able to affect hwasan, or introducing a parameter `asan-random-frame-tag` that has no meaning on asan. Then, I would come up with additional hwasan-* parameters that can have the same semantic as the for asan (if it makes sense). Hello. Do you mean that I should add the options and the ability to toggle these features? Yes please, but it can be certainly added incrementally. The options that could eventually make sense for hwasan and that I haven't implemented are: hwasan-instrument-allocas hwasan-instrument-writes hwasan-instrument-reads hwasan-memintrin Works for me. hwasan-globals could eventually be done, but that's certainly not something I could implement quickly. b) Apparently clang prints also value of all registers. Do we want to do the same? I believe this only happens on clang for inline checking (try testing clang using the parameter `-mllvm --hwasan-instrument-with-calls` to see without). Are we talking about usage of __hwasan_check_x0_18? Using `-mllvm --hwasan-instrument-with-calls` uses function calls like `__hwasan_store4` (similar to the asan instrumentation with calls. The __hwasan_check_x* functions are the "generated checking functions with special calling conventions" I mentioned. The special checking functions are generated to accept a calling convention generated based on what would be optimal for where a check is needed. This custom calling convention can then also be used to keep track of what register values were around in the calling frame. This was introduced in clang at revision: llvm-svn: 351920 Ah ok, I see. Apparently it saves a lot of code size and speed as well. That's also a possible improvement. https://reviews.llvm.org/D56954 This would be nice to have, but I'm not planning on looking at it any time soon. This is currently implemented in clang on top of two not-yet implemented features: Inline instrumentation, and generated checking functions with special calling conventions. It's certainly not something I'm aiming to get into GCC 10. Which is fine. c) I'm a bit confused by the pointer tags, where clang does: Yeah -- I left out a description of short-tags. Hopefully my explanation in the below email helped. https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01968.html d) Are you planning to come up with inline stack variable tagging/untagging for GCC 10? To make sure I understand the question correctly: I think you're asking about writing tags into the shadow memory. Yes, which will be very similar to current ASAN code in asan_emit_stack_protection. I would expect a significant speed up from the inline shadow memory tag emission? Yes, I would also expect a significant speed up. Honestly, I doubt I could get this done properly by the end of stage 3. I'd be happy to give it a shot, but would not like to commit to it. Sure, we should start first with a working implementation and speed up patches can be added later. f) I would rename ASAN_MARK in tree dumps to HWASAN_MARK, similarly to what you did for HWASAN_CHECK? This is an artifact of a shortcut I made (and tried but probably failed to explain well in https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00392.html). For HWASAN_CHECK I introduced a new internal function that takes the
Re: v2 [PATCH 0/X] Introduce HWASAN sanitizer to GCC
On 21/11/2019 13:10, Martin Liška wrote: > On 11/20/19 6:40 PM, Matthew Malcomson wrote: >> On 20/11/2019 14:29, Martin Liška wrote: >>> On 11/7/19 7:37 PM, Matthew Malcomson wrote: I have rebased this series onto Martin Liska's patches that take the most recent libhwasan from upstream LLVM. https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00340.html >>> a) For ASAN we do have bunch of parameters: >>> >>> gcc --help=param | grep asan >>> asan-stack Enable asan stack protection. >>> asan-instrument-allocas Enable asan allocas/VLAs protection. >>> asan-globals Enable asan globals protection. >>> asan-instrument-writes Enable asan store operations protection. >>> asan-instrument-reads Enable asan load operations protection. >>> asan-memintrin Enable asan builtin functions >>> protection. >>> asan-use-after-return Enable asan detection of >>> use-after-return >>> bugs. >>> asan-instrumentation-with-call-threshold Use callbacks instead of >>> inline code if number of accesses in function becomes greater or equal >>> to this number. >>> >>> We can probably use some of these in order to drive hwaddress in a >>> similar way. Most of them makes sense for hwaddress as well >> >> >> I would prefer to keep the options different but would be happy to share >> them if others want. > > Works for me. > >> >> I figure that there will be some parameters that make sense for hwasan >> but not for asan. >> For example hwasan-random-frame-tag doesn't have any analogue for asan. >> Re-using `asan-stack` for hwasan would mean we would then need to decide >> between having options with either `hwasan` or `asan` prefix being able >> to affect hwasan, or introducing a parameter `asan-random-frame-tag` >> that has no meaning on asan. > > Then, I would come up with additional hwasan-* parameters that can have > the same semantic as the for asan (if it makes sense). > Do you mean that I should add the options and the ability to toggle these features? The options that could eventually make sense for hwasan and that I haven't implemented are: hwasan-instrument-allocas hwasan-instrument-writes hwasan-instrument-reads hwasan-memintrin hwasan-globals could eventually be done, but that's certainly not something I could implement quickly. >> >> >>> >>> b) Apparently clang prints also value of all registers. Do we want to do >>> the same? >>> >> >> I believe this only happens on clang for inline checking (try testing >> clang using the parameter `-mllvm --hwasan-instrument-with-calls` to see >> without). > > Are we talking about usage of __hwasan_check_x0_18? > Using `-mllvm --hwasan-instrument-with-calls` uses function calls like `__hwasan_store4` (similar to the asan instrumentation with calls. The __hwasan_check_x* functions are the "generated checking functions with special calling conventions" I mentioned. The special checking functions are generated to accept a calling convention generated based on what would be optimal for where a check is needed. This custom calling convention can then also be used to keep track of what register values were around in the calling frame. This was introduced in clang at revision: llvm-svn: 351920 https://reviews.llvm.org/D56954 >> >> This would be nice to have, but I'm not planning on looking at it any >> time soon. >> This is currently implemented in clang on top of two not-yet implemented >> features: Inline instrumentation, and generated checking functions with >> special calling conventions. >> >> It's certainly not something I'm aiming to get into GCC 10. > > Which is fine. > >> >> >>> >>> c) I'm a bit confused by the pointer tags, where clang does: >>> >> >> Yeah -- I left out a description of short-tags. >> Hopefully my explanation in the below email helped. >> https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01968.html >> >>> >>> d) Are you planning to come up with inline stack variable >>> tagging/untagging for GCC 10? >> >> To make sure I understand the question correctly: >> I think you're asking about writing tags into the shadow memory. > > Yes, which will be very similar to current ASAN code in > asan_emit_stack_protection. > I would expect a significant speed up from the inline shadow memory tag > emission? Yes, I would also expect a significant speed up. Honestly, I doubt I could get this done properly by the end of stage 3. I'd be happy to give it a shot, but would not like to commit to it. > >> >> >>> f) I would rename ASAN_MARK in tree dumps to HWASAN_MARK, similarly to >>> what you did >>> for HWASAN_CHECK? >> >> This is an artifact of a shortcut I made (and tried but probably failed >> to explain well in >> https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00392.html). >> >> For HWASAN_CHECK I introduced a new internal function that takes the >> same arguments as ASAN_CHECK, hence this new function is printed >>
Re: v2 [PATCH 0/X] Introduce HWASAN sanitizer to GCC
On 11/20/19 6:40 PM, Matthew Malcomson wrote: On 20/11/2019 14:29, Martin Liška wrote: On 11/7/19 7:37 PM, Matthew Malcomson wrote: I have rebased this series onto Martin Liska's patches that take the most recent libhwasan from upstream LLVM. https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00340.html I've also cleared up some nomenclature (I had previously used the word 'colour' a few times instead of the word 'tag' and that clashes with other descriptions) and based the patch series off a more recent GCC revision (r277678). There's an ongoing discussion on whether to have __SANITIZER_ADDRESS__, or __SANITIZER_HWADDRESS__, but I'm keeping that discussion to the existing thread. Similarly there's still the question around C++ exceptions that I'm keeping to the existing thread (on the first patch series). NOTE: Unfortunately, there's a bug in the more recent version of GCC I rebased onto. Hwasan catches this when bootstrapping, which means bootstrapping with hwasan fails. I'm working on tracking the bug down now, but sending this series upstream for visibility while that happens. Bugzilla link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92410 Entire patch series attached to cover letter.= Hello. Thank you very much for the patch set, I've just wrote some inline replies and I have also some questions/suggestions that I'll summarize here. One caveat, I'm not maintainer in any of the ideas and I must confirm that I haven't made a deep review of the part which relates to new RTL hooks and stack expansion. I expect Jakub can help us here. Questions/notes: a) For ASAN we do have bunch of parameters: gcc --help=param | grep asan asan-stack Enable asan stack protection. asan-instrument-allocas Enable asan allocas/VLAs protection. asan-globals Enable asan globals protection. asan-instrument-writes Enable asan store operations protection. asan-instrument-reads Enable asan load operations protection. asan-memintrin Enable asan builtin functions protection. asan-use-after-return Enable asan detection of use-after-return bugs. asan-instrumentation-with-call-threshold Use callbacks instead of inline code if number of accesses in function becomes greater or equal to this number. We can probably use some of these in order to drive hwaddress in a similar way. Most of them makes sense for hwaddress as well I would prefer to keep the options different but would be happy to share them if others want. Works for me. I figure that there will be some parameters that make sense for hwasan but not for asan. For example hwasan-random-frame-tag doesn't have any analogue for asan. Re-using `asan-stack` for hwasan would mean we would then need to decide between having options with either `hwasan` or `asan` prefix being able to affect hwasan, or introducing a parameter `asan-random-frame-tag` that has no meaning on asan. Then, I would come up with additional hwasan-* parameters that can have the same semantic as the for asan (if it makes sense). b) Apparently clang prints also value of all registers. Do we want to do the same? I believe this only happens on clang for inline checking (try testing clang using the parameter `-mllvm --hwasan-instrument-with-calls` to see without). Are we talking about usage of __hwasan_check_x0_18? This would be nice to have, but I'm not planning on looking at it any time soon. This is currently implemented in clang on top of two not-yet implemented features: Inline instrumentation, and generated checking functions with special calling conventions. It's certainly not something I'm aiming to get into GCC 10. Which is fine. c) I'm a bit confused by the pointer tags, where clang does: Yeah -- I left out a description of short-tags. Hopefully my explanation in the below email helped. https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01968.html d) Are you planning to come up with inline stack variable tagging/untagging for GCC 10? To make sure I understand the question correctly: I think you're asking about writing tags into the shadow memory. Yes, which will be very similar to current ASAN code in asan_emit_stack_protection. I would expect a significant speed up from the inline shadow memory tag emission? I wasn't planning on this. What I've posted has all the functionality I'm aiming to get in. My stretch goal at the moment is to handle exceptions (where I currently have a fundamental problem I'm trying to resolve). e) In hwasan_increment_tag, shouldn't you skip HWASAN_STACK_BACKGROUND color? Hopefully answered in https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01968.html Yes. f) I would rename ASAN_MARK in tree dumps to HWASAN_MARK, similarly to what you did for HWASAN_CHECK? This is an artifact of a shortcut I made (and tried but probably failed to explain well in
Re: v2 [PATCH 0/X] Introduce HWASAN sanitizer to GCC
On 20/11/2019 14:29, Martin Liška wrote: > On 11/7/19 7:37 PM, Matthew Malcomson wrote: >> I have rebased this series onto Martin Liska's patches that take the most >> recent libhwasan from upstream LLVM. >> https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00340.html >> >> I've also cleared up some nomenclature (I had previously used the word >> 'colour' >> a few times instead of the word 'tag' and that clashes with other >> descriptions) >> and based the patch series off a more recent GCC revision (r277678). >> >> There's an ongoing discussion on whether to have >> __SANITIZER_ADDRESS__, or >> __SANITIZER_HWADDRESS__, but I'm keeping that discussion to the existing >> thread. >> >> Similarly there's still the question around C++ exceptions that I'm >> keeping to >> the existing thread (on the first patch series). >> >> >> NOTE: >> Unfortunately, there's a bug in the more recent version of GCC I >> rebased >> onto. >> Hwasan catches this when bootstrapping, which means bootstrapping >> with hwasan >> fails. >> I'm working on tracking the bug down now, but sending this series >> upstream >> for visibility while that happens. >> >> Bugzilla link: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92410 >> >> Entire patch series attached to cover letter.= >> > > Hello. > > Thank you very much for the patch set, I've just wrote some inline replies > and I have also some questions/suggestions that I'll summarize here. One > caveat, > I'm not maintainer in any of the ideas and I must confirm that I haven't > made > a deep review of the part which relates to new RTL hooks and stack > expansion. > I expect Jakub can help us here. > > Questions/notes: > a) For ASAN we do have bunch of parameters: > > gcc --help=param | grep asan > asan-stack Enable asan stack protection. > asan-instrument-allocas Enable asan allocas/VLAs protection. > asan-globals Enable asan globals protection. > asan-instrument-writes Enable asan store operations protection. > asan-instrument-reads Enable asan load operations protection. > asan-memintrin Enable asan builtin functions protection. > asan-use-after-return Enable asan detection of use-after-return > bugs. > asan-instrumentation-with-call-threshold Use callbacks instead of > inline code if number of accesses in function becomes greater or equal > to this number. > > We can probably use some of these in order to drive hwaddress in a > similar way. Most of them makes sense for hwaddress as well I would prefer to keep the options different but would be happy to share them if others want. I figure that there will be some parameters that make sense for hwasan but not for asan. For example hwasan-random-frame-tag doesn't have any analogue for asan. Re-using `asan-stack` for hwasan would mean we would then need to decide between having options with either `hwasan` or `asan` prefix being able to affect hwasan, or introducing a parameter `asan-random-frame-tag` that has no meaning on asan. > > b) Apparently clang prints also value of all registers. Do we want to do > the same? > I believe this only happens on clang for inline checking (try testing clang using the parameter `-mllvm --hwasan-instrument-with-calls` to see without). This would be nice to have, but I'm not planning on looking at it any time soon. This is currently implemented in clang on top of two not-yet implemented features: Inline instrumentation, and generated checking functions with special calling conventions. It's certainly not something I'm aiming to get into GCC 10. > > c) I'm a bit confused by the pointer tags, where clang does: > Yeah -- I left out a description of short-tags. Hopefully my explanation in the below email helped. https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01968.html > > d) Are you planning to come up with inline stack variable > tagging/untagging for GCC 10? To make sure I understand the question correctly: I think you're asking about writing tags into the shadow memory. I wasn't planning on this. What I've posted has all the functionality I'm aiming to get in. My stretch goal at the moment is to handle exceptions (where I currently have a fundamental problem I'm trying to resolve). > e) In hwasan_increment_tag, shouldn't you skip HWASAN_STACK_BACKGROUND > color? Hopefully answered in https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01968.html > f) I would rename ASAN_MARK in tree dumps to HWASAN_MARK, similarly to > what you did > for HWASAN_CHECK? This is an artifact of a shortcut I made (and tried but probably failed to explain well in https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00392.html). For HWASAN_CHECK I introduced a new internal function that takes the same arguments as ASAN_CHECK, hence this new function is printed differently. For HWASAN_MARK, I used a trick to avoid adding "almost duplicate" code everywhere in
Re: v2 [PATCH 0/X] Introduce HWASAN sanitizer to GCC
On 11/7/19 7:37 PM, Matthew Malcomson wrote: I have rebased this series onto Martin Liska's patches that take the most recent libhwasan from upstream LLVM. https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00340.html I've also cleared up some nomenclature (I had previously used the word 'colour' a few times instead of the word 'tag' and that clashes with other descriptions) and based the patch series off a more recent GCC revision (r277678). There's an ongoing discussion on whether to have __SANITIZER_ADDRESS__, or __SANITIZER_HWADDRESS__, but I'm keeping that discussion to the existing thread. Similarly there's still the question around C++ exceptions that I'm keeping to the existing thread (on the first patch series). NOTE: Unfortunately, there's a bug in the more recent version of GCC I rebased onto. Hwasan catches this when bootstrapping, which means bootstrapping with hwasan fails. I'm working on tracking the bug down now, but sending this series upstream for visibility while that happens. Bugzilla link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92410 Entire patch series attached to cover letter.= Hello. Thank you very much for the patch set, I've just wrote some inline replies and I have also some questions/suggestions that I'll summarize here. One caveat, I'm not maintainer in any of the ideas and I must confirm that I haven't made a deep review of the part which relates to new RTL hooks and stack expansion. I expect Jakub can help us here. Questions/notes: a) For ASAN we do have bunch of parameters: gcc --help=param | grep asan asan-stack Enable asan stack protection. asan-instrument-allocas Enable asan allocas/VLAs protection. asan-globalsEnable asan globals protection. asan-instrument-writes Enable asan store operations protection. asan-instrument-reads Enable asan load operations protection. asan-memintrin Enable asan builtin functions protection. asan-use-after-return Enable asan detection of use-after-return bugs. asan-instrumentation-with-call-threshold Use callbacks instead of inline code if number of accesses in function becomes greater or equal to this number. We can probably use some of these in order to drive hwaddress in a similar way. Most of them makes sense for hwaddress as well b) Apparently clang prints also value of all registers. Do we want to do the same? $ clang /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/hwasan/stack-tagging-basic-1.c -fsanitize=hwaddress && ./a.out ... Tags for short granules around the buggy address (one tag corresponds to 16 bytes): .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. => .. .. .. .. .. .. .. .. e9 .. [..] .. .. .. .. .. <= .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. See https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html#short-granules for a description of short granule tags Registers where the failure occurred (pc 0xb2976d60): x0 0063 x1 f763249c x2 e900f76324a4 x3 b2976d94 x4 x5 165a043ab8eb3734 x6 x7 b299f99c x8 0011 x9 0200efff x10 x11 0063 x12 0200fffeff763241 x13 0011 x14 0008 x15 c000e9e9 x16 b2959b88 x17 0007 x18 0040 x19 b2977148 x20 x21 b2950388 x22 x23 x24 x25 x26 x27 x28 x29 f76324a0 x30 b2976d60 SUMMARY: HWAddressSanitizer: tag-mismatch (/home/marxin/Programming/gcc/a.out+0x2cd5c) in using_stack c) I'm a bit confused by the pointer tags, where clang does: $ clang /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/hwasan/stack-tagging-basic-1.c -fsanitize=hwaddress && ./a.out ==30028==ERROR: HWAddressSanitizer: tag-mismatch on address 0xf76324a4 at pc 0xb2976d60 READ of size 4 at 0xf76324a4 tags: e9/00 (ptr/mem) in thread T0 #0 0xb2976d5c in using_stack (/home/marxin/Programming/gcc/a.out+0x2cd5c) #1 0xb2976e08 in main (/home/marxin/Programming/gcc/a.out+0x2ce08) #2 0x83ca73e8 in __libc_start_main (/lib64/libc.so.6+0x243e8) #3 0xb29503b8 in _start /home/abuild/rpmbuild/BUILD/glibc-2.30/csu/../sysdeps/aarch64/start.S:92 Address 0xf76324a4 is located in stack of thread T0 Thread: T0 0xeffe2000 stack: [0xf6e33000,0xf7633000) sz: 8388608 tls: [0x83f82d20,0x83f83470) Previously allocated frames: record_addr:0x83c68748 record:0x324ab2976c8c in using_stack (/home/marxin/Programming/gcc/a.out+0x2cc8c) Memory tags around the buggy address (one tag corresponds to 16 bytes): 00 00 00 00 00 00 00 00 00 00 00 00
Re: v2 [PATCH 0/X] Introduce HWASAN sanitizer to GCC
On 11/11/2019 16:13, Matthew Malcomson wrote: > On 07/11/2019 18:37, Matthew Malcomson wrote: >> I have rebased this series onto Martin Liska's patches that take the most >> recent libhwasan from upstream LLVM. >> https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00340.html >> >> I've also cleared up some nomenclature (I had previously used the word >> 'colour' >> a few times instead of the word 'tag' and that clashes with other >> descriptions) >> and based the patch series off a more recent GCC revision (r277678). >> >> There's an ongoing discussion on whether to have __SANITIZER_ADDRESS__, or >> __SANITIZER_HWADDRESS__, but I'm keeping that discussion to the existing >> thread. >> >> Similarly there's still the question around C++ exceptions that I'm keeping >> to >> the existing thread (on the first patch series). >> >> >> NOTE: >> Unfortunately, there's a bug in the more recent version of GCC I rebased >> onto. >> Hwasan catches this when bootstrapping, which means bootstrapping with >> hwasan >> fails. >> I'm working on tracking the bug down now, but sending this series >> upstream >> for visibility while that happens. >> >> Bugzilla link: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92410 >> >> Entire patch series attached to cover letter. >> > > It seems that PR 92410 is a little more extensive than it originally > looked (in fixing it I saw instances of the same basic problem elsewhere > too). > > Just in case anyone wants to take a look at this HWASAN series in the > meantime there are two ways: > > 1) Bootstrap with hwasan not crashing on error. > > 2) Apply the last patch I posted on > http://pdtlreviewboard.cambridge.arm.com/r/12149/ Oops -- clipboard didn't have what I thought it did. I meant https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92410 here. > > > Number 1 requires the patch below and to run make with HWASAN_OPTIONS > set to "halt_on_error=0 exitcode=0". > > diff --git a/config/bootstrap-hwasan.mk b/config/bootstrap-hwasan.mk > index 91989f4..3672b91 100644 > --- a/config/bootstrap-hwasan.mk > +++ b/config/bootstrap-hwasan.mk > @@ -4,8 +4,8 @@ ># breaks. Running with a random frame tag gives approx. 50% chance of ># bootstrap comparison diff in libiberty/alloca.c. > > -STAGE2_CFLAGS += -fsanitize=hwaddress --param hwasan-random-frame-tag=0 > -STAGE3_CFLAGS += -fsanitize=hwaddress --param hwasan-random-frame-tag=0 > +STAGE2_CFLAGS += -fsanitize-recover=hwaddress -fsanitize=hwaddress > --param hwasan-random-frame-tag=0 > +STAGE3_CFLAGS += -fsanitize-recover=hwaddress -fsanitize=hwaddress > --param hwasan-random-frame-tag=0 >POSTSTAGE1_LDFLAGS += -fsanitize=hwaddress -static-libhwasan \ > -B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/ \ > -B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/hwasan/ \ > > > > > Number 2 option avoids the current problem, but causes two extra > testsuite failures (unrelated to hwasan) in gcc.dg/fold-eqandshift-1.c > and gcc.c-torture/compile/pr32482.c. > These are existing bugs that a new `assert` catches. >
Re: v2 [PATCH 0/X] Introduce HWASAN sanitizer to GCC
On 07/11/2019 18:37, Matthew Malcomson wrote: > I have rebased this series onto Martin Liska's patches that take the most > recent libhwasan from upstream LLVM. > https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00340.html > > I've also cleared up some nomenclature (I had previously used the word > 'colour' > a few times instead of the word 'tag' and that clashes with other > descriptions) > and based the patch series off a more recent GCC revision (r277678). > > There's an ongoing discussion on whether to have __SANITIZER_ADDRESS__, or > __SANITIZER_HWADDRESS__, but I'm keeping that discussion to the existing > thread. > > Similarly there's still the question around C++ exceptions that I'm keeping to > the existing thread (on the first patch series). > > > NOTE: >Unfortunately, there's a bug in the more recent version of GCC I rebased >onto. >Hwasan catches this when bootstrapping, which means bootstrapping with > hwasan >fails. >I'm working on tracking the bug down now, but sending this series upstream >for visibility while that happens. > >Bugzilla link: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92410 > > Entire patch series attached to cover letter. > It seems that PR 92410 is a little more extensive than it originally looked (in fixing it I saw instances of the same basic problem elsewhere too). Just in case anyone wants to take a look at this HWASAN series in the meantime there are two ways: 1) Bootstrap with hwasan not crashing on error. 2) Apply the last patch I posted on http://pdtlreviewboard.cambridge.arm.com/r/12149/ Number 1 requires the patch below and to run make with HWASAN_OPTIONS set to "halt_on_error=0 exitcode=0". diff --git a/config/bootstrap-hwasan.mk b/config/bootstrap-hwasan.mk index 91989f4..3672b91 100644 --- a/config/bootstrap-hwasan.mk +++ b/config/bootstrap-hwasan.mk @@ -4,8 +4,8 @@ # breaks. Running with a random frame tag gives approx. 50% chance of # bootstrap comparison diff in libiberty/alloca.c. -STAGE2_CFLAGS += -fsanitize=hwaddress --param hwasan-random-frame-tag=0 -STAGE3_CFLAGS += -fsanitize=hwaddress --param hwasan-random-frame-tag=0 +STAGE2_CFLAGS += -fsanitize-recover=hwaddress -fsanitize=hwaddress --param hwasan-random-frame-tag=0 +STAGE3_CFLAGS += -fsanitize-recover=hwaddress -fsanitize=hwaddress --param hwasan-random-frame-tag=0 POSTSTAGE1_LDFLAGS += -fsanitize=hwaddress -static-libhwasan \ -B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/ \ -B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/hwasan/ \ Number 2 option avoids the current problem, but causes two extra testsuite failures (unrelated to hwasan) in gcc.dg/fold-eqandshift-1.c and gcc.c-torture/compile/pr32482.c. These are existing bugs that a new `assert` catches.
v2 [PATCH 0/X] Introduce HWASAN sanitizer to GCC
I have rebased this series onto Martin Liska's patches that take the most recent libhwasan from upstream LLVM. https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00340.html I've also cleared up some nomenclature (I had previously used the word 'colour' a few times instead of the word 'tag' and that clashes with other descriptions) and based the patch series off a more recent GCC revision (r277678). There's an ongoing discussion on whether to have __SANITIZER_ADDRESS__, or __SANITIZER_HWADDRESS__, but I'm keeping that discussion to the existing thread. Similarly there's still the question around C++ exceptions that I'm keeping to the existing thread (on the first patch series). NOTE: Unfortunately, there's a bug in the more recent version of GCC I rebased onto. Hwasan catches this when bootstrapping, which means bootstrapping with hwasan fails. I'm working on tracking the bug down now, but sending this series upstream for visibility while that happens. Bugzilla link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92410 Entire patch series attached to cover letter. all-patches.tar.gz Description: all-patches.tar.gz
