[hwasan] Add __hwasan_add_frame_record to the hwasan interface

Hwasan includes instructions in the prologue that mix the PC and SP and store
it into the stack ring buffer stored at __hwasan_tls. Thi

[hwasan] Add __hwasan_add_frame_record to the hwasan interface

Hwasan includes instructions in the prologue that mix the PC and SP and store
it into the stack ring buffer stored at __hwasan_tls. This is a thread_local
global exposed from the hwasan runtime. However, if TLS-mechanisms or the
hwasan runtime haven't been setup yet, it will be invalid to access __hwasan_tls.
This is the case for Fuchsia where we instrument libc, so some functions that
are instrumented but can run before hwasan initialization will incorrectly
access this global. Additionally, libc cannot have any TLS variables, so we
cannot weakly define __hwasan_tls until the runtime is loaded.

A way we can work around this is by moving the instructions into a hwasan
function that does the store into the ring buffer and creating a weak definition
of that function locally in libc. This way __hwasan_tls will not actually be
referenced. This is not our long-term solution, but this will allow us to roll
out hwasan in the meantime.

This patch includes:

- A new llvm flag for choosing to emit a libcall rather than instructions in the
prologue (off by default)
- The libcall for storing into the ringbuffer (__hwasan_add_frame_record)

Differential Revision: https://reviews.llvm.org/D128387

show more ...

Revert "[hwasan] Add __hwasan_record_frame_record to the hwasan interface"

This reverts commit 4956620387ee45a48a394853a47ddd65195c4cc6.

This broke a sanitizer builder: https://lab.llvm.org/buildbo

Revert "[hwasan] Add __hwasan_record_frame_record to the hwasan interface"

This reverts commit 4956620387ee45a48a394853a47ddd65195c4cc6.

This broke a sanitizer builder: https://lab.llvm.org/buildbot/#/builders/77/builds/19597

show more ...

[hwasan] Add __hwasan_record_frame_record to the hwasan interface

Hwasan includes instructions in the prologue that mix the PC and SP and store
it into the stack ring buffer stored at __hwasan_tls.

[hwasan] Add __hwasan_record_frame_record to the hwasan interface

Hwasan includes instructions in the prologue that mix the PC and SP and store
it into the stack ring buffer stored at __hwasan_tls. This is a thread_local
global exposed from the hwasan runtime. However, if TLS-mechanisms or the
hwasan runtime haven't been setup yet, it will be invalid to access __hwasan_tls.
This is the case for Fuchsia where we instrument libc, so some functions that
are instrumented but can run before hwasan initialization will incorrectly
access this global. Additionally, libc cannot have any TLS variables, so we
cannot weakly define __hwasan_tls until the runtime is loaded.

A way we can work around this is by moving the instructions into a hwasan
function that does the store into the ring buffer and creating a weak definition
of that function locally in libc. This way __hwasan_tls will not actually be
referenced. This is not our long-term solution, but this will allow us to roll
out hwasan in the meantime.

This patch includes:

- A new llvm flag for choosing to emit a libcall rather than instructions in the
prologue (off by default)
- The libcall for storing into the ringbuffer (__hwasan_record_frame_record)

Differential Revision: https://reviews.llvm.org/D128387

show more ...

[hwasan] Refactor frame record info into function

This way it can be reused easily in D128387.

Note this changes the IR slightly. Before The steps for calculating and storing the frame record info

[hwasan] Refactor frame record info into function

This way it can be reused easily in D128387.

Note this changes the IR slightly. Before The steps for calculating and storing the frame record info were:

1. getPC
2. getSP
3. inttoptr
4. or SP, PC
5. store

Now the steps are:

1. getPC
2. getSP
3. or SP, PC
4. inttoptr
5. store

Differential Revision: https://reviews.llvm.org/D129315

show more ...

[NFC][HWASan] Refactor hwasan pass

This moves some code for getting PC and SP into their own functions. Since SP
is also retrieved in the prologue and getting the stack tag, we can cache the
SP if w

[NFC][HWASan] Refactor hwasan pass

This moves some code for getting PC and SP into their own functions. Since SP
is also retrieved in the prologue and getting the stack tag, we can cache the
SP if we get it once in the prologue. This caching will really only be relevant
in D128387 where StackBaseTag may not be set in the prologue if __hwasan_tls
is not used.

Differential Revision: https://reviews.llvm.org/D128551

show more ...

[HWASan] Use new IR attribute for communicating unsanitized globals.

