How is Win/Dos syscalls implemented in Wine?

Peter Andersson kanelballe at
Sat Oct 26 17:02:32 CDT 2002

On Saturday 26 October 2002 21.32, Eric Pouech wrote:
> > 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
OK, I didnt realise this before (lack of wine knowledge). 
This means the linux sycall can possibly come from every wine-native 
dll. I agree, tracing syscalls will be very hard indeed. 

> > > 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
> 3)
> (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
> A+

You are right, and as Sylvain Petreolle wrote it might even be possible to 
push the (iret) adress and jump to an int 80h instruction. But its still a 
fact that the supervisor process would trap the syscall, wouldnt it?
It could still do a sanity check of the sycall. I know its hard but a few
worst case scenario, like the removed home directory, could be catched.
Some protection is better than no protection.


More information about the wine-devel mailing list