maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Instrumentation/DataFlowSanitizer/basic.ll

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

52 lines
2.7 KiB
LLVM
Raw Normal View History

[DFSan] Change shadow and origin memory layouts to match MSan. Previously on x86_64: +--------------------+ 0x800000000000 (top of memory) | application memory | +--------------------+ 0x700000008000 (kAppAddr) | | | unused | | | +--------------------+ 0x300000000000 (kUnusedAddr) | origin | +--------------------+ 0x200000008000 (kOriginAddr) | unused | +--------------------+ 0x200000000000 | shadow memory | +--------------------+ 0x100000008000 (kShadowAddr) | unused | +--------------------+ 0x000000010000 | reserved by kernel | +--------------------+ 0x000000000000 MEM_TO_SHADOW(mem) = mem & ~0x600000000000 SHADOW_TO_ORIGIN(shadow) = kOriginAddr - kShadowAddr + shadow Now for x86_64: +--------------------+ 0x800000000000 (top of memory) | application 3 | +--------------------+ 0x700000000000 | invalid | +--------------------+ 0x610000000000 | origin 1 | +--------------------+ 0x600000000000 | application 2 | +--------------------+ 0x510000000000 | shadow 1 | +--------------------+ 0x500000000000 | invalid | +--------------------+ 0x400000000000 | origin 3 | +--------------------+ 0x300000000000 | shadow 3 | +--------------------+ 0x200000000000 | origin 2 | +--------------------+ 0x110000000000 | invalid | +--------------------+ 0x100000000000 | shadow 2 | +--------------------+ 0x010000000000 | application 1 | +--------------------+ 0x000000000000 MEM_TO_SHADOW(mem) = mem ^ 0x500000000000 SHADOW_TO_ORIGIN(shadow) = shadow + 0x100000000000 Reviewed By: stephan.yichao.zhao, gbalats Differential Revision: https://reviews.llvm.org/D104896
2021-06-25 13:16:36 +08:00
; RUN: opt < %s -dfsan -S | FileCheck %s --check-prefixes=CHECK,CHECK_NO_ORIGIN -DSHADOW_XOR_MASK=87960930222080 --dump-input-context=100
[dfsan] Expose dfsan_get_track_origins to get origin tracking status This allows application code checks if origin tracking is on before printing out traces. -dfsan-track-origins can be 0,1,2. The current code only distinguishes 1 and 2 in compile time, but not at runtime. Made runtime distinguish 1 and 2 too. Reviewed By: browneee Differential Revision: https://reviews.llvm.org/D105128
2021-06-29 14:17:00 +08:00
; RUN: opt < %s -dfsan -dfsan-track-origins=1 -S | FileCheck %s --check-prefixes=CHECK,CHECK_ORIGIN1 -DSHADOW_XOR_MASK=87960930222080 --dump-input-context=100
; RUN: opt < %s -dfsan -dfsan-track-origins=2 -S | FileCheck %s --check-prefixes=CHECK_ORIGIN2 -DSHADOW_XOR_MASK=87960930222080 --dump-input-context=100
[dfsan] Instrument origin variable and function definitions This is a part of https://reviews.llvm.org/D95835. Reviewed-by: morehouse, gbalats Differential Revision: https://reviews.llvm.org/D96977
2021-02-19 02:29:21 +08:00
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
; CHECK: @__dfsan_arg_tls = external thread_local(initialexec) global [100 x i64]
; CHECK: @__dfsan_retval_tls = external thread_local(initialexec) global [100 x i64]
; CHECK: @__dfsan_arg_origin_tls = external thread_local(initialexec) global [200 x i32]
; CHECK: @__dfsan_retval_origin_tls = external thread_local(initialexec) global i32
; CHECK_NO_ORIGIN: @__dfsan_track_origins = weak_odr constant i32 0
[dfsan] Expose dfsan_get_track_origins to get origin tracking status This allows application code checks if origin tracking is on before printing out traces. -dfsan-track-origins can be 0,1,2. The current code only distinguishes 1 and 2 in compile time, but not at runtime. Made runtime distinguish 1 and 2 too. Reviewed By: browneee Differential Revision: https://reviews.llvm.org/D105128
2021-06-29 14:17:00 +08:00
; CHECK_ORIGIN1: @__dfsan_track_origins = weak_odr constant i32 1
; CHECK_ORIGIN2: @__dfsan_track_origins = weak_odr constant i32 2
[dfsan] Record dfsan metadata in globals This will allow identifying exactly how many shadow bytes were used during compilation, for when fast8 mode is introduced. Also, it will provide a consistent matching point for instrumentation tests so that the exact llvm type used (i8 or i16) for the shadow can be replaced by a pattern substitution. This is handy for tests with multiple prefixes. Reviewed by: stephan.yichao.zhao, morehouse Differential Revision: https://reviews.llvm.org/D97409
2021-02-25 03:42:30 +08:00
; CHECK: @__dfsan_shadow_width_bits = weak_odr constant i32 [[#SBITS:]]
; CHECK: @__dfsan_shadow_width_bytes = weak_odr constant i32 [[#SBYTES:]]
[dfsan] Propagate origin tracking at store This is a part of https://reviews.llvm.org/D95835. Reviewed By: morehouse, gbalats Differential Revision: https://reviews.llvm.org/D97789
2021-03-03 02:59:07 +08:00
define i8 @load(i8* %p) {
[dfsan] Replace dfs$ prefix with .dfsan suffix The current naming scheme adds the `dfs$` prefix to all DFSan-instrumented functions. This breaks mangling and prevents stack trace printers and other tools from automatically demangling function names. This new naming scheme is mangling-compatible, with the `.dfsan` suffix being a vendor-specific suffix: https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-structure With this fix, demangling utils would work out-of-the-box. Reviewed By: stephan.yichao.zhao Differential Revision: https://reviews.llvm.org/D104494
2021-06-18 05:55:05 +08:00
; CHECK-LABEL: define i8 @load.dfsan
[DFSan] Change shadow and origin memory layouts to match MSan. Previously on x86_64: +--------------------+ 0x800000000000 (top of memory) | application memory | +--------------------+ 0x700000008000 (kAppAddr) | | | unused | | | +--------------------+ 0x300000000000 (kUnusedAddr) | origin | +--------------------+ 0x200000008000 (kOriginAddr) | unused | +--------------------+ 0x200000000000 | shadow memory | +--------------------+ 0x100000008000 (kShadowAddr) | unused | +--------------------+ 0x000000010000 | reserved by kernel | +--------------------+ 0x000000000000 MEM_TO_SHADOW(mem) = mem & ~0x600000000000 SHADOW_TO_ORIGIN(shadow) = kOriginAddr - kShadowAddr + shadow Now for x86_64: +--------------------+ 0x800000000000 (top of memory) | application 3 | +--------------------+ 0x700000000000 | invalid | +--------------------+ 0x610000000000 | origin 1 | +--------------------+ 0x600000000000 | application 2 | +--------------------+ 0x510000000000 | shadow 1 | +--------------------+ 0x500000000000 | invalid | +--------------------+ 0x400000000000 | origin 3 | +--------------------+ 0x300000000000 | shadow 3 | +--------------------+ 0x200000000000 | origin 2 | +--------------------+ 0x110000000000 | invalid | +--------------------+ 0x100000000000 | shadow 2 | +--------------------+ 0x010000000000 | application 1 | +--------------------+ 0x000000000000 MEM_TO_SHADOW(mem) = mem ^ 0x500000000000 SHADOW_TO_ORIGIN(shadow) = shadow + 0x100000000000 Reviewed By: stephan.yichao.zhao, gbalats Differential Revision: https://reviews.llvm.org/D104896
2021-06-25 13:16:36 +08:00
; CHECK: xor i64 {{.*}}, [[SHADOW_XOR_MASK]]
[dfsan] Propagate origin tracking at store This is a part of https://reviews.llvm.org/D95835. Reviewed By: morehouse, gbalats Differential Revision: https://reviews.llvm.org/D97789
2021-03-03 02:59:07 +08:00
; CHECK: ret i8 %a
%a = load i8, i8* %p
ret i8 %a
}
define void @store(i8* %p) {
[dfsan] Replace dfs$ prefix with .dfsan suffix The current naming scheme adds the `dfs$` prefix to all DFSan-instrumented functions. This breaks mangling and prevents stack trace printers and other tools from automatically demangling function names. This new naming scheme is mangling-compatible, with the `.dfsan` suffix being a vendor-specific suffix: https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-structure With this fix, demangling utils would work out-of-the-box. Reviewed By: stephan.yichao.zhao Differential Revision: https://reviews.llvm.org/D104494
2021-06-18 05:55:05 +08:00
; CHECK-LABEL: define void @store.dfsan
[DFSan] Change shadow and origin memory layouts to match MSan. Previously on x86_64: +--------------------+ 0x800000000000 (top of memory) | application memory | +--------------------+ 0x700000008000 (kAppAddr) | | | unused | | | +--------------------+ 0x300000000000 (kUnusedAddr) | origin | +--------------------+ 0x200000008000 (kOriginAddr) | unused | +--------------------+ 0x200000000000 | shadow memory | +--------------------+ 0x100000008000 (kShadowAddr) | unused | +--------------------+ 0x000000010000 | reserved by kernel | +--------------------+ 0x000000000000 MEM_TO_SHADOW(mem) = mem & ~0x600000000000 SHADOW_TO_ORIGIN(shadow) = kOriginAddr - kShadowAddr + shadow Now for x86_64: +--------------------+ 0x800000000000 (top of memory) | application 3 | +--------------------+ 0x700000000000 | invalid | +--------------------+ 0x610000000000 | origin 1 | +--------------------+ 0x600000000000 | application 2 | +--------------------+ 0x510000000000 | shadow 1 | +--------------------+ 0x500000000000 | invalid | +--------------------+ 0x400000000000 | origin 3 | +--------------------+ 0x300000000000 | shadow 3 | +--------------------+ 0x200000000000 | origin 2 | +--------------------+ 0x110000000000 | invalid | +--------------------+ 0x100000000000 | shadow 2 | +--------------------+ 0x010000000000 | application 1 | +--------------------+ 0x000000000000 MEM_TO_SHADOW(mem) = mem ^ 0x500000000000 SHADOW_TO_ORIGIN(shadow) = shadow + 0x100000000000 Reviewed By: stephan.yichao.zhao, gbalats Differential Revision: https://reviews.llvm.org/D104896
2021-06-25 13:16:36 +08:00
; CHECK: xor i64 {{.*}}, [[SHADOW_XOR_MASK]]
[dfsan] Propagate origin tracking at store This is a part of https://reviews.llvm.org/D95835. Reviewed By: morehouse, gbalats Differential Revision: https://reviews.llvm.org/D97789
2021-03-03 02:59:07 +08:00
; CHECK: ret void
store i8 0, i8* %p
ret void
}
[dfsan] Record dfsan metadata in globals This will allow identifying exactly how many shadow bytes were used during compilation, for when fast8 mode is introduced. Also, it will provide a consistent matching point for instrumentation tests so that the exact llvm type used (i8 or i16) for the shadow can be replaced by a pattern substitution. This is handy for tests with multiple prefixes. Reviewed by: stephan.yichao.zhao, morehouse Differential Revision: https://reviews.llvm.org/D97409
2021-02-25 03:42:30 +08:00
; CHECK: declare void @__dfsan_load_callback(i[[#SBITS]], i8*)
; CHECK: declare void @__dfsan_store_callback(i[[#SBITS]], i8*)
; CHECK: declare void @__dfsan_mem_transfer_callback(i[[#SBITS]]*, i64)
; CHECK: declare void @__dfsan_cmp_callback(i[[#SBITS]])
[dfsan] Instrument origin variable and function definitions This is a part of https://reviews.llvm.org/D95835. Reviewed-by: morehouse, gbalats Differential Revision: https://reviews.llvm.org/D96977
2021-02-19 02:29:21 +08:00
; CHECK: ; Function Attrs: nounwind readonly
[dfsan] Add full fast8 support Complete support for fast8: - amend shadow size and mapping in runtime - remove fast16 mode and -dfsan-fast-16-labels flag - remove legacy mode and make fast8 mode the default - remove dfsan-fast-8-labels flag - remove functions in dfsan interface only applicable to legacy - remove legacy-related instrumentation code and tests - update documentation. Reviewed By: stephan.yichao.zhao, browneee Differential Revision: https://reviews.llvm.org/D103745
2021-06-05 06:34:02 +08:00
; CHECK-NEXT: declare zeroext i[[#SBITS]] @__dfsan_union_load(i[[#SBITS]]*, i64)
[dfsan] Instrument origin variable and function definitions This is a part of https://reviews.llvm.org/D95835. Reviewed-by: morehouse, gbalats Differential Revision: https://reviews.llvm.org/D96977
2021-02-19 02:29:21 +08:00
; CHECK: ; Function Attrs: nounwind readonly
[dfsan] Add full fast8 support Complete support for fast8: - amend shadow size and mapping in runtime - remove fast16 mode and -dfsan-fast-16-labels flag - remove legacy mode and make fast8 mode the default - remove dfsan-fast-8-labels flag - remove functions in dfsan interface only applicable to legacy - remove legacy-related instrumentation code and tests - update documentation. Reviewed By: stephan.yichao.zhao, browneee Differential Revision: https://reviews.llvm.org/D103745
2021-06-05 06:34:02 +08:00
; CHECK-NEXT: declare zeroext i64 @__dfsan_load_label_and_origin(i8*, i64)
[dfsan] Instrument origin variable and function definitions This is a part of https://reviews.llvm.org/D95835. Reviewed-by: morehouse, gbalats Differential Revision: https://reviews.llvm.org/D96977
2021-02-19 02:29:21 +08:00
; CHECK: declare void @__dfsan_unimplemented(i8*)
[dfsan] Record dfsan metadata in globals This will allow identifying exactly how many shadow bytes were used during compilation, for when fast8 mode is introduced. Also, it will provide a consistent matching point for instrumentation tests so that the exact llvm type used (i8 or i16) for the shadow can be replaced by a pattern substitution. This is handy for tests with multiple prefixes. Reviewed by: stephan.yichao.zhao, morehouse Differential Revision: https://reviews.llvm.org/D97409
2021-02-25 03:42:30 +08:00
; CHECK: declare void @__dfsan_set_label(i[[#SBITS]] zeroext, i32 zeroext, i8*, i64)
[dfsan] Instrument origin variable and function definitions This is a part of https://reviews.llvm.org/D95835. Reviewed-by: morehouse, gbalats Differential Revision: https://reviews.llvm.org/D96977
2021-02-19 02:29:21 +08:00
; CHECK: declare void @__dfsan_nonzero_label()
; CHECK: declare void @__dfsan_vararg_wrapper(i8*)
; CHECK: declare zeroext i32 @__dfsan_chain_origin(i32 zeroext)
[dfsan] Track origin at loads The first version of origin tracking tracks only memory stores. Although this is sufficient for understanding correct flows, it is hard to figure out where an undefined value is read from. To find reading undefined values, we still have to do a reverse binary search from the last store in the chain with printing and logging at possible code paths. This is quite inefficient. Tracking memory load instructions can help this case. The main issues of tracking loads are performance and code size overheads. With tracking only stores, the code size overhead is 38%, memory overhead is 1x, and cpu overhead is 3x. In practice #load is much larger than #store, so both code size and cpu overhead increases. The first blocker is code size overhead: link fails if we inline tracking loads. The workaround is using external function calls to propagate metadata. This is also the workaround ASan uses. The cpu overhead is ~10x. This is a trade off between debuggability and performance, and will be used only when debugging cases that tracking only stores is not enough. Reviewed By: gbalats Differential Revision: https://reviews.llvm.org/D100967
2021-04-21 12:54:29 +08:00
; CHECK: declare zeroext i32 @__dfsan_chain_origin_if_tainted(i[[#SBITS]] zeroext, i32 zeroext)
[dfsan] Instrument origin variable and function definitions This is a part of https://reviews.llvm.org/D95835. Reviewed-by: morehouse, gbalats Differential Revision: https://reviews.llvm.org/D96977
2021-02-19 02:29:21 +08:00
; CHECK: declare void @__dfsan_mem_origin_transfer(i8*, i8*, i64)
[dfsan] Record dfsan metadata in globals This will allow identifying exactly how many shadow bytes were used during compilation, for when fast8 mode is introduced. Also, it will provide a consistent matching point for instrumentation tests so that the exact llvm type used (i8 or i16) for the shadow can be replaced by a pattern substitution. This is handy for tests with multiple prefixes. Reviewed by: stephan.yichao.zhao, morehouse Differential Revision: https://reviews.llvm.org/D97409
2021-02-25 03:42:30 +08:00
; CHECK: declare void @__dfsan_maybe_store_origin(i[[#SBITS]] zeroext, i8*, i64, i32 zeroext)