[hwasan] Fix rare false negative (zero tag) in stack-uar.c (#69374)

stack-uar.c is flaky (1 in 256 executions) because the random tag
may be zero (https://github.com/llvm/llvm-project/issues/69221)

[hwasan] Fix rare false negative (zero tag) in stack-uar.c (#69374)

stack-uar.c is flaky (1 in 256 executions) because the random tag
may be zero (https://github.com/llvm/llvm-project/issues/69221).

This patch works around the issue in the same way as deep-recursion.c

(https://github.com/llvm/llvm-project/commit/aa4dfd3736dd1c2e0263eacd09bd613c5784ea73),
by falling back to a neighboring object, which must have a different
(non-zero) tag.

This patch also does a minor cleanup of the aforementioned
deep-recursion.c, for consistency with stack-uar.c.

Co-authored-by: Thurston Dang <thurston@google.com>

show more ...

[compiler-rt][HWASAN] Add missing include in deep-recursion.c test

[hwasan] Fix and re-enable deep-recursion.c (#69265)

deep-recursion.c was disabled

(https://github.com/llvm/llvm-project/commit/c007e0f66ee3f96467fd12f6200218fb4c38c2c9)
because the test may get

[hwasan] Fix and re-enable deep-recursion.c (#69265)

deep-recursion.c was disabled

(https://github.com/llvm/llvm-project/commit/c007e0f66ee3f96467fd12f6200218fb4c38c2c9)
because the test may get unlucky and end up with a zero-tagged variable,
leading to a false negative
(https://github.com/llvm/llvm-project/issues/69221).

This patch re-enables the test and adds a workaround: it checks
if the variable is zero-tagged, and if so, it will instead use the
neighboring variable, which must have a different (hence non-zero)
tag.

Fixing the stack allocation tagging is left as an exercise for the
reader. It is non-trivial because, even if the stackTagBase is
non-zero, tags for subsequent allocations in the stack frame may wrap
around to zero; working around this would require adding multiple
instructions to each alloca.

---------

Co-authored-by: Thurston Dang <thurston@google.com>

show more ...

[hwasan][test] Fix regex so deep-recursion.c is unsupported on aarch64 targets (#69254)

After 144c5b6d58803a2d4a0fe92a0fe331ff0347dc3b, we still see this test
running in CI for aarch64-linux target

[hwasan][test] Fix regex so deep-recursion.c is unsupported on aarch64 targets (#69254)

After 144c5b6d58803a2d4a0fe92a0fe331ff0347dc3b, we still see this test
running in CI for aarch64-linux targets. This appears to be related to
the triple being `aarch64-unknown-linux-gnu`, or similar.

The bot link below includes 144c5b6d58803a2d4a0fe92a0fe331ff0347dc3b,
and fails the deep-recursion.c test, which should have been disabled.
https://luci-milo.appspot.com/ui/p/fuchsia/builders/toolchain.ci/clang-linux-arm64/b8767065085790662609/overview

show more ...

[compiler-rt][hwasan] Disable deep-recursion.c test on AArch64 Linux

The test program occasionaly fails to detect the fault as it should.
See https://github.com/llvm/llvm-project/issues/69221.

Remove stable-runtime from many tests

They pass on x86_64 host, arm64 host, and Android.

Reviewed By: vitalybuka

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

[hwasan] Convert tests to check 'target=...'

Part of the project to eliminate special handling for triples in lit
expressions.

[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] Add basic stack tagging support for LAM.

Adds the basic instrumentation needed for stack tagging.

Currently does not support stack short granules or TLS stack histories,
since a different

[HWASan] Add basic stack tagging support for LAM.

Adds the basic instrumentation needed for stack tagging.

Currently does not support stack short granules or TLS stack histories,
since a different code path is followed for the callback instrumentation
we use.

We may simply wait to support these two features until we switch to
a custom calling convention.

Patch By: xiangzhangllvm, morehouse

Reviewed By: vitalybuka

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

show more ...

[HWASan] Disable stack, globals and force callbacks for x86_64.

Subsequent patches will implement page-aliasing mode for x86_64, which
will initially only work for the primary heap allocator. We fo

[HWASan] Disable stack, globals and force callbacks for x86_64.

Subsequent patches will implement page-aliasing mode for x86_64, which
will initially only work for the primary heap allocator. We force
callback instrumentation to simplify the initial aliasing
implementation.

Reviewed By: vitalybuka, eugenis

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

show more ...

Fix typo in test cases as well.

llvm-svn: 349255

[hwasan] Record and display stack history in stack-based reports.

Summary:
Display a list of recent stack frames (not a stack trace!) when
tag-mismatch is detected on a stack address.

The implement

[hwasan] Record and display stack history in stack-based reports.

Summary:
Display a list of recent stack frames (not a stack trace!) when
tag-mismatch is detected on a stack address.

The implementation uses alignment tricks to get both the address of
the history buffer, and the base address of the shadow with a single
8-byte load. See the comment in hwasan_thread_list.h for more
details.

Developed in collaboration with Kostya Serebryany.

Reviewers: kcc

Subscribers: srhines, kubamracek, mgorny, hiraditya, jfb, llvm-commits

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

llvm-svn: 342923

show more ...

[hwasan] Record and display stack history in stack-based reports.

Summary:
Display a list of recent stack frames (not a stack trace!) when
tag-mismatch is detected on a stack address.

The implement

[hwasan] Record and display stack history in stack-based reports.

Summary:
Display a list of recent stack frames (not a stack trace!) when
tag-mismatch is detected on a stack address.

The implementation uses alignment tricks to get both the address of
the history buffer, and the base address of the shadow with a single
8-byte load. See the comment in hwasan_thread_list.h for more
details.

Developed in collaboration with Kostya Serebryany.

Reviewers: kcc

Subscribers: srhines, kubamracek, mgorny, hiraditya, jfb, llvm-commits

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

llvm-svn: 342921

show more ...