From: Elizabeth Figura <zfigura@codeweavers.com>
To: x86@kernel.org, Linux Kernel <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Ricardo Neri <ricardo.neri-calderon@linux.intel.com>,
wine-devel@winehq.org
Subject: x86 SGDT emulation for Wine
Date: Wed, 27 Dec 2023 16:20:37 -0600 [thread overview]
Message-ID: <2285758.taCxCBeP46@uriel> (raw)
Hello all,
There is a Windows 98 program, a game called Nuclear Strike, which wants to do
some amount of direct VGA access. Part of this is port I/O, which naturally
throws SIGILL that we can trivially catch and emulate in Wine. The other part
is direct access to the video memory at 0xa0000, which in general isn't a
problem to catch and virtualize as well.
However, this program is a bit creative about how it accesses that memory;
instead of just writing to 0xa0000 directly, it looks up a segment descriptor
whose base is at 0xa0000 and then uses the %es override to write bytes. In
pseudo-C, what it does is:
int get_vga_selector()
{
sgdt(&gdt_size, &gdt_ptr);
sldt(&ldt_segment);
++gdt_size;
descriptor = gdt_ptr;
while (descriptor->base != 0xa0000)
{
++descriptor;
gdt_size -= sizeof(*descriptor);
if (!gdt_size)
break;
}
if (gdt_size)
return (descriptor - gdt_ptr) << 3;
descriptor = gdt_ptr[ldt_segment >> 3]->base;
ldt_size = gdt_ptr[ldt_segment >> 3]->limit + 1;
while (descriptor->base != 0xa0000)
{
++descriptor;
ldt_size -= sizeof(*descriptor);
if (!ldt_size)
break;
}
if (ldt_size)
return (descriptor - ldt_ptr) << 3;
return 0;
}
Currently we emulate IDT access. On a read fault, we execute sidt ourselves,
check if the read address falls within the IDT, and return some dummy data
from the exception handler if it does [1]. We can easily enough implement GDT
access as well this way, and there is even an out-of-tree patch written some
years ago that does this, and helps the game run.
However, there are two problems that I have observed or anticipated:
(1) On systems with UMIP, the kernel emulates sgdt instructions and returns a
consistent address which we can guarantee is invalid. However, it also returns
a size of zero. The program doesn't expect this (cf. the way the loop is
written above) and I believe will effectively loop forever in that case, or
until it finds the VGA selector or hits invalid memory.
I see two obvious ways to fix this: either adjust the size of the fake
kernel GDT, or provide a switch to stop emulating and let Wine handle it. The
latter may very well a more sustainable option in the long term (although I'll
admit I can't immediately come up with a reason why, other than "we might need
to raise the size yet again".)
Does anyone have opinions on this particular topic? I can look into
writing a patch but I'm not sure what the best approach is.
(2) On 64-bit systems without UMIP, sgdt returns a truncated address when in
32-bit mode. This truncated address in practice might point anywhere in the
address space, including to valid memory.
In order to fix this, we would need the kernel to guarantee that the GDT
base points to an address whose bottom 32 bits we can guarantee are
inaccessible. This is relatively easy to achieve ourselves by simply mapping
those pages as noaccess, but it also means that those pages can't overlap
something we need; we already go to pains to make sure that certain parts of
the address space are free. Broadly anything above the 2G boundary *should* be
okay though. Is this feasible?
We could also just decide we don't care about systems without UMIP, but
that seems a bit unfortunate; it's not that old of a feature. But I also have
no idea how hard it would be to make this kind of a guarantee on the kernel
side.
This is also, theoretically, a problem for the IDT, except that on the
machines I've tested, the IDT is always at 0xfffffe0000000000. That's not
great either (it's certainly caused some weirdness and confusion when
debugging, when we unexpectedly catch an unrelated null pointer access) but it
seems to work in practice.
--Zeb
[1] https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/krnl386.exe16/
instr.c#l702
next reply other threads:[~2023-12-27 22:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-27 22:20 Elizabeth Figura [this message]
2023-12-27 23:58 ` x86 SGDT emulation for Wine H. Peter Anvin
2024-01-02 17:12 ` Sean Christopherson
2024-01-02 19:53 ` Elizabeth Figura
2024-01-03 7:30 ` Stefan Dösinger
2024-01-03 15:19 ` Sean Christopherson
2024-01-03 15:33 ` H. Peter Anvin
2024-01-04 6:35 ` Elizabeth Figura
2024-01-05 1:02 ` H. Peter Anvin
2024-01-05 1:21 ` Sean Christopherson
2024-01-05 2:47 ` Andrew Cooper
2024-01-05 4:03 ` H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2285758.taCxCBeP46@uriel \
--to=zfigura@codeweavers.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=ricardo.neri-calderon@linux.intel.com \
--cc=tglx@linutronix.de \
--cc=wine-devel@winehq.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).