As the last leg of my journey (for now) implementing Windows' thousand synchronization objects, I arrive at ERESOURCE. Unlike the last three forms of mutex, these can be recursively acquired, and so it's necessary to keep track of who is holding them. I have a complete implementation that passes its own tests, but only with KeGetCurrentThread() stubbed to return the TID.
A proper implementation of KeGetCurrentThread() is already required by some drivers (bug 45844). What would be necessary to implement this function in an acceptable way? If simply returning the TID isn't enough (and I believe this approach has been rejected before), how much of the structure need we correctly implement? How can we find out what that structure is, undocumented as it is? (For a slightly more concrete question: is [1] a legally safe source?)
ἔρρωσθε, Zeb
Hi Zebediah,
On 2/1/19 4:44 AM, Zebediah Figura wrote:
As the last leg of my journey (for now) implementing Windows' thousand synchronization objects, I arrive at ERESOURCE. Unlike the last three forms of mutex, these can be recursively acquired, and so it's necessary to keep track of who is holding them. I have a complete implementation that passes its own tests, but only with KeGetCurrentThread() stubbed to return the TID.
As mentioned in bug, if it's the only thing preventing you from sending it, using KeGetCurrentThreadId() in ERESOURCE until we have KeGetCurrentThread() doesn't seem too bad.
A proper implementation of KeGetCurrentThread() is already required by some drivers (bug 45844). What would be necessary to implement this function in an acceptable way? If simply returning the TID isn't enough (and I believe this approach has been rejected before), how much of the structure need we correctly implement? How can we find out what that structure is, undocumented as it is? (For a slightly more concrete question: is [1] a legally safe source?)
I don't know about how much of the actual struct do we need, but even being able to reference the object by pointer would be enough for some applications (and for your use case, I guess). I recently looked at ObReferenceObjectByHandle (which is needed by MRAC anti-cheat as well we others, according to bugzilla). It's not strictly needed for KeGetCurrentThread(), but having it implemented for threads would take care of object lifetime and HANDLE to object pointer mapping. I have a proof of concept code for ObReferenceObjectByHandle(). The idea there is to do actual handles to client object pointer mapping in wineserver. Server also notifies device manager when the underlying object is released, so it may free its object.
Jacek
-
Jacek Caban -
Zebediah Figura