Re: [PATCH 0/5] aarch64 BTI stub fixes

[Fangrui Song <i@maskray.me>]

On Thu, Nov 9, 2023 at 6:58 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>
> The 11/07/2023 13:08, Szabolcs Nagy wrote:
> > The 11/07/2023 11:38, Nick Clifton wrote:
> > > FYI - I did find one regression in the linker testsuite with the patch applied:
> > >
> > >   FAIL: Check linker stubs with indirect calls handle BTI (exe).
> > >
> > > However there are mitigating circumstances:
> > >
> > >   * The failure was for an unusual toolchain configuration:
> > >
> > >       --target=aarch64_be-linux-gnu_ilp32
> > >
> > >   * The three other tests in this part of the testsuite also fail, both
> > >     with and without your patch applied:
> > >
> > >       FAIL: Check linker stubs with indirect calls handle BTI (shared lib).
> > >       FAIL: Check linker stubs with indirect calls handle BTI (exe).
> > >       FAIL: Check linker stubs with indirect calls handle BTI when target has BTI.
> > >
> > >    Note: there appear to be *two* tests called "check linker stubs with indirect calls handle BTI (exe)."
> > >
> > > I leave it up to you to decide if it is worth fixing these tests.
> >
> > thanks for looking at this.
> > i will have to check what's going on.
>
> i will change the name of the new test to be unique.
>
> cleaning up ilp32 test issues will be a fair bit of work.
>
> i can commit a followup patch to force the tests i added to use
> lp64 abi, like we do on other tests, but this is not ideal.
>
> > > PS.  My gut feeling at the moment is that we do not need a 2.41.1 release
> > > for this patch, since AArch64 systems with BTI enabled are not yet the norm,
> > > and those that do exist are being used to test for problems like this rather
> > > than general use.  Since your patch will be in the 2.42 release, due January
> > > next year, I think that that will be a reasonable timescale for getting the
> > > fix out there.  Do you agree ?
> >
> > makes sense,
> > unless it affects hardened kernel builds.
> > i will have to check if that's an issue.
>
> in practice i think the kernel should be fine.
> (it's hard to say conclusively)
>
> but i plan to backport the patches even if we don't arrange
> a new release.

% grep '\.zero' ld/testsuite/ld-aarch64/bti-far*
ld/testsuite/ld-aarch64/bti-far-3a.s:.zero      0x07000000
ld/testsuite/ld-aarch64/bti-far-3b.s:.zero      0x01000000
ld/testsuite/ld-aarch64/bti-far-3b.s:.zero      0x07000000
ld/testsuite/ld-aarch64/bti-far-3c.s:.zero      0x01000000
% size ld/tmpdir/bti-far-*
   text    data     bss     dec     hex filename
117440552             0       0 117440552       7000028 ld/tmpdir/bti-far-3a.o
134217768             0       0 134217768       8000028 ld/tmpdir/bti-far-3b.o
16777260              0       0 16777260        100002c ld/tmpdir/bti-far-3c.o
    132       0       0     132      84 ld/tmpdir/bti-far-opt.o


`.zero      0x07000000` is 112MiB.  Perhaps use output section
addresses (e.g. [1]) to make the files smaller?

[1]: https://github.com/llvm/llvm-project/blob/de176d8c5496d6cf20e82aface98e102c593dbe2/lld/test/ELF/aarch64-thunk-pi.s#L112