From: Segher Boessenkool <segher@kernel.crashing.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: 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
Date: Mon, 28 Mar 2022 09:22:20 -0500 [thread overview]
Message-ID: <20220328142220.GI614@gate.crashing.org> (raw)
In-Reply-To: <YkGFdtn0yDIPqXRl@FVFF77S0Q05N>
Hi!
On Mon, Mar 28, 2022 at 10:52:54AM +0100, Mark Rutland wrote:
> On Fri, Mar 25, 2022 at 10:12:38AM -0500, Segher Boessenkool wrote:
> > The compiler isn't assuming anything about asan. The compiler generates
> > its code without any consideration of what asan will or will not do.
> > The burden of making things work is on asan.
>
> 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?
The attribute is about how the *current* function is instrumented, not
about anything called by this function. This is clearly documented:
'no_sanitize_address'
'no_address_safety_analysis'
The 'no_sanitize_address' attribute on functions is used to inform
the compiler that it should not instrument memory accesses in the
function when compiling with the '-fsanitize=address' option. The
'no_address_safety_analysis' is a deprecated alias of the
'no_sanitize_address' attribute, new code should use
'no_sanitize_address'.
> > The compiler should not do anything differently here if it uses asan.
> > The address sanitizer and the memcpy function implementation perhaps
> > have to cooperate somehow, or asan needs more smarts. This needs to
> > happen no matter what, to support other things calling memcpy, say,
> > assembler code.
>
> I appreciate where you're coming from here, but I think you're approaching the
> problem sideways.
I am stating facts, I am not trying to solve your problem there. It
seemed to me (and still does) that you didn't grasp all facts here.
> We need to define *what the semantics are* so that we can actually solve the
> problem, e.g. is a memcpy implementation expected to be instrumented or not?
That is up to the memcpy implementation itself, of course.
> > GCC *requires* memcpy to be the standard memcpy always (i.e. to have the
> > standard-specified semantics). This means that it will have the same
> > semantics as __builtin_memcpy always, and either or not be a call to an
> > external function. It can also create calls to it out of thin air.
>
> I understand all of that.
And still you want us to do something that is impossible under those
existing constraints :-(
If you want the external memcpy called by modules A, B, C to not be
instrumented, you have to link A, B, and C against an uninstrumented
memcpy. This is something the kernel will have to do, the compiler has
no say in how the kernel is linked together.
Segher
next prev parent reply other threads:[~2022-03-28 14:27 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-24 11:19 clang memcpy calls Borislav Petkov
2022-03-24 15:29 ` Mark Rutland
2022-03-24 18:43 ` Nick Desaulniers
2022-03-24 22:54 ` David Laight
2022-03-25 12:15 ` Mark Rutland
2022-03-25 14:13 ` Peter Zijlstra
2022-03-25 15:12 ` Segher Boessenkool
2022-03-28 9:52 ` Mark Rutland
2022-03-28 10:20 ` Jakub Jelinek
2022-03-28 11:54 ` Peter Zijlstra
2022-03-28 12:55 ` Mark Rutland
2022-03-28 13:12 ` Jakub Jelinek
2022-03-28 13:44 ` Mark Rutland
2022-03-30 14:45 ` Marco Elver
2022-03-28 14:22 ` Segher Boessenkool [this message]
2022-03-28 14:58 ` Mark Rutland
2022-03-28 15:59 ` Segher Boessenkool
2022-03-28 16:16 ` Peter Zijlstra
2022-03-28 16:58 ` Segher Boessenkool
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220328142220.GI614@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=bp@alien8.de \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-toolchains@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=peterz@infradead.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).