On 9/6/19 4:46 PM, Matthew Malcomson wrote: > Hello, > > This patch series is a WORK-IN-PROGRESS towards porting the LLVM hardware > address sanitizer (HWASAN) in GCC. The document describing HWASAN can be > found > here http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html.
Hello. I'm happy that you are working on the functionality for GCC and I can provide my knowledge that I have with ASAN. I briefly read the patch series and I have multiple questions (and observations): 1) Is the ambition of the patchset to be a software emulation of MTE that can work targets that do not support MTE? Is it something what clang names hwasan-abi=interceptor? 2) Do you have a real aarch64 hardware that has MTE support? Would it be possible for the future to give such a machine to GCC Compile Farm for testing purpose? 3) I like the idea of sharing of internal functions like ASAN_CHECK/HWASAN_CHECK. We should benefit from that in the future. 4) Am I correct that due to escape of "tagged" pointers, one needs to have an entire DSO (dynamic shared object) built with hwasan enabled? Otherwise, a dereference of a tagged pointer will lead to a segfault (except TBI feature on aarch64)? 5) Is there a documentation/definition of how shadow memory for memory tagging looks like? Is it similar to ASAN, where one can get to tag with: u8 memory_tag = *((PTR >> TG) + SHADOW_OFFSET) & 0xf? 6) Note that thing like memtag_tag_size, memtag_granule_size define an ABI of libsanitizer > > The current patch series is far from complete, but I'm posting the current > state > to provide something to discuss at the Cauldron next week. > > In its current state, this sanitizer only works on AArch64 with a custom > kernel > to allow tagged pointers in system calls. This is discussed in the below link > https://source.android.com/devices/tech/debug/hwasan -- the custom kernel > allows > tagged pointers in syscalls. Can you be please more specific. Is the MTE in upstream linux kernel? If so, starting from which version? > I have also not yet put tests into the DejaGNU framework, but instead have a > simple test file from which the tests will eventually come. That test file is > attached to this email despite not being in the patch series. > > Something close to this patch series bootstraps and passes most regression > tests when ~--with-build-config=bootstrap-hwasan~ is used. The regressions it > doesn't pass are all the other sanitizer tests and all linker plugin tests. > The linker plugin tests fail due to a configuration problem where the library > path is not correctly set. > (I say "something close to this patch series" because I recently made a change > that breaks bootstrap but I believe is the best approach once I've fixed it, > hence for an RFC I'm leaving it in). > > HWASAN works by storing a tag in the top bits of every pointer and a colour in > a shadow memory region corresponding to every area of memory. On every memory > access through a pointer the tag in the pointer is checked against the colour > in > shadow memory corresponding to the memory the pointer is accessing. If the > tag > and colour do not match then a fault is signalled. > > The instrumentation required for this sanitizer has a large overlap with the > instrumentation required for implementing MTE (which has similar functionality > but checks are automatically done in the hardware and instructions for > colouring > shadow memory and for managing tags are provided by the architecture). > https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-a-profile-architecture-2018-developments-armv85a > > We hope to use the HWASAN framework to implement MTE tagging on the stack, and > hence I have a "dummy" patch demonstrating the approach envisaged for this. What's the situation with heap allocated memory and global variables? > > Though there is still much to implement here, the general approach should be > clear. Any feedback is welcomed, but I have three main points that I'm > particularly hoping for external opinions. > > 1) The current approach stores a tag on the RTL representing a given variable, > in order to implement HWASAN for x86_64 the tag needs to be removed before > every memory access but not on things like function calls. > Is there any obvious way to handle removing the tag in these places? > Maybe something with legitimize_address? Not being a target expect, but I bet you'll need to store the tag with a RTL representation of a stack variable. Thanks, Martin > 2) The first draft presented here introduces a new RTL expression called > ADDTAG. I now believe that a hook would be neater here but haven't yet > looked into it. Do people agree? > (addtag is introduced in the patch titled "Put tags into each stack > variable > pointer", but the reason it's introduced is so the backend can define how > this gets implemented with a ~define_expand~ and that's only needed for the > MTE handling as introduced in "Add in MTE stubs") > 3) This patch series has not yet had much thought go towards it around command > line arguments. I personally quite like the idea of having > ~-fsanitize=hwaddress~ turn on "checking memory tags against shadow memory > colour", and MTE being just a hardware acceleration of this ability. > I suspect this idea wouldn't be liked by all and would like to hear some > opinions. > > Thanks, > Matthew >
