Hello! Perhaps someone can give me a good answer to this question. Please give me a direct answer, I have allready been trouh the wine FAQ:s , docs, code, etc.
I know DOS syscalls is made using interupts (int instruction) but, is Windows/NT syscalls made the same way. How does wine stop these instructions from reaching the unix kernel?
On Fri, 25 Oct 2002, Peter Andersson wrote:
Hello! Perhaps someone can give me a good answer to this question. Please give me a direct answer, I have allready been trouh the wine FAQ:s , docs, code, etc.
I know DOS syscalls is made using interupts (int instruction) but, is Windows/NT syscalls made the same way.
What are Windows/NT syscalls? Win32 apps doesn't make any syscalls, they just call the system DLLs (which is just shared libraries). Wine implements those DLLs in its own way.
How does wine stop these instructions from reaching the unix kernel?
If you're talking about interrupts, the ones that DOS/Windows app may use aren't accepted by Linux, so a segmentation fault happens when an app tries to issue such an interrupt. Wine can catch that segmentation fault by installing a SIGSEGV signal handler. If you're talking about the Win32 API, then Wine just links the app to its own version of that API, so it calls into the Wine-implemented DLLs.
Hi, Ok, I think I get it (never been much into Windoze codeing)... Windows "syscalls" is also actually done by requesting a dll mapping and calling the system_function inside processed mapped memory. Am I right so far?
Is the dll mapping event, itself raised by some kind of SIGSEGV signal?
About the DOS/Windows interrupts: Is it really sure that trusting SIGSEGV is safe? What happens for instance in this case:
EAX (ackumulator register)= (char *) "$HOME" and an instruction interupt 10h (Linux unlink syscall)? This is a fully correct Linux syscall, wich would remove the users homedirectory if called, and would not raise a SIGSEGV signal. How would Wine stop this?
I know wine uses the ptrace syscall, is that really only for debugging purposes, or is it for catching the SIGSEGV signals also?
//Peter
On Friday 25 October 2002 17.26, you wrote:
On Fri, 25 Oct 2002, Peter Andersson wrote:
Hello! Perhaps someone can give me a good answer to this question. Please give me a direct answer, I have allready been trouh the wine FAQ:s , docs, code, etc.
I know DOS syscalls is made using interupts (int instruction) but, is Windows/NT syscalls made the same way.
What are Windows/NT syscalls? Win32 apps doesn't make any syscalls, they just call the system DLLs (which is just shared libraries). Wine implements those DLLs in its own way.
How does wine stop these instructions from reaching the unix kernel?
If you're talking about interrupts, the ones that DOS/Windows app may use aren't accepted by Linux, so a segmentation fault happens when an app tries to issue such an interrupt. Wine can catch that segmentation fault by installing a SIGSEGV signal handler. If you're talking about the Win32 API, then Wine just links the app to its own version of that API, so it calls into the Wine-implemented DLLs.
Ok, I think I get it (never been much into Windoze codeing)... Windows "syscalls" is also actually done by requesting a dll mapping and calling the system_function inside processed mapped memory. Am I right so far?
it's how it's done in windows. it doesn't mean wine implement it the same may basically in win NT, all systems calls are made from ntdll ntdll in turn issues system call to the "internal" system wine doesn't implement such a mechanism, nor does it allow to run the native ntdll it just reimplements the ntdll (and uses the wineserver, which can be seen as many regards as the windows internal system)
Is the dll mapping event, itself raised by some kind of SIGSEGV signal?
no, just pure function calls
About the DOS/Windows interrupts: Is it really sure that trusting SIGSEGV is safe? What happens for instance in this case:
EAX (ackumulator register)= (char *) "$HOME" and an instruction interupt 10h (Linux unlink syscall)? This is a fully correct Linux syscall, wich would remove the users homedirectory if called, and would not raise a SIGSEGV signal. How would Wine stop this?
wine doesn't stop linux syscall from happenning (btw, linux doesn't use interrupt 10, but 0x80. you must refer to the operation code in linux syscall)
what Ove describe is only valid for bios and msdos interrupts. we don't emulate nt system calls
I know wine uses the ptrace syscall, is that really only for debugging purposes, or is it for catching the SIGSEGV signals also?
not only debugging. also for cross process memory manipulation for example
On Fri, 25 Oct 2002, Peter Andersson wrote:
Hi, Ok, I think I get it (never been much into Windoze codeing)...
Hmm. Have you been into Linux coding, then? (The concept of shared libraries seem a little foreign to you...)
Windows "syscalls" is also actually done by requesting a dll mapping and calling the system_function inside processed mapped memory. Am I right so far?
I'm still not sure what you're talking about. Again, Win32 apps doesn't do syscalls.
Or, let's see, what do you consider a syscall? If from your Linux program, you call malloc(), is that a syscall? It sounds like you think it is. But it isn't, it's a call into a shared library (libc.so)
Is the dll mapping event, itself raised by some kind of SIGSEGV signal?
DLLs are imported by the app, just like your Linux app imports libc.so (and ld.so is the loader that actually loads libc.so and links your Linux app against it at runtime).
About the DOS/Windows interrupts: Is it really sure that trusting SIGSEGV is safe? What happens for instance in this case:
EAX (ackumulator register)= (char *) "$HOME" and an instruction interupt 10h (Linux unlink syscall)?
This is a fully correct Linux syscall,
Since when? A syscall number isn't an interrupt vector number. Linux/i386 syscalls are always entered via int 0x80 (with eax being the syscall number). All other ints are invalid and generate a SIGSEGV.
wich would remove the users homedirectory if called, and would not raise a SIGSEGV signal. How would Wine stop this?
If, let's say, a windoze app really used int 0x80 to intentially obliterate the user's system? Well, Wine wouldn't stop it.
I know wine uses the ptrace syscall, is that really only for debugging purposes, or is it for catching the SIGSEGV signals also?
It's to support certain win32 features (that's mostly used for debugging). Catching signals is done with sigaction().
Why couldnt we implement a int 0x80 that would do nothing/call SIGSEGV handler ? We did it for all other ints we have implemented.
If, let's say, a windoze app really used int 0x80 to intentially obliterate the user's system? Well, Wine wouldn't stop it.
I know wine uses the ptrace syscall, is that really only for debugging purposes, or is it for catching the SIGSEGV signals also?
It's to support certain win32 features (that's mostly used for debugging). Catching signals is done with sigaction().
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
On Sat, 26 Oct 2002, Sylvain Petreolle wrote:
Why couldnt we implement a int 0x80 that would do nothing/call SIGSEGV handler ? We did it for all other ints we have implemented.
That's not the way it works. Interrupt goes to OS core (global IDT table actually), is rejected (privilege level check fails), SIGSEGV is raised, Wine detects SIGSEGV and its cause, Wine handles interrupt. You can't change the order in which this happens from user-space. Only a kernel module can replace IDT entries (and if you did, replacing the 0x80 entry would kill *all* running Linux apps, since the IDT is global).
"Ove" == Ove Kaaven ovehk@ping.uio.no writes:
Ove> On Sat, 26 Oct 2002, Sylvain Petreolle wrote:
>> Why couldnt we implement a int 0x80 that would do nothing/call >> SIGSEGV handler ? We did it for all other ints we have implemented.
Ove> That's not the way it works. Interrupt goes to OS core (global IDT Ove> table actually), is rejected (privilege level check fails), SIGSEGV Ove> is raised, Wine detects SIGSEGV and its cause, Wine handles Ove> interrupt. You can't change the order in which this happens from Ove> user-space. Only a kernel module can replace IDT entries (and if Ove> you did, replacing the 0x80 entry would kill *all* running Linux Ove> apps, since the IDT is global).
What happens on a win/win32 system when a program has lets say a sequence like "set up values for thread abort for linux, call int80()" in its startup code?
Bye
On Sat, 26 Oct 2002, Uwe Bonnes wrote:
"Ove" == Ove Kaaven ovehk@ping.uio.no writes:
Ove> On Sat, 26 Oct 2002, Sylvain Petreolle wrote: >> Why couldnt we implement a int 0x80 that would do nothing/call >> SIGSEGV handler ? We did it for all other ints we have implemented. Ove> That's not the way it works. Interrupt goes to OS core (global IDT Ove> table actually), is rejected (privilege level check fails), SIGSEGV Ove> is raised, Wine detects SIGSEGV and its cause, Wine handles Ove> interrupt. You can't change the order in which this happens from Ove> user-space. Only a kernel module can replace IDT entries (and if Ove> you did, replacing the 0x80 entry would kill *all* running Linux Ove> apps, since the IDT is global).What happens on a win/win32 system when a program has lets say a sequence like "set up values for thread abort for linux, call int80()" in its startup code?
I'm not sure, but I'd expect an exception to be raised. (Gav once investigated what an int80 does under Windows, as part of development related to WineX's secret copy protection code, and I think he said that it would crash on his system)
Thanks for putting my thinking on the right track again...
Conclusion: The ntdll is for wine apps what libc is for Linux/Unix. Syscalls is made from ntdll and the native version is never run.
You are right about the syscalls in Linux, too bad theres no protection for it though. It should be, otherwise there could appear wine_linux viruses. Cant you fix this with ptrace?
Thanks for your help!
//Peter
On Friday 25 October 2002 17.26, Ove Kaaven wrote:
On Fri, 25 Oct 2002, Peter Andersson wrote:
Hello! Perhaps someone can give me a good answer to this question. Please give me a direct answer, I have allready been trouh the wine FAQ:s , docs, code, etc.
I know DOS syscalls is made using interupts (int instruction) but, is Windows/NT syscalls made the same way.
What are Windows/NT syscalls? Win32 apps doesn't make any syscalls, they just call the system DLLs (which is just shared libraries). Wine implements those DLLs in its own way.
How does wine stop these instructions from reaching the unix kernel?
If you're talking about interrupts, the ones that DOS/Windows app may use aren't accepted by Linux, so a segmentation fault happens when an app tries to issue such an interrupt. Wine can catch that segmentation fault by installing a SIGSEGV signal handler. If you're talking about the Win32 API, then Wine just links the app to its own version of that API, so it calls into the Wine-implemented DLLs.
Conclusion: The ntdll is for wine apps what libc is for Linux/Unix. Syscalls is made from ntdll and the native version is never run.
mostly (libc contains much more than ntdll does). A closer (yet incomplete) answer would be libc = ntdll + kernel32 + msvcrt (most of the win32 apps don't call ntdll in, they call kernel32 or msvcrt in)
You are right about the syscalls in Linux, too bad theres no protection for it though. It should be, otherwise there could appear wine_linux viruses.
well, there could, as well, be pure linux viruses. and, I don't see why wine should be more protective than the linux kernel is.
Cant you fix this with ptrace?
no.
A+
On Saturday 26 October 2002 14.13, Eric Pouech wrote:
Conclusion: The ntdll is for wine apps what libc is for Linux/Unix. Syscalls is made from ntdll and the native version is never run.
mostly (libc contains much more than ntdll does). A closer (yet incomplete) answer would be libc = ntdll + kernel32 + msvcrt (most of the win32 apps don't call ntdll in, they call kernel32 or msvcrt in)
You are right about the syscalls in Linux, too bad theres no protection for it though. It should be, otherwise there could appear wine_linux viruses.
well, there could, as well, be pure linux viruses. and, I don't see why wine should be more protective than the linux kernel is.
Well for now there are not much Linux viruses around. It is possible to write an antivirus program (I have not heard of any yet) for Linux/Unix. And there are antivirus programs for Windows. But how do you check for viruses that directly affects the Linux/Unix environment embedded within a Windows app? I believe running windows apps in wine should be trusted the same way as enabling java in a web browser.
Has an int 0x80 any purpose in Windows environment? What does it do?
Cant you fix this with ptrace?
no.
A+
Are you really sure?
Here is a cut of the Linux man side: ... ... ... PTRACE_SYSCALL, PTRACE_SINGLESTEP Restarts the stopped child as for PTRACE_CONT, but arranges for the child to be stopped at the next entry to or exit from a system call, or after exe- cution of a single instruction, respectively. (The child will also, as usual, be stopped upon receipt of a signal.) From the parent's perspective, the child will appear to have been stopped by receipt of a SIGTRAP. So, for PTRACE_SYSCALL, for example, the idea is to inspect the arguments to the system call at the first stop, then do another PTRACE_SYSCALL and inspect the return value of the system call at the second stop. (addr is ignored.) ... ... ...
Cant you use this to trap the call and kill the process before it enters the kernel or maybe if its a 0x80 intreupt check the params for the call and do some protective actions if the call is not supported by wine?
//Peter
Well for now there are not much Linux viruses around. It is possible to write an antivirus program (I have not heard of any yet) for Linux/Unix.
if antivirus check for a signature, it should find it. it would be more difficult for polyforms virii of course. As of today, I don't think that people willing to write virii for (against) Linux would use wine as their insertion media
And there are antivirus programs for Windows. But how do you check for viruses that directly affects the Linux/Unix environment embedded within a Windows app? I believe running windows apps in wine should be trusted the same way as enabling java in a web browser.
there are some validity checks against the PE (file format). however, wine doesn't provide a sandbox. intercepting linux syscalls isn't enough you need also to prevent : 1/ read/write to wine memory (which would trigger some other nice side effects) 2/ read/write of local files (which isn't allowed for java in web browser by default...) 3/ know if a requested operation (syscall, win32 api call) is malicious or not
so wine will not protect users from windows programs
the best thing to do (see some recent discussion on wine-devel on this topic) is to limit the part of the disk wine will be allowed to read/write to
Has an int 0x80 any purpose in Windows environment?
under dos it sure has (don't have Ralf Brown list handy)
Cant you fix this with ptrace?
Are you really sure?
you will need to: 1/ know which part of memory is calling (wine DLLs vs program exec vs loaded DLLs) [regular windows API must be allowed to call linux syscalls] 2/ allow disallow the traps you want 3/ and because of the point 1 above, this will not be of any protection.
for example, look at the following scheme: 1/ get the address of the implementation of an API in wine 2/ call Win32 API to allow write access to this part of memory 3/ modify the code the make the linux syscall you want 4/ call in this API.
of course, you could in the ptrace code check for CRC of memory (or calling page), but I wouldn't dare to use the final performance of such a beast
if you have enough time to loose on this, feel free to do it
A+
On Saturday 26 October 2002 18.01, Eric Pouech wrote:
Well for now there are not much Linux viruses around. It is possible to write an antivirus program (I have not heard of any yet) for Linux/Unix.
if antivirus check for a signature, it should find it. it would be more difficult for polyforms virii of course. As of today, I don't think that people willing to write virii for (against) Linux would use wine as their insertion media
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 :-)
And there are antivirus programs for Windows. But how do you check for viruses that directly affects the Linux/Unix environment embedded within a Windows app? I believe running windows apps in wine should be trusted the same way as enabling java in a web browser.
there are some validity checks against the PE (file format). however, wine doesn't provide a sandbox. intercepting linux syscalls isn't enough you need also to prevent : 1/ read/write to wine memory (which would trigger some other nice side effects) 2/ read/write of local files (which isn't allowed for java in web browser by default...) 3/ know if a requested operation (syscall, win32 api call) is malicious or not
so wine will not protect users from windows programs
the best thing to do (see some recent discussion on wine-devel on this topic) is to limit the part of the disk wine will be allowed to read/write to
Has an int 0x80 any purpose in Windows environment?
under dos it sure has (don't have Ralf Brown list handy)
Cant you fix this with ptrace?
Are you really sure?
you will need to: 1/ know which part of memory is calling (wine DLLs vs program exec vs loaded DLLs) [regular windows API must be allowed to call linux syscalls]
I was told direct syscalls were only made through lovest level dlls, like ntdll,and from whithin dos/16 bit system. Whats this?
2/ allow disallow the traps you want
Why disallow interupt traps?
3/ and because of the point 1 above, this will not be of any protection.
for example, look at the following scheme: 1/ get the address of the implementation of an API in wine 2/ call Win32 API to allow write access to this part of memory 3/ modify the code the make the linux syscall you want 4/ call in this API.
of course, you could in the ptrace code check for CRC of memory (or calling page), but I wouldn't dare to use the final performance of such a beast
if you have enough time to loose on this, feel free to do it
A+
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?
//Peter
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 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+
I disagree here. one anti debug / hiding technique is : 1)set regs 1a) push 3) location on the stack. 2) jump to 80h then the "iret" instruction in int 80h will jump to 3)
malicious non trusted dll:
- setup malicious regs (like erase file...)
- 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
A+
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
On Sat, 26 Oct 2002, Sylvain Petreolle wrote:
I disagree here. one anti debug / hiding technique is : 1)set regs 1a) push 3) location on the stack. 2) jump to 80h then the "iret" instruction in int 80h will jump to 3)
Well, while I agree with the general sentiment, this is technically not quite right. In i386 protected mode, you cannot jump directly to code with a different privilege level (it'd cause a GPF/SIGSEGV to try), it must be done through a "gate" (typically an interrupt). Passing through such a privilege-transition gate also implies switching to a similarly-privileged stack (before the return address is pushed), so you cannot push your own return address onto the kernel's privileged stack. And you probably can't even get the address of the kernel interrupt handler (the IDT can be protected from being read). This doesn't make Wine any more secure though, of course...
Well, while I agree with the general sentiment, this is technically not quite right. In i386 protected mode, you cannot jump directly to code with a different privilege level (it'd cause a GPF/SIGSEGV to try), it must be done through a "gate" (typically an interrupt). Passing through such a privilege-transition gate also implies switching to a similarly-privileged stack (before the return address is pushed), so you cannot push your own return address onto the kernel's privileged stack. And you probably can't even get the address of the kernel interrupt handler (the IDT can be protected from being read). This doesn't make Wine any more secure though, of course...
I wasn't talking about jumping directly into the kernel I was referring to the trusted/untrusted DLL part. the int 80h instruction was in trusted code. I was trying to show that "trusting" DLLs (or code pages) to allow/disallow syscalls could be rather easily circumvented and was offering no protection ("trusted" int 80h insn in trusted code could be used easily by untrusted code)
A+
On Sun, 27 Oct 2002, Eric Pouech wrote:
Well, while I agree with the general sentiment, this is technically not quite right. In i386 protected mode, you cannot jump directly to code with a different privilege level (it'd cause a GPF/SIGSEGV to try), it must be done through a "gate" (typically an interrupt). Passing through such a privilege-transition gate also implies switching to a similarly-privileged stack (before the return address is pushed), so you cannot push your own return address onto the kernel's privileged stack. And you probably can't even get the address of the kernel interrupt handler (the IDT can be protected from being read). This doesn't make Wine any more secure though, of course...
I wasn't talking about jumping directly into the kernel
Hm? I was replying to Sylvain, who was talking about that.
Hm? I was replying to Sylvain, who was talking about that.
talking too much of security must have turned me paranoid ;-) A+
Sylvain Petreolle a écrit :
I disagree here. one anti debug / hiding technique is : 1)set regs 1a) push 3) location on the stack. 2) jump to 80h then the "iret" instruction in int 80h will jump to 3)
agreed (devil is in details) A+
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:
- setup malicious regs (like erase file...)
- 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
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.
//Peter
On Sat, 26 Oct 2002, Peter Andersson wrote:
Thanks for putting my thinking on the right track again...
Conclusion: The ntdll is for wine apps what libc is for Linux/Unix. Syscalls is made from ntdll and the native version is never run.
That sounds about right.
You are right about the syscalls in Linux, too bad theres no protection for it though. It should be, otherwise there could appear wine_linux viruses. Cant you fix this with ptrace?
It's not generally considered a big risk (it could even be considered a feature in some situations), and excessive ptrace usage makes attaching with a debugger like gdb much harder, and it's not that easy to do (it should obviously be permitted from Wine code, but not Win32 code, but how do your ptrace handler figure out what's Wine code and what's not?). But feel free to code it yourself if you're concerned...
-
Eric Pouech -
Ove Kaaven -
Peter Andersson -
Sylvain Petreolle -
Uwe Bonnes