Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 28 Mar 2022 12:20:39 +0200
From:   Jakub Jelinek <jakub@redhat.com>
To:     Mark Rutland <mark.rutland@arm.com>
Cc:     Segher Boessenkool <segher@kernel.crashing.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Nick Desaulniers <ndesaulniers@google.com>,
        Borislav Petkov <bp@alien8.de>,
        Nathan Chancellor <nathan@kernel.org>, x86-ml <x86@kernel.org>,
        lkml <linux-kernel@vger.kernel.org>, llvm@lists.linux.dev,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        linux-toolchains@vger.kernel.org
Subject: Re: clang memcpy calls
Message-ID: <YkGL929QoFiTfMK7@tucnak>
Reply-To: Jakub Jelinek <jakub@redhat.com>
References: <YjxTt3pFIcV3lt8I@zn.tnic>
 <CAKwvOdkw0Bbm+=ZyViXQhBE1L6uSbvkstHJuHpQ21tzJRftgAw@mail.gmail.com>
 <Yj2yYFloadFobRPx@lakrids>
 <Yj3OEI+WHV/A5uf8@hirez.programming.kicks-ass.net>
 <20220325151238.GB614@gate.crashing.org>
 <YkGFdtn0yDIPqXRl@FVFF77S0Q05N>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YkGFdtn0yDIPqXRl@FVFF77S0Q05N>
Precedence: bulk

On Mon, Mar 28, 2022 at 10:52:54AM +0100, Mark Rutland wrote:
> I think we're talking past each other here, so let me be more precise. :)
> 
> The key thing is that when the user passes `-fsantize=address`, instrumentation
> is added by (a part of) the compiler. That instrumentation is added under some
> assumptions as to how the compiler as a whole will behave.
> 
> With that in mind, the question is how is __attribute__((no_sanitize_address))
> intended to work when considering all the usual expectations around how the
> compiler can play with memcpy and similar?

no_sanitize_address or lack thereof is whether the current function
shouldn't be or should be ASan instrumented, not on whether other functions
it calls are instrumented or not.  memcpy/memmove/memset are just a tiny bit
special case because the compiler can add them on their own even if they
aren't present in the source (there are a few others the compiler can
pattern match too) and various builtins can be on the other side expanded
inline instead of called, so one then gets the sanitization status of the
function in which it is used rather than whether the out of line
implementation of the function is sanitized.

If coexistence of instrumented and non-instrumented memcpy etc. was the goal
(it clearly wasn't), then the sanitizer libraries wouldn't be overriding
memcpy calls, but instead the compiler would redirect calls to memcpy in
instrumented functions to say __asan_memcpy which then would be
instrumented.

> Given the standard doesn't say *anything* about instrumentation, what does GCC
> *require* instrumentation-wise of the memcpy implementation? What happens *in
> practice* today?
> 
> For example, is the userspace implementation of memcpy() instrumented for
> AddressSanitizer, or not?

It is, for all functions, whether compiled with -fsanitize=address or not,
if user app is linked with -fsanitize=address, libasan is linked in and
overrides the libc memcpy with its instrumented version.

Note that the default shadow memory value is 0 which means accessible,
so even when memcpy is instrumented, when called from non-instrumented code
often it will not do anything beyond normal behavior, as non-instrumented
functions don't poison the paddings in between variable (there even doesn't
have to be any) etc.  But e.g. malloc/operator new etc. is also overridden,
so buffer overflows/underflows on memory allocated that way from
uninstrumented code using memcpy etc. will be diagnosed.

	Jakub