[PATCH] cfi: rust: pass -Zpatchable-function-entry on all architectures

[Mark Rutland]

On Wed, Oct 09, 2024 at 10:15:35PM +0200, Alice Ryhl wrote:
> On Wed, Oct 9, 2024 at 7:43 PM Mark Rutland <mark.rutland at arm.com> wrote:
> >
> > Hi Alice,
> >
> > On Tue, Oct 08, 2024 at 05:37:16PM +0000, Alice Ryhl wrote:
> > > The KCFI sanitizer stores the CFI tag of a function just before its
> > > machine code. However, the patchable-function-entry flag can be used to
> > > introduce additional nop instructions before the machine code, taking up
> > > the space that normally holds the CFI tag.
> >
> > To clarify, when you say "before the machine code", do you mean when
> > NOPs are placed before the function entry point? e.g. if we compiled
> > with -fpatchable-function-entry=M,N where N > 0? I'll refer tho this as
> > "pre-function NOPs" below.
> >
> > There's an existing incompatibility between CFI and pre-function NOPs
> > for C code, because we override -fpatchable-function-entry on a
> > per-function basis (e.g. for noinstr and notrace), and we don't
> > currently have a mechanism to ensure the CFI tag is in the same place
> > regardless. This is why arm64 has CONFIG_DYNAMIC_FTRACE_WITH_CALL_OPS
> > depend on !CFI.
> >
> > For C code at least, just using regular -fpatchable-function-entry=M or
> > -fpatchable-function-entry=M,0 shouldn't change the location of the CFI
> > tag relative to the function entrypoint, and so should have no adverse
> > effect on CFI.
> >
> > Is Rust any different here?
> 
> Ah, no it shouldn't be. Sami can you confirm?
> 
> > > In this case, a backwards offset is applied to the CFI tag to move
> > > them out of the way of the nop instructions. To ensure that C and Rust
> > > agree on the offset used by CFI tags, pass the
> > > -Zpatchable-function-entry to rustc whenever it is passed to the C
> > > compiler.
> >
> > As above, I suspect this isn't necessary to make CFI work, for any case
> > that works with C today, due to -fpatchable-funtion-entry being
> > overridden on a per-function basis. Are you seeing a problem in
> > practice, or was this found by inspection?
> >
> > However IIUC this will allow rust to be traced via ftrace (assuming rust
> > records the instrumented locations as gcc and clang do); is that the
> > case? Assuming so, is there any ABI difference that might bite us? On
> > arm64 we require that anything marked instrumented with
> > patchable-function-entry strictly follows the AAPCS64 calling convention
> > and our ftrace trampolines save/restore the minimal set of necessary
> > registers, and I don't know how rust whether rust will behave the same
> > or e.g. use specialized calling conventions internally.
> 
> Well, I was told that it's a problem and was able to trigger a failure
> on x86. I didn't manage to trigger one on arm64, but I wasn't sure
> whether that was me doing something wrong, or whether the problem only
> exists on x86. We already have the flag on x86 for FINEIBT, 

I believe that hte problem only exists on x86, becaause they use 
patchable-function-entry for their FINEIBT patching (and use -mfentry
for ftrace), whereas everyone else uses patchable-function-entry for
ftrace.

> but I thought on the off chance that it's not a problem in practice on
> arm, it still doesn't hurt to add the flag.

It won't adversely affect CFI, but it will open up rust code for ftrace,
so I'm not sure that "it doesn't hurt".

AFAICT at the moment this isn't necessary for CFI, so can we drop this
patch for now?

If we want to pass these flags for !x86, the justification should be to
enable ftrace for rust code, and we should test that actually works
(e.g. by testing ftrace with rust code).

What happens on x86 for ftrace and rust?

> Regarding the AAPCS64 calling convention thing ... rustc uses the Rust
> calling convention for functions internally in Rust code and I don't
> know whether that changes anything relevant for what you mention.
> Matthew/Sami do you know?

>From their replies it sounds like that happens to be true in practice
today, but as above I think we should go test this actually works.

Mark.