Globals that shouldn't be sanitized are currently communicated to HWASan
through the use of the llvm.asan.globals IR metadata. No

[HWASan] Use new IR attribute for communicating unsanitized globals.

Globals that shouldn't be sanitized are currently communicated to HWASan
through the use of the llvm.asan.globals IR metadata. Now that we have
an on-GV attribute, use it.

Reviewed By: pcc

Differential Revision: https://reviews.llvm.org/D127543

show more ...

[MTE] [HWASan] Use LoopInfo for reachability queries.

The reachability queries default to "reachable" after exploring too many
basic blocks. LoopInfo helps it skip over the whole loop.

Reviewed By:

[MTE] [HWASan] Use LoopInfo for reachability queries.

The reachability queries default to "reachable" after exploring too many
basic blocks. LoopInfo helps it skip over the whole loop.

Reviewed By: eugenis

Differential Revision: https://reviews.llvm.org/D127917

show more ...

[NFC] [HWASan] Remove indirection for getting analyses.

This was necessary for code reuse between the old and new passmanager.
With the old pass-manager gone, this is no longer necessary.

Reviewed

[NFC] [HWASan] Remove indirection for getting analyses.

This was necessary for code reuse between the old and new passmanager.
With the old pass-manager gone, this is no longer necessary.

Reviewed By: eugenis, myhsu

Differential Revision: https://reviews.llvm.org/D127913

show more ...

Remove unneeded cl::ZeroOrMore for cl::opt/cl::list options

Remove unneeded cl::ZeroOrMore for cl::opt options

Similar to 557efc9a8b68628c2c944678c6471dac30ed9e8e.
This commit handles options where cl::ZeroOrMore is more than one line below
cl::opt.

[llvm] Remove unneeded cl::ZeroOrMore for cl::opt options. NFC

Some cl::ZeroOrMore were added to avoid the `may only occur zero or one times!`
error. More were added due to cargo cult. Since the err

[llvm] Remove unneeded cl::ZeroOrMore for cl::opt options. NFC

Some cl::ZeroOrMore were added to avoid the `may only occur zero or one times!`
error. More were added due to cargo cult. Since the error has been removed,
cl::ZeroOrMore is unneeded.

Also remove cl::init(false) while touching the lines.

show more ...

Add !nosanitize to FixedMetadataKinds

This patch adds !nosanitize metadata to FixedMetadataKinds.def, !nosanitize indicates that LLVM should not insert any sanitizer instrumentation.

Reviewed By: v

Add !nosanitize to FixedMetadataKinds

This patch adds !nosanitize metadata to FixedMetadataKinds.def, !nosanitize indicates that LLVM should not insert any sanitizer instrumentation.

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D126294

show more ...

[iwyu] Handle regressions in libLLVM header include

Running iwyu-diff on LLVM codebase since fa5a4e1b95c8f37796 detected a few
regressions, fixing them.

Differential Revision: https://reviews.llvm.

[iwyu] Handle regressions in libLLVM header include

Running iwyu-diff on LLVM codebase since fa5a4e1b95c8f37796 detected a few
regressions, fixing them.

Differential Revision: https://reviews.llvm.org/D124847

show more ...

[LegacyPM] Remove HWAsanSanitizerLegacyPass

Using the legacy PM for the optimization pipeline was deprecated in 13.0.0.
Following recent changes to remove non-core features of the legacy
PM/optimiza

[LegacyPM] Remove HWAsanSanitizerLegacyPass

Using the legacy PM for the optimization pipeline was deprecated in 13.0.0.
Following recent changes to remove non-core features of the legacy
PM/optimization pipeline, remove AddressSanitizerLegacyPass...

...,
ModuleAddressSanitizerLegacyPass, and ASanGlobalsMetadataWrapperPass.

MemorySanitizerLegacyPass was removed in D123894.
AddressSanitizerLegacyPass was removed in D124216.

Reviewed By: #sanitizers, vitalybuka

Differential Revision: https://reviews.llvm.org/D124337

show more ...

[AddressSanitizer] Allow prefixing memintrinsic calls in kernel mode

Allow receiving memcpy/memset/memmove instrumentation by using __asan or
__hwasan prefixed versions for AddressSanitizer and HWAd

[AddressSanitizer] Allow prefixing memintrinsic calls in kernel mode

Allow receiving memcpy/memset/memmove instrumentation by using __asan or
__hwasan prefixed versions for AddressSanitizer and HWAddressSanitizer
respectively when compiling in kernel mode, by passing params
-asan-kernel-mem-intrinsic-prefix or -hwasan-kernel-mem-intrinsic-prefix.

