Current interception code does not cover all of the required registers
on Windows for a specific flavor of MOV, so this patch adds cases to
identify the following 5-byte instructions on 64-bit Windows:
mov QWORD PTR [rsp + XX], rdx <- second integer argument
mov QWORD PTR [rsp + XX], r9 <- third integer argument
mov QWORD PTR [rsp + XX], r8 <- fourth integer argument
The instruction for MOV [...] RCX is already covered in the previous
version.
Patch by Matthew McGovern!
Reviewers: rnk
Differential Revision: https://reviews.llvm.org/D57339
llvm-svn: 353483
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
Same idea as r310419: The 8 byte nop is a suffix of the 9 byte nop, and we need at most 6 bytes.
Differential Revision: https://reviews.llvm.org/D51788
llvm-svn: 342649
In Windows version 1803, the first instruction of ntdll!strchr is:
8a01 mov al,byte ptr [rcx]
This is the only needed change for this version as far as I can tell.
Differential Revision: https://reviews.llvm.org/D46458
llvm-svn: 332095
Summary:
Unlike the rest of the sanitizer code, lib/interception uses native macros like __linux__
to check for specific targets instead of the common ones like SANITIZER_LINUX.
When working on the Solaris port of the sanitizers, the current style was found to not
only be inconsistent, but clumsy to use because the canonical way to check for Solaris
is to check for __sun__ && __svr4__ which is a mouthful.
Therefore, this patch switches to use SANITIZER_* macros instead.
Tested on x86_64-pc-linux-gnu.
Reviewers: kcc, vitalybuka
Reviewed By: vitalybuka
Subscribers: #sanitizers, srhines, krytarowski, llvm-commits, fedor.sergeev
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D39798
llvm-svn: 319906
The 9 byte nop is a suffix of the 10 byte nop, and we need at most 6
bytes.
ntdll's version of strcpy is written in assembly and is very clever.
strcat tail calls strcpy but with a slightly different arrangement of
argument registers at an alternate entry point. It looks like this:
ntdll!strcpy:
00007ffd`64e8a7a0 4c8bd9 mov r11,rcx
ntdll!__entry_from_strcat_in_strcpy:
00007ffd`64e8a7a3 482bca sub rcx,rdx
00007ffd`64e8a7a6 f6c207 test dl,7
If we overwrite more than two bytes in our interceptor, that label will
no longer be a valid instruction boundary.
By recognizing the 9 byte nop, we use the two byte backwards branch to
start our trampoline, avoiding this issue.
Fixes https://github.com/google/sanitizers/issues/829
Patch by David Major
llvm-svn: 310419
The first instruction of the new ucrtbase!strnlen implementation loads a
global, presumably to dispatch between SSE and non-SSE optimized strnlen
implementations.
Fixes PR32895 and probably
https://github.com/google/sanitizers/issues/818
llvm-svn: 305581
This fix a bug, when calling InternalGetProcAddress() for an executable that
doesn't export any symbol. So the table is empty.
If we don't check for this condition, the program fails with Error 0xc0000142.
Also, I add a regression test for Windows.
Differential Revision: https://reviews.llvm.org/D28502
llvm-svn: 293521
This fix a bug, when calling InternalGetProcAddress() for an executable that
doesn't export any symbol. So the table is empty.
If we don't check for this condition, the program fails with Error 0xc0000142.
Also, I add a regression test for Windows.
Differential Revision: https://reviews.llvm.org/D28502
llvm-svn: 292747
Summary:
In a 32-bit address space, PC-relative jump targets are wrapped, so a
direct branch at 0x90000001 can reach address 0x10000000 with a
displacement of 0x7FFFFFFFF. This can happen in applications, such as
Chrome, that are linked with /LARGEADDRESSAWARE.
Reviewers: etienneb
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D26650
llvm-svn: 286997
Summary:
The check-asan-dynamic tests were broken on win10 because the interception
library was not able to hook on some functions.
credits: thanks sebastian marchand to help debugging this on win10.
Reviewers: rnk
Subscribers: chrisha, llvm-commits, dberris
Differential Revision: https://reviews.llvm.org/D25120
llvm-svn: 282904
Summary:
The MSVC compiler is generating multiple instance of the exception handler
when compiling on win64 with /MD.
see: https://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx
Two tests were failing when running:
```
ninja check-asan-dynamic.
```
The tests were failing because only the first occurence of the function was patched.
The function `__C_specific_handler` is defined in `ntdll` and `vcruntime140`.
After this patch, there is still two remaining tests failing.
```
********************
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
Testing Time: 87.81s
********************
Failing Tests (2):
AddressSanitizer-x86_64-windows-dynamic :: TestCases/Windows/dll_intercept_memchr.cc
AddressSanitizer-x86_64-windows-dynamic :: TestCases/Windows/dll_intercept_memcpy_indirect.cc
Expected Passes : 342
Passes With Retry : 2
Expected Failures : 16
Unsupported Tests : 152
Unexpected Failures: 2
```
Reviewers: rnk, vitalybuka
Subscribers: vitalybuka, llvm-commits, chrisha, dberris
Differential Revision: https://reviews.llvm.org/D24983
llvm-svn: 282614
Summary:
These instructions where not supported on my win7 computer.
They were happening on strstr when building chrome unittests with asan.
Reviewers: rnk
Subscribers: llvm-commits, chrisha
Differential Revision: https://reviews.llvm.org/D23081
llvm-svn: 277519
Summary:
On my install of Windows 10, RaiseException is a tail call to
kernelbase!RaiseException. Obviously, we fail to intercept that.
Instead, try hooking at the ntdll!RtlRaiseException layer. It is
unlikely that this layer will contain control flow.
Intercepting at this level requires adding a decoding for
'LEA ESP, [ESP + 0xXXXXXXXX]', which is a really obscure way to write
'SUB ESP, 0xXXXXXXXX' that avoids clobbering EFLAGS.
Reviewers: etienneb
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D23046
llvm-svn: 277518
Summary:
On windows, an export can be redirected to an other DLL.
This patch is adding the required support to the internal
GetProcAddress implementation.
This case was encountered by instrumenting chromium (win 64-bits)
using this GN configuration:
```
is_component_build = true
is_debug = false
enable_nacl = false
is_clang = true
is_asan = true
clang_base_path = "d:\src\llvm\ninja64"
clang_use_chrome_plugins = false
clang_version = "4.0.0"
```
The operating system is win7 (x64).
Visual Studio: 2015 Professional
Reviewers: rnk
Subscribers: llvm-commits, chrisha
Differential Revision: https://reviews.llvm.org/D22880
llvm-svn: 277294
Summary:
Some instructions can only be copied if the relative offset is adjusted.
This patch adds support for two common instruction.
It's quite common to have a indirect load in the prologue
(loading the security cookie).
Reviewers: rnk
Subscribers: llvm-commits, wang0109, chrisha
Differential Revision: https://reviews.llvm.org/D22647
llvm-svn: 276336
Summary:
Indirect load are relative offset from RIP.
The current trampoline implementation is incorrectly
copying these instructions which make some unittests
crashing.
This patch is not fixing the unittests but it's fixing
the crashes. The functions are no longer hooked.
Patches will come soon to fix these unittests.
Reviewers: rnk
Subscribers: llvm-commits, wang0109, chrisha
Differential Revision: https://reviews.llvm.org/D22410
llvm-svn: 275892
Summary:
The trampoline allocation limits the memory scanning to 1 gig.
There is an unittest that is allocating a large object which make
it impossible to the trampoline allocator to find a free spot.
see shadow_mapping_failures:
```
char bigchunk[1 << 30];
```
This patch is not fixing the unittest but it's fixing it's infinite
loop behavior.
Reviewers: rnk
Subscribers: llvm-commits, wang0109, chrisha
Differential Revision: https://reviews.llvm.org/D22471
llvm-svn: 275887
Summary:
Indirect load are relative offset from RIP.
The current trampoline implementation is incorrectly
copying these instructions which make some unittests
crashing.
This patch is not fixing the unittests but it's fixing
the crashes. The functions are no longer hooked.
Patches will come soon to fix these unittests.
Reviewers: rnk
Subscribers: llvm-commits, wang0109, chrisha
Differential Revision: https://reviews.llvm.org/D22410
llvm-svn: 275584
c:\lipo\work\asan\b_llvm>c:\lipo\work\asan\b_llvm\projects\compiler-rt\test\asan\X86_64WindowsConfig\TestCases\Output\null_deref.cc.tmp
=================================================================
==5488==ERROR: AddressSanitizer: access-violation on unknown address 0x000000000028 (pc 0x7ff701f91067 bp 0x000c8cf8fbf0 sp 0x000c8cf8fbb0 T0)
==5488==The signal is caused by a READ memory access.
==5488==Hint: address points to the zero page.
#0 0x7ff701f91066 in NullDeref(int *) C:\lipo\work\asan\llvm\projects\compiler-rt\test\asan\TestCases\null_deref.cc:15:10
#1 0x8a0388830a67 (<unknown module>)
The reason was symbols was not initilized. In fact, it was first inited
with a call to stack.Print(), which calls
WinSymbolizerTool::SymbolizePC, then InitializeDbgHelpIfNeeded().
Since the StackWalk was performed before the stack.Print(), stack frames
where not gathered correctly.
There should be a better place to initialize symbols. For now, this
patch makes the test happy.
Patch by Wei Wang
Differential Revision: https://reviews.llvm.org/D22410
llvm-svn: 275580
Summary:
These patterns are encounter when using instrumented DLL.
Without this patch, asan lit test are crashing when trying to hook
on RaiseException function.
Reviewers: rnk
Subscribers: llvm-commits, wang0109, chrisha
Differential Revision: https://reviews.llvm.org/D22340
llvm-svn: 275489
mov edi,edi is _not_ NOP in 64-bit, use 66,90h instead.
This bug was causing interception unittest to crash on
Windows64 (windows 8 and windows 10).
Credits to etienneb for finding the root cause.
Patch by: Wei Wang
Differential Revision: http://reviews.llvm.org/D22274
llvm-svn: 275207
Summary:
Many CRT (64-bits) functions contains a "hint-nop". The current padding
detection is not able to recognize the 10-bytes padding and the HotPatch
hooking technique cannot be used.
Other patterns may be discover and may be added later.
Reviewers: rnk
Subscribers: llvm-commits, wang0109, chrisha
Differential Revision: http://reviews.llvm.org/D22258
llvm-svn: 275180
Summary:
This is a cleanup and refactoring of the interception code on windows
Enhancement:
* Adding the support for 64-bits code
* Adding several hooking technique:
* Detour
* JumpRedirect
* HotPatch
* Trampoline
* Adding a trampoline memory pool (64-bits) and release the allocated memory in unittests
Cleanup:
* Adding unittests for 64-bits hooking techniques
* Enhancing the RoundUpInstruction by sharing common decoder
Reviewers: rnk
Subscribers: llvm-commits, wang0109, chrisha
Differential Revision: http://reviews.llvm.org/D22111
llvm-svn: 275123
Summary:
This patch is adding more unittests for testing the interception
of 32-bits code.
Reviewers: rnk
Subscribers: llvm-commits, wang0109, chrisha
Differential Revision: http://reviews.llvm.org/D22077
llvm-svn: 274775
Some known issues are:
When "head" include instructions that involve branching, the "cut and paste" approach may break down in a way that function interception still work but calling back the original function does not work.
The jmp [rip -8] saves some bytes in the "head" but finding the safe zone of 0xCC is not implemented yet. So it may stomp on preceding codes.
The shadow offset is not working yet on Win64. More complexity maybe involved since there are some differences regarding virtual address space between Window 8 and Windows 8.1/10.
Patch by: Wang Wei
Differential Revision: http://reviews.llvm.org/D20884
llvm-svn: 271915
It's fixing compilation errors. The runtime is not yet working.
Missing features:
OverrideFunction for x64
an equiv function for inline asm (atomic_compare_exchange_strong)
shadow memory offset needs to be adjusted
RoundUpToInstrBoundary for x64
They will be implemented by subsequent patches.
Patch by Wei Wang.
Differential revision: http://reviews.llvm.org/D20455
llvm-svn: 271049
ucrtbase.dll appears to be built with some kind of cross-module
inlining, because there are calls to imported Heap* routines sprinkled
throughout the code. This inlining defeats our attempts to hotpatch
malloc, _malloc_base, and related functions. Failing to intercept an
allocation or deallocation results in a crash when the program attempts
to deallocate or reallocate memory with the wrong allocator.
This change patches the IAT of ucrtbase.dll to replace the addresses of
the imported Heap* functions with implementations provided by ASan. We
don't globally intercept the win32 Heap* functions because they are
typically used by system DLLs that run before ASan initializes.
Eventually, we may want to intercept them, but for now I think this is
the minimal change that will keep ASan stable.
Reviewers: samsonov
Differential Revision: http://reviews.llvm.org/D18413
llvm-svn: 264327
Some unit tests were failing because we didn't intercept strdup. It
turns out it works just fine on 2013 and 2015 with a small patch to the
interception logic.
llvm-svn: 264013
In VS 2015, the memset fill parameter is zero extended from one byte
instead of being copied wholesale.
The issue reproduces with existing tests if you use VS2015.
llvm-svn: 263966
Define WIN32_LEAN_AND_MEAN before including Windows.h. This is already being
done in some places. This does it more broadly. This permits building ASAN on
Linux for Winndows, as well as reduces the amount of included declarations.
llvm-svn: 251649
ASan uses GetProcAddress to get the address of malloc so it can patch
it. Newer versions of Windows make GetProcAddress initialize the DLL
before returning a function pointer into it. That's perfectly
reasonable, but ASan needs to finish patching malloc before CRT
initialization. So now we roll our own GetProcAddress.
Fixes PR24237
Based on a patch by David Major
Originally written by David Major as part of:
https://hg.mozilla.org/mozilla-central/file/tip/toolkit/xre/WindowsCrtPatch.h
llvm-svn: 245377
Summary: This finishes support for ASAN on MSVC2012.
Test Plan: |ninja check-asan| passes locally with this on MSVC2012.
Reviewers: timurrrr
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5494
llvm-svn: 218465
Reid Kleckner