[libcxx-commits] [PATCH] D132090: [1a/3][ASan][compiler-rt] API for double ended containers

[Tacet via Phabricator via libcxx-commits]

AdvenamTacet created this revision.
Herald added subscribers: Enna1, dberris.
Herald added a project: All.
AdvenamTacet requested review of this revision.
Herald added projects: Sanitizers, libc++.
Herald added subscribers: libcxx-commits, Sanitizers.
Herald added a reviewer: libc++.

This commit is a part of patches extending AddressSanitizer
C++ container overflow detection capabilities by adding annotations,
similar to those existing in std::vector, to std::string and
std::deque collections. These changes allow ASan to detect cases
when the instrumented program accesses memory which is internally
allocated by the collection but is still not in-use
(accesses before or after the stored elements for std::deque,
or between the size and capacity bounds for std::string).

Trail of Bits developed this as part of a research project where
we tried to find bugs using the oss-fuzz
(using llvm-14 with our modifications) harnesses.
Now, we want to upstream the llvm-15 port of this work.

This commit adds new compiler-rt ASan sanitization API functions:
__sanitizer_annotate_de_contiguous_container_front and
__sanitizer_annotate_de_contiguous_container_back, necessary to
sanitize/annotate double ended contiguous containers.
Note that those functions annotate a single contiguous memory buffer
(so e.g. the std::deque's internal chunk). Such containers have
the beginning of allocated memory block,
beginning of the container the in-use data,
end of the container's in-use data and
end of the allocated memory block.

Regarding the sanitization, there is a small caveat.
Since we do not modify the ASan's shadow memory encoding values,
the capability of sanitizing/annotating a prefix of
the internal contiguous memory buffer is limited --
up to SHADOW_GRANULARITY-1 bytes may not be poisoned before
the container's in-use data.
This can cause false negatives (situations when ASan will not detect
memory corruption in those areas).

SHADOW_GRANULARITY is usually 8 – that value describes how
many bytes has a block described by a single value in the
AddressSanitizer's shadow memory and is set during llvm/clang
compilation.

On the other hand, API function interfaces are designed to work even
if this caveat would not exist. Therefore implementations using those
functions will poison every byte correctly, if only ASan
(and compiler-rt) is extended to support it. In other words, if ASan
was modified to support annotating/poisoning of objects lying on
addresses unaligned to SHADOW_GRANULARITY (so e.g. prefixes of
those blocks), which would require changing its shadow memory encoding,
this would not require any changes in the libcxx std::string/deque code
which is added in further commits of this patch series.

Structure of our patches:
[1a/3][ASan][compiler-rt] API for double ended containers
[1b/3][ASan][compiler-rt] API for annotating objects memory
[2a/3][ASan][libcxx] std::deque annotations
[2b/3][ASan][libcxx] std::basic_string annotations
[3/3][ASan] integration test for std::deque and std::basic_string annotations

1a -> 2a -

  \
   --> 3
  /

1b -> 2b -

If you have any questions, please email:

- advenam.tacet at trailofbits.com
- disconnect3d at trailofbits.com


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D132090

Files:
  compiler-rt/include/sanitizer/common_interface_defs.h
  compiler-rt/lib/asan/asan_errors.cpp
  compiler-rt/lib/asan/asan_errors.h
  compiler-rt/lib/asan/asan_poisoning.cpp
  compiler-rt/lib/asan/asan_report.cpp
  compiler-rt/lib/asan/asan_report.h
  compiler-rt/lib/sanitizer_common/sanitizer_common_interface.inc
  compiler-rt/lib/sanitizer_common/sanitizer_interface_internal.h
  libcxx/include/__config

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D132090.453493.patch
Type: text/x-patch
Size: 24602 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/libcxx-commits/attachments/20220818/dd1e2eda/attachment-0001.bin>