DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 55REgrpi1472861
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5CF1F3858408
Date: Fri, 27 Jun 2025 14:41:39 +0000
To: cygwin AT cygwin DOT com
Subject: XSAVE-related segfaults observed under wine
Message-ID: <87bjq9457k.fsf@protonmail.com>
Feedback-ID: 112775352:user:proton
MIME-Version: 1.0
From: Pip Cet via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Pip Cet <pipcet AT protonmail DOT com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>

This is about a bug which was observed when running msys2 binaries in
Wine under recent Linux kernels on new Intel/AMD CPUs that support the
PKU/PKRU feature, but it appears to be a bug in Cygwin; specifically,
in:

    c607889824395f0eac7e85d5b81c906bf8025321
    Author:     Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>
    AuthorDate: Sun Oct 13 07:41:40 2024 +0900
    Commit:     Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>
    CommitDate: Fri Nov 1 04:56:27 2024 +0900

    Cygwin: sigfe: Fix a bug that signal handler destroys fpu states

In this commit, we added these lines of code:

	movl	\$0x0d,%eax
	xorl	%ecx,%ecx
	cpuid	# get necessary space for xsave
	movq	%rbx,%rcx
	addq	\$0x48,%rbx # 0x18 for alignment, 0x30 for additional space
	subq	%rbx,%rsp
	movl	%ebx,0x24(%rsp)
	xorq	%rax,%rax
	shrq	\$3,%rcx
	leaq	0x30(%rsp),%rdi
	rep	stosq
	xgetbv	# get XCR0 (ecx is 0 after rep)
	movl	%eax,0x28(%rsp)
	movl	%edx,0x2c(%rsp)
	notl	%ecx # set ecx non-zero
	movl	%ecx,0x20(%rsp)
	xsave64	0x30(%rsp)

The problem is that those new Intel/AMD CPUs (I have one of each here)
report the PKU/PKRU feature with an additional XSAVE area of 8 bytes
(only 4 bytes are used).  This means that the cpuid instruction will
return in %rbx a value which is not aligned to 64 bytes, so our
subtraction will make %rsp+0x30 (the target of the xsave64 instruction)
misaligned (by 8 bytes) when we execute the xsave64 instruction, which
assumes its argument to be 64-byte aligned.  This causes a segfault and
abnormal program termination.

Disabling the PKU feature ("nopku" on the Linux kernel command line;
reboot) makes the problem go away, as does working around it in
winedbg --gdb:

    b *0x18019c647
    Breakpoint 1 at 0x18019c647
    Wine-gdb> command 1
    command 1
    Type commands for breakpoint(s) 1, one per line.
    End with a line saying just "end".
    >p $rbx += 56
    >c
    >end
    Wine-gdb> c

(Here, 0x18019c647 is the address of the movq %rbx, %rcx instruction in
the segment above).

My suggested fix is to align the value in %rbx to the next 64-byte
multiple after the "cpuid" instruction is executed, by performing the
assembler equivalent of $rbx += 63; $rbx &= -64; I tried this:

diff --git a/winsup/cygwin/scripts/gendef b/winsup/cygwin/scripts/gendef
index 861a2405b..d681fde3f 100755
--- a/winsup/cygwin/scripts/gendef
+++ b/winsup/cygwin/scripts/gendef
@@ -232,6 +232,8 @@ sigdelayed:
 	movl	\$0x0d,%eax
 	xorl	%ecx,%ecx
 	cpuid	# get necessary space for xsave
+	addq	\$63, %rbx
+	andq	\$-64, %rbx # align to next 64-byte multiple
 	movq	%rbx,%rcx
 	addq	\$0x48,%rbx # 0x18 for alignment, 0x30 for additional space
 	subq	%rbx,%rsp

And it worked in a very simple test, on the msys2-runtime source
(copying the DLL from a partially-successful build to the msys2 image).
I hope it's small enough to be exempt from copyright requirements!

I don't know whether (or when) Windows systems will support the PKU/PKRU
feature (which is extremely useful!), but I suspect the bug would occur
there, too, or with other small additional XSAVE areas.

Links to GitHub issues for the related msys2 problem:

    https://github.com/msys2/msys2-runtime/issues/295
    https://github.com/msys2/msys2-docker/issues/18

Sorry this got a bit long, and thanks!

Pip


-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple