[PATCH v3 0/1] MR9671: include: Add bti jc for __ASM_DEFINE_FUNC on ARM64
Branch Target Identification (BTI) was introduced with ARMv8.5 and is enabled by newer distributions. It's a NOP for older hardware, so make our code compatible to it. See also: https://github.com/AndreRH/hangover/issues/192 Note: I wasn't able to test this on Hardware myself! -- v3: ntdll/unix: Add bti c for call dispatchers https://gitlab.winehq.org/wine/wine/-/merge_requests/9671
From: André Zwing <nerv(a)dawncrow.de> Branch Target Identification (BTI) was introduced with ARMv8.5 and is enabled by newer distributions. It's a NOP for older hardware, so make our code compatible to it. --- dlls/ntdll/unix/signal_arm64.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/dlls/ntdll/unix/signal_arm64.c b/dlls/ntdll/unix/signal_arm64.c index 2e7cce6e2e1..a08175d951d 100644 --- a/dlls/ntdll/unix/signal_arm64.c +++ b/dlls/ntdll/unix/signal_arm64.c @@ -1544,6 +1544,7 @@ __ASM_GLOBAL_FUNC( signal_start_thread, * __wine_syscall_dispatcher */ __ASM_GLOBAL_FUNC( __wine_syscall_dispatcher, + "hint 34\n\t" /* bti c */ "ldr x10, [x18, #0x378]\n\t" /* thread_data->syscall_frame */ "stp x18, x19, [x10, #0x90]\n\t" "stp x20, x21, [x10, #0xa0]\n\t" @@ -1709,6 +1710,7 @@ __ASM_GLOBAL_FUNC( __wine_syscall_dispatcher_return, * __wine_unix_call_dispatcher */ __ASM_GLOBAL_FUNC( __wine_unix_call_dispatcher, + "hint 34\n\t" /* bti c */ "ldr x10, [x18, #0x378]\n\t" /* thread_data->syscall_frame */ "stp x18, x19, [x10, #0x90]\n\t" "stp x20, x21, [x10, #0xa0]\n\t" -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/9671
which at this point probably means only syscall/unixcall dispatchers
Just pushed the minimal commit based on your assumptions. Do we have ARMv8.5 or ARMv9 test capabilities? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9671#note_125111
On Sun Dec 7 21:02:46 2025 +0000, André Zwing wrote:
which at this point probably means only syscall/unixcall dispatchers Just pushed the minimal commit based on your assumptions. Do we have ARMv8.5 or ARMv9 test capabilities? How does this work, to limit the need of BTI only to the unix side? Is there some control bit somewhere that limits the extent of the BTI checks that gets cleared/set when switching between the unix and win32 sides?
(The only parts of BTI I'm familiar with is in pure linux contexts, where BTI gets enabled for a process if the executable, and presumably all directly linked libraries, have the BTI enable flag set. And that flag gets set if all object files are built with that flag enabled, or if linking with `-Wl,-z,force-bti`. And is there a similar flag for PE executables that would allow the OS/wine to enable BTI for the win32 side as well?) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9671#note_125135
On Mon Dec 8 12:06:26 2025 +0000, Martin Storsjö wrote:
How does this work, to limit the need of BTI only to the unix side? Is there some control bit somewhere that limits the extent of the BTI checks that gets cleared/set when switching between the unix and win32 sides? (The only parts of BTI I'm familiar with is in pure linux contexts, where BTI gets enabled for a process if the executable, and presumably all directly linked libraries, have the BTI enable flag set. And that flag gets set if all object files are built with that flag enabled, or if linking with `-Wl,-z,force-bti`. And is there a similar flag for PE executables that would allow the OS/wine to enable BTI for the win32 side as well?) I don't have the hardware to test it, but my understanding is that this is done through the PROT_BTI flag, which is set on executable pages of libraries that support BTI.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/9671#note_125136
On Mon Dec 8 12:28:46 2025 +0000, Alexandre Julliard wrote:
I don't have the hardware to test it, but my understanding is that this is done through the PROT_BTI flag, which is set on executable pages of libraries that support BTI. Oh, I see. That sounds reasonable; so for everything on the unix side, it's handled by the regular system loader, and for the win32 side, Wine would be free to enable that flag for DLLs/EXEs that are built with the same feature, if there would be a similar flag for them.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/9671#note_125137
participants (3)
-
Alexandre Julliard (＠julliard) -
André Zwing
-
Martin Storsjö