[PATCH v2 1/2] ntdll/tests: Add a test for segment register contents in x86_64 exception handlers.
Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> --- v2: Test the contents of %es, %fs, %gs as well. dlls/ntdll/tests/exception.c | 40 +++++++++++++++++++++++++++++++++++- 1 file changed, 39 insertions(+), 1 deletion(-) diff --git a/dlls/ntdll/tests/exception.c b/dlls/ntdll/tests/exception.c index da88ca449fb..7c75606dd32 100644 --- a/dlls/ntdll/tests/exception.c +++ b/dlls/ntdll/tests/exception.c @@ -2812,7 +2812,7 @@ static void test___C_specific_handler(void) /* This is heavily based on the i386 exception tests. */ static const struct exception { - BYTE code[18]; /* asm code */ + BYTE code[40]; /* asm code */ BYTE offset; /* offset of faulting instruction */ BYTE length; /* length of faulting instruction */ NTSTATUS status; /* expected status code */ @@ -2921,6 +2921,34 @@ static const struct exception /* 35 */ { { 0xa3, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xc3 }, /* movl %eax,0xffffffffffffffff; ret */ 0, 9, STATUS_ACCESS_VIOLATION, 2, { 1, 0xffffffffffffffff } }, + + /* test exception with cleared segment registers */ + { { + 0x8c, 0xc0, /* mov %es,%eax */ + 0x50, /* push %rax */ + 0x8c, 0xd8, /* mov %ds,%eax */ + 0x50, /* push %rax */ + 0x8c, 0xe0, /* mov %fs,%eax */ + 0x50, /* push %rax */ + 0x8c, 0xe8, /* mov %gs,%eax */ + 0x50, /* push %rax */ + 0x31, 0xc0, /* xor %eax,%eax */ + 0x8e, 0xc0, /* mov %eax,%es */ + 0x8e, 0xd8, /* mov %eax,%ds */ + 0x8e, 0xe0, /* mov %eax,%fs */ + 0x8e, 0xe8, /* mov %eax,%gs */ + 0xfa, /* cli */ + 0x58, /* pop %rax */ + 0x8e, 0xe8, /* mov %eax,%gs */ + 0x58, /* pop %rax */ + 0x8e, 0xe0, /* mov %eax,%fs */ + 0x58, /* pop %rax */ + 0x8e, 0xd8, /* mov %eax,%ds */ + 0x58, /* pop %rax */ + 0x8e, 0xc0, /* mov %eax,%es */ + 0xc3, /* retq */ + }, 22, 1, STATUS_PRIVILEGED_INSTRUCTION, 0 }, + { { 0xf1, 0x90, 0xc3 }, /* icebp; nop; ret */ 1, 1, STATUS_SINGLE_STEP, 0 }, { { 0xcd, 0x2c, 0xc3 }, @@ -2992,6 +3020,16 @@ static DWORD WINAPI handler( EXCEPTION_RECORD *rec, ULONG64 frame, "%u: Unexpected exception address %p/%p\n", entry, rec->ExceptionAddress, (char*)context->Rip ); + todo_wine ok( context->SegDs == context->SegSs, + "%u: ds %#x does not match ss %#x\n", entry, context->SegDs, context->SegSs ); + todo_wine ok( context->SegEs == context->SegSs, + "%u: es %#x does not match ss %#x\n", entry, context->SegEs, context->SegSs ); + todo_wine ok( context->SegGs == context->SegSs, + "%u: ds %#x does not match ss %#x\n", entry, context->SegGs, context->SegSs ); + + todo_wine ok( context->SegFs && context->SegFs != context->SegSs, + "%u: got fs %#x\n", entry, context->SegFs ); + if (except->status == STATUS_BREAKPOINT && is_wow64) parameter_count = 1; else if (except->alt_status == 0 || rec->ExceptionCode != except->alt_status) -- 2.30.2
Based on a patch by Dávid Török. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=47970 Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> --- v2: Massage the context after returning to user mode; we may need it untouched for exceptions in 32-bit code. Actually, the behaviour of segment registers on x86_64 Windows is more complicated: * By default, %ss == %ds == %es == %gs == 0x2b; %cs == 0x33; %fs == 0x53. * NtGetContextThread() does not capture the actual values, but instead returns the default values. * All system calls restore all segments to their default values, including NtContinue(). * RtlRestoreContext() also restores all segments to their default values. * SegDs, SegEs, SegFs, SegGs all restore default values in exception handlers; SegSs returns the actual value of %ss. * RtlCaptureContext() does capture the actual values. I did not test: * whether %cs is correctly captured or restored in any functions; * whether segment registers are restored from exception handlers (either to the default values or to the values set in the context). We could, to a point, emulate the above, but it gets tricky. According to the Intel 64 and IA-32 Architectures Software Developer's Manual: * %es, %ds, %ss can point to any segment—the entire contents of the descriptor table are effectively ignored (if I'm reading Volume 3 §3.4.4 right). However, they have to point to a *valid* segment (cf. Volume 1 §3.4.2.1). * %cs is more restricted—the attributes in the descriptor table are also validated (Volume 3 §5.2.1). * I don't even know about %fs and %gs; the manual is too vague and confusing. dlls/ntdll/signal_x86_64.c | 4 ++++ dlls/ntdll/tests/exception.c | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/dlls/ntdll/signal_x86_64.c b/dlls/ntdll/signal_x86_64.c index b5be4f35758..d88f7ae553a 100644 --- a/dlls/ntdll/signal_x86_64.c +++ b/dlls/ntdll/signal_x86_64.c @@ -567,6 +567,10 @@ NTSTATUS WINAPI dispatch_exception( EXCEPTION_RECORD *rec, CONTEXT *context ) context->R12, context->R13, context->R14, context->R15 ); } + /* Legends of Runeterra depends on having SegDs == SegSs in an exception + * handler. */ + context->SegDs = context->SegSs; + if (call_vectored_handlers( rec, context ) == EXCEPTION_CONTINUE_EXECUTION) NtContinue( context, FALSE ); diff --git a/dlls/ntdll/tests/exception.c b/dlls/ntdll/tests/exception.c index 7c75606dd32..cdf3cdf8201 100644 --- a/dlls/ntdll/tests/exception.c +++ b/dlls/ntdll/tests/exception.c @@ -3020,7 +3020,7 @@ static DWORD WINAPI handler( EXCEPTION_RECORD *rec, ULONG64 frame, "%u: Unexpected exception address %p/%p\n", entry, rec->ExceptionAddress, (char*)context->Rip ); - todo_wine ok( context->SegDs == context->SegSs, + ok( context->SegDs == context->SegSs, "%u: ds %#x does not match ss %#x\n", entry, context->SegDs, context->SegSs ); todo_wine ok( context->SegEs == context->SegSs, "%u: es %#x does not match ss %#x\n", entry, context->SegEs, context->SegSs ); -- 2.30.2
Hi, While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=87844 Your paranoid android. === debiant2 (64 bit WoW report) === ntdll: change.c:277: Test failed: should be ready Report validation errors: ntdll:exception has no test summary line (early exit of the main process?) ntdll:exception has unaccounted for todo messages
Hi, While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=87843 Your paranoid android. === debiant2 (64 bit WoW report) === Report validation errors: ntdll:exception has no test summary line (early exit of the main process?) ntdll:exception has unaccounted for todo messages
Hi, On Sun, 28 Mar 2021, Marvin wrote: [...]
=== debiant2 (64 bit WoW report) ===
Report validation errors: ntdll:exception has no test summary line (early exit of the main process?) ntdll:exception has unaccounted for todo messages
As noticed by the TestBot this patch did introduce a new test failure: https://test.winehq.org/data/patterns-tb-wine.html#ntdll:exception It only impacts the wow64 builds. That the test does not print a summary line means it must be crashing hard somewhere (or that stdout gets summarily closed somehow?). Could you have a look? -- Francois Gouget <fgouget(a)codeweavers.com>
On 4/29/21 3:37 AM, Francois Gouget wrote:
Hi,
On Sun, 28 Mar 2021, Marvin wrote: [...]
=== debiant2 (64 bit WoW report) ===
Report validation errors: ntdll:exception has no test summary line (early exit of the main process?) ntdll:exception has unaccounted for todo messages
As noticed by the TestBot this patch did introduce a new test failure:
https://test.winehq.org/data/patterns-tb-wine.html#ntdll:exception
It only impacts the wow64 builds. That the test does not print a summary line means it must be crashing hard somewhere (or that stdout gets summarily closed somehow?).
Could you have a look?
Sorry for missing this the first time; I think WoW64 was broken at about this time and I misread this as being part of that. Anyway, I can't reproduce this locally, but the tests I was able to run on the testbot suggest that segv_handler() isn't even called. My guess is that it's a qemu/virtualization bug.
On 5/1/21 5:05 PM, Zebediah Figura (she/her) wrote:
On 4/29/21 3:37 AM, Francois Gouget wrote:
Hi,
On Sun, 28 Mar 2021, Marvin wrote: [...]
=== debiant2 (64 bit WoW report) ===
Report validation errors: ntdll:exception has no test summary line (early exit of the main process?) ntdll:exception has unaccounted for todo messages
As noticed by the TestBot this patch did introduce a new test failure:
https://test.winehq.org/data/patterns-tb-wine.html#ntdll:exception
It only impacts the wow64 builds. That the test does not print a summary line means it must be crashing hard somewhere (or that stdout gets summarily closed somehow?).
Could you have a look?
Sorry for missing this the first time; I think WoW64 was broken at about this time and I misread this as being part of that.
Anyway, I can't reproduce this locally, but the tests I was able to run on the testbot suggest that segv_handler() isn't even called. My guess is that it's a qemu/virtualization bug.
Further information: if I don't clear fs or gs, the test works as expected, but if I clear either one, it breaks. I can't reproduce this locally with a Debian 10 VM, with Linux 4.19.
participants (4)
-
Francois Gouget -
Marvin -
Zebediah Figura -
Zebediah Figura (she/her)