search for: hwasan

This commit has added __hwasan_memset to compiler-rt: commit 749bd83b08b7239f5d18c4e3095183919c68eb30 Author: Eugene Leviant <eleviant at accesssoftek.com> Date: Thu Dec 20 09:10:03 2018 +0000 [HWASAN] Add support for memory intrinsics This is patch complements D55117 implementing __hwasan_mem* functions i...

After updating from trunk today, I am seeing this failure in hwasan: FAIL: HWAddressSanitizer-x86_64 :: TestCases/sizes.cpp (19011 of 49508) ******************** TEST 'HWAddressSanitizer-x86_64 :: TestCases/sizes.cpp' FAILED ******************** <snip> Command Output (stderr): -- + : 'RUN: at line 1' + /build/./bin/clang --driver-mode=g++ -fs...

Hello, I'm working on implementing hwasan instrumentation in GCC, and have just started discussing my current work-in-progress on the gcc-patches mailing list. (https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00387.html -- the email that Kostya saw and added people to). I've gotten about as basic a user-space implementation as possible...

Hi, On Fri, Sep 20, 2019 at 6:48 AM Matthew Malcomson <Matthew.Malcomson at arm.com> wrote: > > Hello again, > > I have been thinking more about the GCC implementation of hwasan and > found a few more questions that I would really appreciate help with. > > --- > I've noticed a match-all condition in the compiler inline > instrumentation, but can't see where it's used in the libhwasan function > call checks. Is that a planned behaviour or am I...

...d 40 b2 orr x8, x8, #0xffffffff 2d4e0: 08 05 00 91 add x8, x8, #1 2d4e4: a2 13 00 d1 sub x2, x29, #4 2d4e8: e9 03 08 aa mov x9, x8 2d4ec: df 64 ff 97 bl #-158852 <__hwasan_check_x2_18_short> 2d4f0: ea 03 1f 2a mov w10, wzr 2d4f4: aa c3 1f b8 stur w10, [x29, #-4] 2d4f8: a2 23 00 d1 sub x2, x29, #8 2d4fc: e9 03 08 aa mov x9, x8 2d500: da 64 ff 97...

Hello again, I had hoped that rc4 would be the last one, but I wanted to pick up one more fix, so here we go. Release Candidate 5 was just tagged as llvmorg-10.0.0-rc5 on the release branch at 35627038123. Source code and docs are available at https://prereleases.llvm.org/10.0.0/#rc5 and https://github.com/llvm/llvm-project/releases/tag/llvmorg-10.0.0-rc5 If nothing new comes up, I plan to tag

...r-rt. It will leverage support within sanitizer_common, which already contains facilities like stack context tracking, needed by the heap profiler. Shadow Memory There are some basic facilities in sanitizer_common for mmap’ing the shadow memory, but most of the existing setup lives in the ASAN and HWASAN libraries. In the case of ASAN, there is support for both statically assigned shadow offsets (the default on most platforms), and for dynamically assigned shadow memory (implemented for Windows and currently also used for Android and iOS). According to kcc, recent experiments show that the performa...

...er. > It was partially motivated by my looking to see what version of shadow setup to use, as they initially looked somewhat different, only to discover after carefully tracing through all the values that they were essentially identical but just structured differently (at least between asan and hwasan). This is somewhat philosophical, but to me it seems better to refactor when possible. > > One question about granularity: tcmalloc's allocation granularity is 8, so > by using 64- or 32- byte granules you lose some of the precision. > It depends what you mean by precision. For a...

...needs to be clarified -- hopefully we can start the discussion here? (Please feel free to add people to the thread that you think would be interested). I'll outline some possible approaches that I think seem good below, I know Evgenii and Peter have done a lot of investigation in this area for HWASAN, so I'm hoping you can see any problems I've missed, or indeed propose something better if there's another approach ;-) --- Extra restriction on landing pads --- No matter what the approach, I believe it would be helpful to require stacks tagged for MTE to have landing pads which 1)...

...upport within sanitizer_common, which already contains facilities > like stack context tracking, needed by the heap profiler. > Shadow Memory > > There are some basic facilities in sanitizer_common for mmap’ing the > shadow memory, but most of the existing setup lives in the ASAN and HWASAN > libraries. In the case of ASAN, there is support for both statically > assigned shadow offsets (the default on most platforms), and for > dynamically assigned shadow memory (implemented for Windows and currently > also used for Android and iOS). According to kcc, recent experiments sh...

