[llvm-dev] Memory sanitizer porting

[Evgenii Stepanov via llvm-dev]

Hi,

1. This patch adds an internal (-mllvm) option, which is basically
meant for debugging. If your custom platform has a target triple, you
could submit changes to llvm, clang and compiler-rt to specify any
platform-specific offsets and other details.
2. Blacklist is meant to disable checking for bugs in certain
functions, not to remove all instrumentation. With ASan, these are the
same. With MSan, it places instrumentation in a "safe" mode where, for
example, a function that reads from A and stores to B will (1) not
check A and (2) make B fully initialized even if data being stored
comes from an uninitialized location.

Building MSan runtime library with MSan is not going to work, blacklist or not.

3. No, not really. If you manage to allocate shadow and origin, which
must be the same size as the application-accessible region each, and
define a mapping function between them, it should be possible to make
MSan work.

On Thu, Feb 22, 2018 at 6:38 AM, vit9696 via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Hello,
>
> I am currently porting memory sanitizer to a custom platform, and discovered
> some strange things in the existing implementation.
>
> 1. clang/llvm currently hardcode the list of supported platforms and
> disallow the use of a standalone msan implementation.
> I suppose the solution here is to submit a patch similar to
> https://reviews.llvm.org/D18865, which will provide the necessary arguments
> to configure the layout.
> I have it ready here. Will this approach be fine for the llvm dev team, and
> may I post it for the review then?
>
> 2. There exists a concept of -fsanitize-blacklist argument, which is
> supposed to exclude source locations from being instrumented by the
> sanitizers.
> Normally this works without issues, but I discovered that you cannot compile
> compiler-rt msan implementation with -fsanitize=memory even if the whole
> location is blacklisted (that much I can confirm from the invocations of
> CodeGenModule::isInSanitizerBlacklist function).
> What happens is that for some reason memory sanitizer:
> — still tries to partially instrument the blacklisted code;
> — does not check whether its global memory storage variables are already
> defined.
> The second issue, present in MemorySanitizer::initializeCallbacks, adds a
> second copy of storage global variables when compiling msan.cc (e.g.
> __emutls_v.__msan_retval_tls.63, __emutls_v.__msan_param_tls.65), and this
> results in an undefined reference during the linkage.
>
> Here the question is what was initially intended to be done. I know that
> compiling blacklisted asan runtime code with -fsanitize=address is just
> fine, and this is what Apple actually does in XNU KASAN implementation.
> I kind of expected it to be the right way to do for msan as well, is this
> just a bug? If it is not, should I compile msan runtime without
> -fsanitize=memory in this case, and in fact asan runtime too?
>
> 3. Other than that, I see that memory sanitizer is currently implemented
> only for 64-bit platforms. While I am aware of the issues behind requiring a
> lot of memory to use msan, are there any other issues for not supporting
> 32-bit?
>
> Best regards,
> Vit
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>