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;
MIME-Version: 1.0
References: <Y1LBGZPMfCZ8A1bl@FVFF77S0Q05N> <CABCJKuf=OB_3ZR_rwaG3H5kHKmTTDk+sihjJXYmyWgZjUX2yTQ@mail.gmail.com>
In-Reply-To: <CABCJKuf=OB_3ZR_rwaG3H5kHKmTTDk+sihjJXYmyWgZjUX2yTQ@mail.gmail.com>
From:   Fangrui Song <maskray@google.com>
Date:   Fri, 21 Oct 2022 21:14:41 -0700
Message-ID: <CAFP8O3JuC9HL1-G23vGJO=jjN7Tsgz7c8TB1_F6UQ-MqCyGNLQ@mail.gmail.com>
Subject: Re: kCFI && patchable-function-entry=M,N
To:     Sami Tolvanen <samitolvanen@google.com>
Cc:     Mark Rutland <mark.rutland@arm.com>, llvm@lists.linux.dev,
        linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        Joao Moreira <joao@overdrivepizza.com>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        Kees Cook <keescook@chromium.org>,
        Nathan Chancellor <nathan@kernel.org>,
        Nick Desaulniers <ndesaulniers@google.com>,
        Peter Zijlstra <peterz@infradead.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, Oct 21, 2022 at 10:39 AM Sami Tolvanen <samitolvanen@google.com> wr=
ote:
>
> On Fri, Oct 21, 2022 at 8:56 AM Mark Rutland <mark.rutland@arm.com> wrote=
:
> >
> > Hi,
> >
> > For arm64, I'd like to use -fatchable-function-entry=3DM,N (where N > 0=
), for our
> > ftrace implementation, which instruments *some* but not all functions.
> > Unfortuntately, this doesn't play nicely with -fsanitize=3Dkcfi, as ins=
trumented
> > and non-instrumented functions don't agree on where the type hash shoul=
d live
> > relative to the function entry point, making them incompatible with one=
 another.
>
> Yes, the current implementation assumes that if prefix nops are used,
> all functions have the same number of them.
>
> > Is there any mechanism today that we could use to solve this, or could =
we
> > extend clang to have some options to control this behaviour?
>
> I don't think there's a mechanism to work around the issue right now,
> but we could just change where the hash is emitted on arm64.
>
> > It would also be helpful to have a symbol before both the hash and pre-=
function
> > NOPs so that we can filter those out of probes patching (I see that x86=
 does
> > this with the __cfi_function symbol).
>
> Adding a symbol before the hash isn't a problem, but if we move the
> hash and want the symbol to be placed before the prefix nops as well,
> we might need a flag to control this. Fangrui, what do you think?
>
> Sami

Since the kcfi code expects the hash to appear in a specific location
so that an instrumented indirect jump can reliably obtain the hash.
For a translation unit `-fpatchable-function-entry=3DN,M` may be
specified or not, and we want both to work. Therefore, I agree that a
consistent hash location will help. This argument favors placing M
nops before the hash. The downside is a restriction on how the M nops
can be used. Previously if M>0, the runtime code needs to check
whether a BTI exists to locate the N-M after-function-entry NOPs. If
the hash appears after the M nops, the runtime code needs to
additionally knows whether the hash exists. My question is how to
reliably detect this.

If there is motivation using M>0, I'd like to know the concrete code
sequence for `-fpatchable-function-entry=3DN,M` and how the runtime code
detects the NOPs with optional hash and optional BTI.


--=20
=E5=AE=8B=E6=96=B9=E7=9D=BF