...common, which already contains > facilities like stack context tracking, needed by the heap profiler. > > > Shadow Memory > > There are some basic facilities in sanitizer_common for mmap’ing the > shadow memory, but most of the existing setup lives in the ASAN and > HWASAN libraries. In the case of ASAN, there is support for both > statically assigned shadow offsets (the default on most platforms), > and for dynamically assigned shadow memory (implemented for Windows > and currently also used for Android and iOS). According to kcc, recent > experiment...

...> initially thought. The mitigating factor is that we are focused on unit > tests as opposed to running the full blown application. > > > > The pointers are 32-bit, right? > > Given how RAM-constrained your environment is, maybe you should consider > something more like HWASAN instead of ASAN. > > https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html > > But you may not have enough address bits. :( > > Pointers are 32 bits. Interesting idea, but I agree I don't think we have > enough bits. Even ignoring the sparsely used lower...

...e RAM overhead, but I am afraid this will actually increase it due to extra alignment requirements, especially if an average allocation on your typical application is small. The pointers are 32-bit, right? Given how RAM-constrained your environment is, maybe you should consider something more like HWASAN instead of ASAN. https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html But you may not have enough address bits. :( --kcc On Fri, May 4, 2018 at 3:10 PM Kostya Serebryany <kcc at google.com> wrote: > Hi Walter, > > I've done a first quick scan. > Overall...

...n't been as big an issue as I initially thought. The mitigating factor is that we are focused on unit tests as opposed to running the full blown application. > The pointers are 32-bit, right? > Given how RAM-constrained your environment is, maybe you should consider something more like HWASAN instead of ASAN. > https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html > But you may not have enough address bits. :( Pointers are 32 bits. Interesting idea, but I agree I don't think we have enough bits. Even ignoring the sparsely used lower addresses, DDR + cache...

...itially thought. The mitigating factor is that we are focused on unit >> tests as opposed to running the full blown application. >> > The pointers are 32-bit, right? >> > Given how RAM-constrained your environment is, maybe you should consider >> something more like HWASAN instead of ASAN. >> > https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html >> > But you may not have enough address bits. :( >> Pointers are 32 bits. Interesting idea, but I agree I don't think we have >> enough bits. Even ignoring the sparsel...

I believe a good amount of them (if not most of them) have already been ported! Off the top of my head, I remember that asan, tsan, msan, hwasan, the kernel santizers, and sancov have been ported. I don't think ubsan has been ported yet though. You can also check if other passes you need run under the new PM by checking PassRegistry.def. On Fri, Aug 2, 2019, 14:20 Jordan Rupprecht <rupprecht at google.com> wrote: > Hi Leonar...

Thanks for the confirmation. From the assembly that was sent on the other branch of the thread: > .set .L.str, .L.str.hwasan-3458764513820540928 -3458764513820540928 = 0xd0 << 56 i.e. a "negative" tag. So this appears to be the issue exactly. Peter On Mon, Jun 22, 2020 at 1:55 PM Derrick McKee <derrick.mckee at gmail.com> wrote: > Using lld fixes this issue. > > On Mon, Jun 22, 2020 at...

...ndows. [r322102](http://reviews.llvm.org/rL322102). * A new pass has been introduced to generate 'synthetic function entry counts'. This is a heuristic used to influence inlining. [r322110](http://reviews.llvm.org/rL322110). * An initial stack instrumentation pass has been implemented for HWASan. [r322324](http://reviews.llvm.org/rL322324). ## Clang commits * The target attribute can now be used for function multiversioning as in GCC. This allows multiple versions of a function to be generated, with each version specialised for a target feature (e.g. neon, avx). [r322028](http://reviews...

...ation pass was added to sink copies into a successor block. [r328237](http://reviews.llvm.org/rL328237). * MIR printing, `opt -dot-cfg` and `-debug` printing has been made substantially faster by making the scanning of a module for struct types lazy. [r328246](http://reviews.llvm.org/rL328246). * HWASan has been ported to Linux x86-64. [r328342](http://reviews.llvm.org/rL328342). * TargetLoweringObjectFile has been moved from CodeGen to Target, MachineValueType from CodeGen to Support, and ValueTypes from CodeGen to IR. [r328392](http://reviews.llvm.org/rL328392), [r328395](http://reviews.llvm.or...

...mented in the Scudo hardened allocator (compiler-rt/lib/scudo/standalone) for heap, and stack allocation is implemented in LLVM/Clang behind -fsanitize=memtag <https://llvm.org/docs/MemTagSanitizer.html>. As part of a holistic MTE implementation, global memory should also be properly tagged. HWASan <http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html> (a software-only implementation of MTE) has a schema that uses static tags, however these can be trivially determined by an attacker with access to the ELF file. This would allow attackers with arbitrary read/write to tr...