On Sun Dec 22 16:16:59 2024 +0000, Jinoh Kang wrote:
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!)
I think the easiest way to achieve this is to check if the current bitness is 64bit (also makes `__APPLE__` check unnecessary)
```suggestion:-2+1 /* only handle faults in 64bit code */ if (CS_sig(sigcontext) != cs64_sel) return FALSE; ```