ntdll: enable CreateRemoteThread and RtlCreateUserThread for remote processes
[forgot to hit "reply to all" instead of just reply ...] On 7/15/06, Dan Kegel <dank(a)kegel.com> wrote:
The right thing to do would be to promote the linux thread to be a win32 thread, but as a temporary stopgap, Thomas had the linux thread just do CreateThread and exit, hoping that the newly create Windows thread was healthy.
Well, I think calling CreateThread directly from the context of the hijacked thread would be simpler, though I understand that gets hairy as well if the hijacked thread is holding (say) the loader lock
Maybe we should look more carefully about what it takes to build a normal, healthy win32 thread from a posix thread.
This has been looked at in the past for sure, but I'm not sure if it's documented anywhere.
Well, kind of. Signals are only delivered when syscalls return, so they won't work well if the thread you pick to molest happens to not make any syscalls for a long time.
Hm, really? I haven't come across this before ... how then is it possible to debug a program that is sitting in while(1); if SIGSTOP cannot be delivered? Also we already use SIGUSR1 to suspend a thread and that has to work at any point, so maybe it might need to be changed.
You don't preserve the register state.
Really? What's ptrace(PTRACE_GETREGS, pid, NULL, regs) then, chopped liver? :-)
Oops, my mistake! Sorry Thomas, I didn't see that. If you switch EIP to a register function though you get all this for free ...
Well, if Alexandre thinks that's the way to go, that'd be fine. I thought those only fired when the thread in question performed an alertable wait condition (so says http://msdn.microsoft.com/library/en-us/dllproc/base/queueuserapc.asp ) so it didn't seem like an obvious way to go.
Right but if the thread is suspended then it's waiting, and we could maybe hack it to do an alertable wait. Though doing an alertable wait during a suspend is surely the wrong thing to do in most cases, presumably the server could easily queue an APC itself but not allow other clients to do the same. thanks -mike
On 7/16/06, Mike Hearn <mike(a)plan99.net> wrote:
Well, I think calling CreateThread directly from the context of the hijacked thread would be simpler, though I understand that gets hairy as well if the hijacked thread is holding (say) the loader lock
I'd rather not take the chance of doing anything that messes with the poor thread we're hijacking. Hmm... http://lwn.net/Articles/7577/ makes me think that converting a linux thread to a win32 thread might require initializing the thread's TLS area. We'll look at that a bit.
Well, kind of. Signals are only delivered when syscalls return, so they won't work well if the thread you pick to molest happens to not make any syscalls for a long time.
Hm, really? I haven't come across this before ... how then is it possible to debug a program that is sitting in while(1); if SIGSTOP cannot be delivered?
The magic of ptrace().
Well, if Alexandre thinks that's the way to go, that'd be fine. I thought those only fired when the thread in question performed an alertable wait condition (so says http://msdn.microsoft.com/library/en-us/dllproc/base/queueuserapc.asp ) so it didn't seem like an obvious way to go.
Right but if the thread is suspended then it's waiting, and we could maybe hack it to do an alertable wait. Though doing an alertable wait during a suspend is surely the wrong thing to do in most cases, presumably the server could easily queue an APC itself but not allow other clients to do the same.
That sounds a bit invasive, but if Alexandre prefers it, fine. - Dan
On 7/16/06, Dan Kegel <dank(a)kegel.com> wrote:
I'd rather not take the chance of doing anything that messes with the poor thread we're hijacking. Hmm... http://lwn.net/Articles/7577/ makes me think that converting a linux thread to a win32 thread might require initializing the thread's TLS area. We'll look at that a bit.
Basically everything along the Wine CreateThread codepath .... setting up a server connection, registering it with the server, initializing the TEB, signal setup, synchronizing the Wine VM list with the Linux VM list, allocating a guard page, doing thread attach notifications and finally calling the entrypoint inside a SEH backstop handler. Quite a lot of work, really, so I think it's easier to create the thread from another Wine thread somehow. thanks -mike
On 7/16/06, Mike Hearn <mike(a)plan99.net> wrote:
On 7/16/06, Dan Kegel <dank(a)kegel.com> wrote:
I'd rather not take the chance of doing anything that messes with the poor thread we're hijacking. Hmm... http://lwn.net/Articles/7577/ makes me think that converting a linux thread to a win32 thread might require initializing the thread's TLS area. We'll look at that a bit.
Basically everything along the Wine CreateThread codepath .... setting up a server connection, registering it with the server, initializing the TEB, signal setup, synchronizing the Wine VM list with the Linux VM list, allocating a guard page, doing thread attach notifications and finally calling the entrypoint inside a SEH backstop handler.
Quite a lot of work, really, so I think it's easier to create the thread from another Wine thread somehow.
It would be, except for the scary questions of a) whether the thread is in the middle of something that would interfere, and b) whether jamming a CreateThread call into an existing thread might disturb it somehow. - Dan
participants (2)
-
Dan Kegel -
Mike Hearn