* [Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls
[not found] <bug-106671-4@http.gcc.gnu.org/bugzilla/>
@ 2023-03-23 13:06 ` nsz at gcc dot gnu.org
2023-03-23 13:47 ` broonie at kernel dot org
` (10 subsequent siblings)
11 siblings, 0 replies; 12+ messages in thread
From: nsz at gcc dot gnu.org @ 2023-03-23 13:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
nsz at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nsz at gcc dot gnu.org
Status|NEW |WAITING
--- Comment #7 from nsz at gcc dot gnu.org ---
fixed in bfd ld 2.41 see
https://sourceware.org/bugzilla/show_bug.cgi?id=30076
we can also fix gcc to work with older ld (emit bti c in local functions), but
i don't plan to do that unless there is a reason to do so. (it increases the
emitted bti c considerably in some workloads, e.g. linux kernel, while the
linker fix is less intrusive in the common case with small binaries and no
weird section hacks).
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls
[not found] <bug-106671-4@http.gcc.gnu.org/bugzilla/>
2023-03-23 13:06 ` [Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls nsz at gcc dot gnu.org
@ 2023-03-23 13:47 ` broonie at kernel dot org
2023-08-02 16:03 ` fxue at os dot amperecomputing.com
` (9 subsequent siblings)
11 siblings, 0 replies; 12+ messages in thread
From: broonie at kernel dot org @ 2023-03-23 13:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
--- Comment #8 from Mark Brown <broonie at kernel dot org> ---
Note that the issue was found in the Linux kernel - we were expecting to see
the BTI Cs there, it's certainly a lot simpler to work with.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls
[not found] <bug-106671-4@http.gcc.gnu.org/bugzilla/>
2023-03-23 13:06 ` [Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls nsz at gcc dot gnu.org
2023-03-23 13:47 ` broonie at kernel dot org
@ 2023-08-02 16:03 ` fxue at os dot amperecomputing.com
2023-08-11 9:28 ` wilco at gcc dot gnu.org
` (8 subsequent siblings)
11 siblings, 0 replies; 12+ messages in thread
From: fxue at os dot amperecomputing.com @ 2023-08-02 16:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
Feng Xue <fxue at os dot amperecomputing.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fxue at os dot amperecomputing.com
--- Comment #9 from Feng Xue <fxue at os dot amperecomputing.com> ---
On some occasions, we may not use the new ld, the kernel-building relies on its
own runtime linker which is used for kernel modules. So I created a patch
(https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626084.html), and this
provides user another option that could be done at the compiler side.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls
[not found] <bug-106671-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2023-08-02 16:03 ` fxue at os dot amperecomputing.com
@ 2023-08-11 9:28 ` wilco at gcc dot gnu.org
2023-08-14 20:25 ` jiangning.liu at amperecomputing dot com
` (7 subsequent siblings)
11 siblings, 0 replies; 12+ messages in thread
From: wilco at gcc dot gnu.org @ 2023-08-11 9:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
Wilco <wilco at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |wilco at gcc dot gnu.org
--- Comment #10 from Wilco <wilco at gcc dot gnu.org> ---
(In reply to Feng Xue from comment #9)
> On some occasions, we may not use the new ld, the kernel-building relies on
> its own runtime linker which is used for kernel modules. So I created a
> patch (https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626084.html),
> and this provides user another option that could be done at the compiler
> side.
Reducing BTI is important for security. With LTO a binary should only have BTI
on functions that are indirectly called. So I don't like the idea of adding
more BTI with a new option - it means we will need a linker optimization to
remove those redundant BTIs (eg. by changing them into NOPs).
Note that branch offsets up to 256MB don't need special veneer handling: one
should place a direct branch about halfway to the destination.
Does Linux do any weird hacks in -fpatchable-function-entry that makes it hard
to use BTI?
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls
[not found] <bug-106671-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2023-08-11 9:28 ` wilco at gcc dot gnu.org
@ 2023-08-14 20:25 ` jiangning.liu at amperecomputing dot com
2023-08-15 10:11 ` nsz at gcc dot gnu.org
` (6 subsequent siblings)
11 siblings, 0 replies; 12+ messages in thread
From: jiangning.liu at amperecomputing dot com @ 2023-08-14 20:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
--- Comment #11 from Jiangning Liu <jiangning.liu at amperecomputing dot com> ---
Hi Wilco,
> "it means we will need a linker optimization to remove those redundant BTIs (eg. by changing them into NOPs)"
It will be only for performance optimization, right? If we don't care about
performance, the linker doesn't need to optimize it to be NOP, right? It could
still be useful if we only do this operation for a specific module.
Thanks,
-Jiangning
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls
[not found] <bug-106671-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2023-08-14 20:25 ` jiangning.liu at amperecomputing dot com
@ 2023-08-15 10:11 ` nsz at gcc dot gnu.org
2023-08-15 19:26 ` broonie at kernel dot org
` (5 subsequent siblings)
11 siblings, 0 replies; 12+ messages in thread
From: nsz at gcc dot gnu.org @ 2023-08-15 10:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
--- Comment #12 from nsz at gcc dot gnu.org ---
(In reply to Jiangning Liu from comment #11)
> Hi Wilco,
>
> > "it means we will need a linker optimization to remove those redundant BTIs (eg. by changing them into NOPs)"
>
> It will be only for performance optimization, right? If we don't care about
> performance, the linker doesn't need to optimize it to be NOP, right? It
> could still be useful if we only do this operation for a specific module.
no, this is a security feature, we want as few BTI c in an executable
segment as possible.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls
[not found] <bug-106671-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2023-08-15 10:11 ` nsz at gcc dot gnu.org
@ 2023-08-15 19:26 ` broonie at kernel dot org
2023-08-21 9:53 ` rearnsha at gcc dot gnu.org
` (4 subsequent siblings)
11 siblings, 0 replies; 12+ messages in thread
From: broonie at kernel dot org @ 2023-08-15 19:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
--- Comment #13 from Mark Brown <broonie at kernel dot org> ---
The kernel hasn't got any problem with BTI as far as I am aware - when built
with clang we run the kernel with BTI enabled since clang does just insert a
BTI C at the start of every function, and GCC works fine so long as we don't
get any out of range jumps being generated. The issue is that we don't have
anything to insert veneers in the case where section placement puts static
functions into a distant enough part of memory to need an indirect jump but GCC
has decided to omit the landing pad.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls
[not found] <bug-106671-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2023-08-15 19:26 ` broonie at kernel dot org
@ 2023-08-21 9:53 ` rearnsha at gcc dot gnu.org
2023-08-21 14:15 ` broonie at kernel dot org
` (3 subsequent siblings)
11 siblings, 0 replies; 12+ messages in thread
From: rearnsha at gcc dot gnu.org @ 2023-08-21 9:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
--- Comment #14 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
(In reply to Mark Brown from comment #13)
> The kernel hasn't got any problem with BTI as far as I am aware - when built
> with clang we run the kernel with BTI enabled since clang does just insert a
> BTI C at the start of every function, and GCC works fine so long as we don't
> get any out of range jumps being generated. The issue is that we don't have
> anything to insert veneers in the case where section placement puts static
> functions into a distant enough part of memory to need an indirect jump but
> GCC has decided to omit the landing pad.
The linker has to insert the veneers.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls
[not found] <bug-106671-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2023-08-21 9:53 ` rearnsha at gcc dot gnu.org
@ 2023-08-21 14:15 ` broonie at kernel dot org
2023-08-21 16:04 ` rearnsha at gcc dot gnu.org
` (2 subsequent siblings)
11 siblings, 0 replies; 12+ messages in thread
From: broonie at kernel dot org @ 2023-08-21 14:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
--- Comment #15 from Mark Brown <broonie at kernel dot org> ---
The kernel module loader simply does not insert veneers at present, and there
were some implementation concerns IIRC.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls
[not found] <bug-106671-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2023-08-21 14:15 ` broonie at kernel dot org
@ 2023-08-21 16:04 ` rearnsha at gcc dot gnu.org
2023-08-21 16:18 ` wilco at gcc dot gnu.org
2023-08-21 16:24 ` broonie at kernel dot org
11 siblings, 0 replies; 12+ messages in thread
From: rearnsha at gcc dot gnu.org @ 2023-08-21 16:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
--- Comment #16 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
(In reply to Mark Brown from comment #15)
> The kernel module loader simply does not insert veneers at present, and
> there were some implementation concerns IIRC.
That's not a good reason to weaken the security of the generated code.
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls
[not found] <bug-106671-4@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2023-08-21 16:04 ` rearnsha at gcc dot gnu.org
@ 2023-08-21 16:18 ` wilco at gcc dot gnu.org
2023-08-21 16:24 ` broonie at kernel dot org
11 siblings, 0 replies; 12+ messages in thread
From: wilco at gcc dot gnu.org @ 2023-08-21 16:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
--- Comment #17 from Wilco <wilco at gcc dot gnu.org> ---
(In reply to Mark Brown from comment #13)
> The kernel hasn't got any problem with BTI as far as I am aware - when built
> with clang we run the kernel with BTI enabled since clang does just insert a
> BTI C at the start of every function, and GCC works fine so long as we don't
> get any out of range jumps being generated. The issue is that we don't have
> anything to insert veneers in the case where section placement puts static
> functions into a distant enough part of memory to need an indirect jump but
> GCC has decided to omit the landing pad.
Is the kernel already larger than 128 MBytes .text? Or do people do weird stuff
with section placement that causes branches to be out of range?
^ permalink raw reply [flat|nested] 12+ messages in thread* [Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls
[not found] <bug-106671-4@http.gcc.gnu.org/bugzilla/>
` (10 preceding siblings ...)
2023-08-21 16:18 ` wilco at gcc dot gnu.org
@ 2023-08-21 16:24 ` broonie at kernel dot org
11 siblings, 0 replies; 12+ messages in thread
From: broonie at kernel dot org @ 2023-08-21 16:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
--- Comment #18 from Mark Brown <broonie at kernel dot org> ---
It's section placement stuff that's triggering this. You will also be able to
build a larger kernel if you try, though I'm not sure that's practical.
^ permalink raw reply [flat|nested] 12+ messages in thread