XSAVE-related segfaults observed under wine

Fri Jun 27 19:39:17 GMT 2025

"Corinna Vinschen" <corinna-cygwin@cygwin.com> writes:
> Hi Pip,
>> On Jun 27 14:41, Pip Cet via Cygwin wrote:
>> 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	\0ドルx0d,%eax
>> 	xorl	%ecx,%ecx
>> 	cpuid	# get necessary space for xsave
>> +	addq	\63,ドル %rbx
>> +	andq	\$-64, %rbx # align to next 64-byte multiple
>> what about a oneliner instead by just aligning rsp? As in
>>> 	movq	%rbx,%rcx
>> 	addq	\0ドルx48,%rbx # 0x18 for alignment, 0x30 for additional space
>> 	subq	%rbx,%rsp
>> + andq \$-64, %rsp

We could do that, but it wouldn't be a one-liner, I'm afraid. Two
reasons:
1. It's 0x30(%rsp) that needs to be aligned, not %rsp. Entirely
solvable by making the extra space allocation 0x40 bytes instead of 0x30
bytes.
2. The current register push/pop code needs the stack pointer to be the
same after the xsave/xrstor code as it was before, so we'd need to stash
the old stack pointer somewhere. We could use the 16 bytes we just
extended the extra space area by, I suppose, but I tried changing it and
must have messed up somewhere; it didn't work.
> Would you mind to create a git send-email compatible patch with a nice
> commit message basically duplicating your great description of the
> problem and matching "Fixes:" and "Signed-off-by:" lines?

Sure; while I have tested this patch, it was all in the somewhat unusual
setting of running the msys2-docker-experimental image: I built the new
msys-2.0.dll on one Linux system (booted with "nopku"), then copied the
DLL over to another Linux system (with PKU support), confirmed it fixes
the bug when starting bash, and rebuilt the DLL on the PKU-enabled
system from scratch. Testing on Windows should obviously happen before
considering this patch further.
The only minor change is that %ecx now contains the
potentially-unaligned size; this means we clear only bytes that xsave64
might write to, not the alignment padding.
Please let me know if anything needs changing!
Thanks!
Pip
>From f81fb23b9bd4db9af9942c1bf9059a62849d4b80 Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@protonmail.com>
Subject: [PATCH] Cygwin: Fix segfault when XSAVE area sizes are unaligned
On recent AMD and Intel CPUs, the PKU/PKRU feature reports an XSAVE
storage area of just 8 bytes. This is exposed to Cygwin code when we
run in Wine under Linux.
The xsave64 instruction requires a memory area aligned to 64 bytes; in
the setting above, we would no longer meet that requirement, causing
segfaults and abnormal program termination.
This fix aligns the size of the structure we allocate on the stack
before performing an xsave64 to the next 64-byte multiple; the old
code already guarantees that structures of such size are aligned
properly for xsave64. This fixes the issue on Linux and hopefully
avoids it on future Windows systems which expose such features.
Fixes: c607889824 ("Cygwin: sigfe: Fix a bug that signal handler destroys fpu states")
Signed-off-by: Pip Cet <pipcet@protonmail.com>
---
 winsup/cygwin/scripts/gendef | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/winsup/cygwin/scripts/gendef b/winsup/cygwin/scripts/gendef
index 861a2405b..6328fe2fb 100755
--- a/winsup/cygwin/scripts/gendef
+++ b/winsup/cygwin/scripts/gendef
@@ -233,6 +233,8 @@ sigdelayed:
 	xorl	%ecx,%ecx
 	cpuid	# get necessary space for xsave
 	movq	%rbx,%rcx
+	addq	\63,ドル %rbx
+	andq	\$-64, %rbx # align to next 64-byte multiple
 	addq	\0ドルx48,%rbx # 0x18 for alignment, 0x30 for additional space
 	subq	%rbx,%rsp
 	movl	%ebx,0x24(%rsp)
-- 
2.50.0
