Jinoh Kang (@iamahuman) commented about dlls/ntdll/unix/signal_x86_64.c:
+/***********************************************************************
check_invalid_gs
- Check for fault caused by invalid %gs value (some copy protection schemes mess with it).
- */
+static inline BOOL check_invalid_gs( ucontext_t *sigcontext, CONTEXT *context ) +{
- const BYTE *instr = (BYTE *)context->Rip;
- WORD system_gs = ds64_sel;
- ULONG_PTR cur_gs = 0;
- TEB *teb;
+#ifndef __APPLE__ /* FIXME: why does this break on macOS? */
- /* only handle faults in system libraries */
- if (virtual_is_valid_code_address( instr, 1 )) return FALSE;
First, thanks for taking care of preserving the system code check.
I'm afraid that this check may be too strict for WoW64; we need a bit more precision.
In pure 32bit (signal_i386.c), checking for system code (Unix side[^em]) was enough, because PE side[^em] didn't rely on the GS segment register at all.
In new-style WoW64, we have another layer that uses GS: the WoW64 itself. The new-style WoW64 code itself is 64-bit, so it needs GS. However, the WoW64 code is in the PE side[^em]. Therefore, `virtual_is_valid_code_address` would return TRUE, leading to early exit of this function (on both macOS and Linux).
| Region | Bitness | System code? | Uses GS? | Behavior of this PR (v3) | |---|---|---|---|---| | 64-bit Unix libraries | 64-bit | Yes (Unix) | Yes | Handled | | 32-bit PE (DLL/EXE) | 32-bit | No (PE) | No | Ignored | | WoW64 layer[^w] | 64-bit | **No (PE)** | **Yes** | **Ignored** |
As you can see in the last row, you need extra check for the WoW64 layer, even if `virtual_is_valid_code_address` returns TRUE. Otherwise, it leads to crash.
[^em]: See https://list.winehq.org/mailman3/hyperkitty/list/wine-devel@winehq.org/threa... and https://list.winehq.org/mailman3/hyperkitty/list/wine-devel@winehq.org/threa... for overview on the PE/Unix split architecture. [^w]: This includes wow64.dll, wow64cpu.dll, wow64win.dll, and even ntdll.dll (yes, every new-style WoW64 process haa both 32-bit and 64-bit versions of NTDLL!)