So, I think Alexandre has been ignoring this patch because it only reports correct information for the current process, even though the Mac implementation has the same problem. I can think of a few ways to fix that:
1. Do nothing if the handle passed to NtQueryInformationProcess is the handle of another process.
2. Add a wineserver call such as get_process_unix_pid to get the process's Unix PID from its handle. Modify the Mac code to use task_for_pid and the Linux code to use /proc/%u/status.
3. Add a wineserver call such as get_process_vm_counters to get all the information that ProcessVmCounters needs without exposing the Unix PID. Move the Mac code into the wineserver and add the Linux code there too.
Of those options, I think #3 makes the most sense. Ken, do you think it will cause any problems on Mac?
-Alex
On Mar 17, 2017, at 10:11 PM, Alex Henrie alexhenrie24@gmail.com wrote:
So, I think Alexandre has been ignoring this patch because it only reports correct information for the current process, even though the Mac implementation has the same problem. I can think of a few ways to fix that:
- Do nothing if the handle passed to NtQueryInformationProcess is the
handle of another process.
- Add a wineserver call such as get_process_unix_pid to get the
process's Unix PID from its handle. Modify the Mac code to use task_for_pid and the Linux code to use /proc/%u/status.
task_for_pid() is essentially unavailable. It has security implications, so Apple has put very severe restrictions on what processes can call it.
The wineserver has the Mach task ports for all Wine processes and your hypothetical call would have to inject the task port into the calling process rather than providing the PID. Of course, that presents its own version of the same security concerns as task_for_pid(), although limited in scope to Wine processes.
For what it's worth, there have been other occasions when I've thought it would be useful to be able to get task and thread ports of other Wine processes. For example, I have an implementation of using libunwind for StackWalk64() in dbghelp in a working tree, but it's limited. It can only work on the calling process because it needs the task and thread ports.
- Add a wineserver call such as get_process_vm_counters to get all
the information that ProcessVmCounters needs without exposing the Unix PID. Move the Mac code into the wineserver and add the Linux code there too.
Because the wineserver has the task ports, this would probably be more sensible.
One concern is if programs call this very frequently, adding a wineserver call could add a lot of overhead. I suspect that programs which call this frequently (if there are any) are probably calling it for themselves. So, we'd want to skip the wineserver call in that case, although that would mean duplicating the code in case 3.
-Ken
2017-03-17 23:20 GMT-06:00 Ken Thomases ken@codeweavers.com:
On Mar 17, 2017, at 10:11 PM, Alex Henrie alexhenrie24@gmail.com wrote:
So, I think Alexandre has been ignoring this patch because it only reports correct information for the current process, even though the Mac implementation has the same problem. I can think of a few ways to fix that:
- Do nothing if the handle passed to NtQueryInformationProcess is the
handle of another process.
- Add a wineserver call such as get_process_unix_pid to get the
process's Unix PID from its handle. Modify the Mac code to use task_for_pid and the Linux code to use /proc/%u/status.
task_for_pid() is essentially unavailable. It has security implications, so Apple has put very severe restrictions on what processes can call it.
The wineserver has the Mach task ports for all Wine processes and your hypothetical call would have to inject the task port into the calling process rather than providing the PID. Of course, that presents its own version of the same security concerns as task_for_pid(), although limited in scope to Wine processes.
For what it's worth, there have been other occasions when I've thought it would be useful to be able to get task and thread ports of other Wine processes. For example, I have an implementation of using libunwind for StackWalk64() in dbghelp in a working tree, but it's limited. It can only work on the calling process because it needs the task and thread ports.
Thanks for the explanation!
- Add a wineserver call such as get_process_vm_counters to get all
the information that ProcessVmCounters needs without exposing the Unix PID. Move the Mac code into the wineserver and add the Linux code there too.
Because the wineserver has the task ports, this would probably be more sensible.
One concern is if programs call this very frequently, adding a wineserver call could add a lot of overhead. I suspect that programs which call this frequently (if there are any) are probably calling it for themselves. So, we'd want to skip the wineserver call in that case, although that would mean duplicating the code in case 3.
I'm sure that most programs are only concerned about their own memory usage. So, if it's important to have a fast code path for self-examination, then we can implement solution #1 now and add onto it with solution #3 in the future.
-Alex
-
Alex Henrie -
Ken Thomases