How is Win/Dos syscalls implemented in Wine?

Eric Pouech eric.pouech at
Sat Oct 26 14:32:04 CDT 2002

> You never know that the future holds. I can think of atleast one
> big company that want the death to Linux and Wine, its located
> in Redmond somewhere :-)
they'd better fix their own security holes ;-)

> I was told direct syscalls were only made through lovest level dlls,
> like ntdll,and from whithin dos/16 bit system.
> Whats this?
we're still speaking from two different levels:
- on windows, all the windows-syscalls are made from ntdll
- on wine, no real windows-syscalls are made. However, every (native
wine) DLL is able to link against libc and thus make linux-syscalls
hence the difference

> > 2/ allow disallow the traps you want
> Why disallow interupt traps?
(here read linux-syscalls)
> I must admit I dont have a percent of your knowledge about the Wine
> and Windows architectures, so I have a hard time understanding why
> this is needed, and if therfore if its because of the way Wine is currently
> working or the way Windows calling is made.
> Imagine you write and ownership protect the trusted low level dlls
> (the ones that are supposed to be allowed syscalls).
> Would it not be possible to trace every Wine process for interupts and check
> if its originates from the lowlevel dlls? Checking the adress where interupt
> was is in the memory range of the loaded ntdll, to allow or disallow the
> call. Wouldnt that work?
it depends what you want to achieve, but it won't be sufficient.
examine the following code:

trusted dll:
a) setup regs for syscall
b) int 80h

malicious non trusted dll:
1) setup malicious regs (like erase file...)
2) jump at the address of the int 80h above
(of course you won't be able to go back to 3), but this would still
allow you to make a valid syscall
looking at all trusted dlls you might even find some code where you get
something like (in trusted dll)
a) setup regs for syscall
b) int 80h
c) ret
and in that case, jsr address of b from untrusted code would circumvent
your scheme

once again, since:
- wine is just seen from the linux kernel as a standard process
- wine core DLLs and the loaded code live in the same address space
it would be extremely difficult to implement this type of protection on
wine (as it is today)
it might possible using some kind of code control tools. the new skins
on valgrind would help here, but that would be done in a completly
different manner


More information about the wine-devel mailing list