By default the kernel-specialized versions of both passes drop the
prefixes for calls generated by memintrinsics. This assumes that all
locations that can lower the intrinsics to libcalls can safely be
instrumented. This unfortunately is not the case when implicit calls to
memintrinsics are inserted by the compiler in no_sanitize functions [1].

To solve the issue, normal memcpy/memset/memmove need to be
uninstrumented, and instrumented code should instead use the prefixed
versions. This also aligns with ASan behaviour in user space.

[1] https://lore.kernel.org/lkml/Yj2yYFloadFobRPx@lakrids/

Reviewed By: glider

Differential Revision: https://reviews.llvm.org/D122724

show more ...

[HWASan] do not replace lifetime intrinsics with tagged address.

Quote from the LLVM Language Reference
If ptr is a stack-allocated object and it points to the first byte of the
object, the obje

[HWASan] do not replace lifetime intrinsics with tagged address.

Quote from the LLVM Language Reference
If ptr is a stack-allocated object and it points to the first byte of the
object, the object is initially marked as dead. ptr is conservatively
considered as a non-stack-allocated object if the stack coloring algorithm
that is used in the optimization pipeline cannot conclude that ptr is a
stack-allocated object.

By replacing the alloca pointer with the tagged address before this change,
we confused the stack coloring algorithm.

Reviewed By: eugenis

Differential Revision: https://reviews.llvm.org/D121835

show more ...

Revert "[HWASan] do not replace lifetime intrinsics with tagged address."

Failed on buildbot:

/home/buildbot/buildbot-root/llvm-clang-x86_64-sie-ubuntu-fast/build/bin/llc: error: : error: unable to

Revert "[HWASan] do not replace lifetime intrinsics with tagged address."

Failed on buildbot:

/home/buildbot/buildbot-root/llvm-clang-x86_64-sie-ubuntu-fast/build/bin/llc: error: : error: unable to get target for 'aarch64-unknown-linux-android29', see --version and --triple.
FileCheck error: '<stdin>' is empty.
FileCheck command line: /home/buildbot/buildbot-root/llvm-clang-x86_64-sie-ubuntu-fast/build/bin/FileCheck /home/buildbot/buildbot-root/llvm-project/llvm/test/Instrumentation/HWAddressSanitizer/stack-coloring.ll --check-prefix=COLOR

This reverts commit 208b923e74feeb986fe5114ca39a74b1d2032ed7.

show more ...

[HWASan] do not replace lifetime intrinsics with tagged address.

Quote from the LLVM Language Reference
If ptr is a stack-allocated object and it points to the first byte of the
object, the obje

[HWASan] do not replace lifetime intrinsics with tagged address.

Quote from the LLVM Language Reference
If ptr is a stack-allocated object and it points to the first byte of the
object, the object is initially marked as dead. ptr is conservatively
considered as a non-stack-allocated object if the stack coloring algorithm
that is used in the optimization pipeline cannot conclude that ptr is a
stack-allocated object.

By replacing the alloca pointer with the tagged address before this change,
we confused the stack coloring algorithm.

Reviewed By: eugenis

Differential Revision: https://reviews.llvm.org/D121835

show more ...

Cleanup includes: DebugInfo & CodeGen

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D121332

[NFC] [HWASan] document why we tag Size but untag AlignedSize.

[NFC] [MTE] [HWASan] fixed orphaned comments.

[NFC] [MTE] [HWASan] simply code.

[HWASAN] erase lifetime intrinsics if tag is outside.

Reviewed By: eugenis

Differential Revision: https://reviews.llvm.org/D120437

[NFC] [MTE] [HWASan] Remove unnecessary member of AllocaInfo

Reviewed By: eugenis

Differential Revision: https://reviews.llvm.org/D119981

[HWASan] remove replacement of DbgVariableIntrinsics.

This code was dead because we AI->replaceUsesWithIf above. I verified
this doesn't actually get run by applying
https://gist.github.com/fmayer/a

[HWASan] remove replacement of DbgVariableIntrinsics.

This code was dead because we AI->replaceUsesWithIf above. I verified
this doesn't actually get run by applying
https://gist.github.com/fmayer/aea7cbb4700cfe2c9d932591ae1073c3 to the
Android toolchain and building AOSP, without any crash.

Reviewed By: eugenis

Differential Revision: https://reviews.llvm.org/D119802

show more ...