http://bugs.winehq.org/show_bug.cgi?id=58420
Bug ID: 58420 Summary: Wine crashes when running msys2 iff CPU's PKU/PKRU feature is enabled Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: pipcet@protonmail.com Distribution: ---
This is a heads-up about a bug in cygwin/msys2 which may be misreported as a wine bug.
The Cygwin code assumes CPUID leaf 0x0d to indicate in EBX a 64-byte-aligned value. That may or may not be true on current Windows systems, but on current Linux systems running Wine, with recent CPUs, a CPU feature called "PKU" or "PKRU" (memory protection keys for userspace), enabled by default, indicates an additional 8-byte XSAVE area.
This makes the Cygwin code attempt to xsave to a non-64-byte aligned area, which causes a segfault and abnormal program termination.
While this is clearly a bug, it's a bug that apparently cannot be triggered by current Windows systems. This means Wine fails to be bug-for-bug compatible in this case. I don't think there's an easy way around that: we'd have to trap XGETBV and CPUID instructions to pretend that a feature that is enabled by Linux actually isn't available.
It would have been nice if the Linux kernel had provided a way to disable the pku feature on a per-process basis, but AFAICT, it didn't. The nopku kernel command line argument makes things work, but requires a reboot and disables the very useful PKU feature for the entire system.
So I don't think there's a good workaround here, but maybe we should suggest to the Linux kernel people to allow per-process activation of any future XCR0 features?
http://bugs.winehq.org/show_bug.cgi?id=58420
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source
http://bugs.winehq.org/show_bug.cgi?id=58420
Bernhard Übelacker bernhardu@mailbox.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu@mailbox.org
--- Comment #1 from Bernhard Übelacker bernhardu@mailbox.org --- Thank you very much for the detailed information.
Just putting a link to your cygwin upstream mailing list discussion: https://cygwin.com/pipermail/cygwin/2025-June/258368.html
http://bugs.winehq.org/show_bug.cgi?id=58420
--- Comment #2 from pipcet@protonmail.com --- For what it's worth, I feel quite strongly that Linux should allow "hiding" XCR0 features on a per-process basis. That would allow Wine to work around this bug on the Linux/Wine side of things, and run unfixed Cygwin software on new CPUs without a reboot (and a reduced feature set in the rebooted system).
I suggested that, and the suggestion was rejected.
This means that Wine will now move further away from bug-for-bug compatibility with Windows whenever a new CPU feature is introduced (Linux would enable it for everyone, and even if there is an option to disable it, that would necessarily require a reboot of the Linux system).
I may be overestimating how important such compatibility is to the Wine developers, but if I'm not, our best remaining option would be to make Wine use virtualization instead of hoping to be able to run a Windows program as a Linux process directly; that wouldn't make Wine an emulator, it would merely mean that we trap certain instructions to hide CPU features which Windows doesn't enable or which work differently on Linux and Windows.
http://bugs.winehq.org/show_bug.cgi?id=58420
--- Comment #3 from Bernhard Übelacker bernhardu@mailbox.org --- If I understand this right this issue makes wine getting an exception in a xsave instruction? There might be a chance to workaround by adding something to the function emulate_instruction for this case?