The instruction is present in some library in the 24H2 update for
Windows 11:
==8508==interception_win: unhandled instruction at 0x7ff83e193a40: 44 0f
b6 1a 4c 8b d2 48
This could be generalized, but getting all the ModR/M byte combinations
right is tricky. Many other classes of instructions handled in this file
could use some generalization too.
MSVC can sometimes generate instructions in function prologues that asan
previously didn't know the size of. This teaches asan those sizes. This isn't
super useful for using ASAN with non-msvc compilers, but it does stand alone.
From https://reviews.llvm.org/D151008
Since we may copy code (see CopyInstructions) to the trampoline which
could reference data inside the original module, we really want the
trampoline to be within 2 GB of not just the original function, but
within anything that function may have rip-relative accesses to, i.e.
within 2 GB of that function's whole module.
This fixes interception failures like the following scenario:
1. Intercept `CreateProcess` in kernel32.dll, allocating a trampoline
region right after
2. Start intercepting `memcpy` in the main executable, which is loaded
at a lower address than kernel32.dll, but still within 2 GB of the
trampoline region so we keep using it.
3. Try to copy instructions from `memcpy` to the trampoline. Turns out
one instruction references data that is more than 2GB away from the
trampoline, so it can't be relocated.
4. The process exits due to a CHECK failure
(Full story at https://crbug.com/341936875#comment45 and following.)
This works for MinGW, but the MSVC linker apparently doens't pull in
those symbols. Reverting for now since I won't be able to reproduce it today.
https://lab.llvm.org/buildbot/#/builders/107/builds/2337
This reverts commit 9df92cbd1addb03c7169f05cf3b628f88c610224.
This makes it so we'll be able to decode the instructions used in the
weak function stubs from
https://github.com/llvm/llvm-project/pull/81677. This code doesn't
technically require those changes.
Co-authored-by: Amy Wishnousky <amyw@microsoft.com>
It turns out this works _mostly_ fine, even when mixing debug versions
of asan with programs built with the release runtime. Using /MT (or
/MTd) with a dynamically linked asan has never really worked that well,
and I am planning on opening a PR that will completely remove the
static-asan configuration for windows and make programs linked with the
static CRT/runtime work with the DLL version of asan. This is better
than the current situation because the static linked version of asan
doesn't work well on windows if there are multiple DLLs in the process
using it.
The check for building asan with only /MD or /MT has been removed. It
was in AsanDoesNotSupportStaticLinkage, but was checking for debug CRTs,
not static linkage. The kind of static linkage this function is supposed
to check for (on linux for example) doesn't really exist on windows.
Note: There is one outstanding issue with this approach, if you mix a
/MDd DLLs and /MD dlls in the same process then the "real" function
called by asan interceptors will be the same for calls from both
contexts, potentially screwing up things like errno. This only happens
if you mix /MD and /MDd in the same process, because otherwise asan
won't find functions from both runtimes to intercept. We are working on
a fix for this, and it mainly hits with the CRT functions exported from
both ucrtbase and ntdll.
This change is being upstreamed from Microsoft's fork.
1. Differentiate SANITIZER_WINDOWS64 for x64 and arm64
2. turn off interception tests that expect x86 assembly
---------
Co-authored-by: Farzon Lotfi <farzon@farzon.com>
This instruction is present in memcpy in the latest vcruntime
This PR has been opened for @AndrewDeanMS (a teammate inside Microsoft)
who made the PR to our internal branch.
Co-authored-by: Andrew Dean <Andrew.Dean@microsoft.com>
The old code incorrectly checked what relative offsets were allowed.
The correct check is that the offset from the target to the instruction
pointer should be within $[-2^{31}, 2^{31})$; however, the check that
was originally written was that the offset was within $[0, 2^{31})$.
Negative offsets are certainly allowable (as long as they fit in 32
bits), and this change fixes that.
Updates GetInstructionSize to account for arm64 instruction sizes.
ARM64 instruction are always 4 bytes long but GetInstructionSize in
interception_win.cpp assumes x86_64 which has mixed sizes.
Fix is for: https://github.com/llvm/llvm-project/issues/64319
Before the changeclang_rt.asan_dynamic-aarch64.dll would crash at:
OverrideFunction -> OverrideFunctionWithHotPatch -> GetInstructionSize:825
After the change:
dllthunkintercept -> dllthunkgetrealaddressordie -> InternalGetProcAddress
This adds wcs[n]cat, wcs[n]cmp, wcs[n]cpy, and wcschr functions to the
interception code on Windows; wcs[n]cat was already intercepted, but only on
POSIX.
Differential Revision: https://reviews.llvm.org/D157038
Add a callback from interception to allow asan on Windows to produce
better error messages. If an unrecoverable error occured when
intercepting functions, print a message before terminating.
Additionally, when encountering unknown instructions, a more helpful
message containing the address and the bytes of the unknown instruction
is now printed to help identify the issue and make it easier to propose
a fix.
Depends on D149549
Differential Revision: https://reviews.llvm.org/D149002
Do not treat unknown instructions as a fatal error. In most cases,
failure to intercept a function is reported by the caller, though
requires setting verbosity to 1 or higher to be visible.
Better error message reporting for asan will be added in a separate
patch.
Differential Revision: https://reviews.llvm.org/D149549
The i686-w64-windows-gnu target does not use SEH (which MSVC uses),
but DWARF-2 exception handling or possibly sjlj depending on the
toolchain build options. On this target we have to actually intercept
functions in libc++ and libunwind which handles throwing exceptions.
This fixes the `TestCases/intercept-rethrow-exception.cpp` test.
The x86_64-w64-windows-gnu target already works because it uses SEH
which is handled by intercepting RaiseException, so this change does not
affect x86_64.
Depends on https://reviews.llvm.org/D148990
Differential Revision: https://reviews.llvm.org/D148991
These assembly patterns are needed to intercept some libc++ and
libunwind functions built by Clang for i686-w64-windows-gnu target.
Differential Revision: https://reviews.llvm.org/D148990
This is a follow up to [Sanitizers][Darwin] Rename Apple macro SANITIZER_MAC -> SANITIZER_APPLE (D125816)
Performed a global search/replace as in title against LLVM sources
Differential Revision: https://reviews.llvm.org/D126263
To intercept the functions in Win11's ntdll.dll, we need to use the trampoline
technique because there are bytes other than 0x90 or 0xcc in the gaps between
exported functions. This patch adds more patterns that appear in ntdll's
functions.
Bug: https://bugs.llvm.org/show_bug.cgi?id=51721
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D109941
See https://reviews.llvm.org/D58620 for discussion, and for the commands
I ran. In addition I also ran
for f in $(svn diff | diffstat | grep .cc | cut -f 2 -d ' '); do rg $f . ; done
and manually updated references to renamed files found by that.
llvm-svn: 367456
