Re: [PATCH v2 0/1] MR10330: ntdll: Implement syscall emulation on Linux using Syscall User Dispatch.

[Elizabeth Figura (＠zfigura)]

The maybe touchy part of this feature is the logic to find and exclude libc.

This is necessary because of sigreturn. (It would also be necessary because of the syscalls made from sigsys_handler itself, namely arch_prctl and the write generated by TRACE, but we could flip the toggle to avoid these.) Returning from the SIGSYS handler will jump back into PE code, but it does so using the sigreturn syscall, which itself will generate SIGSYS otherwise. We cannot flip the toggle after jumping back to PE code. The "exclusion area" was designed to address this exact problem.

The proposed approach of dl_iterate_phdr() looks reasonable to me; it relies on documented APIs, and only needs to hardcode the name of libc. If we can't find libc for any reason (e.g. because the name is different, or it's statically linked), we simply don't use SUD.

Still, concerns have been raised that this might seem too hacky, so for the sake of completeness here are the alternative approaches I see:

* Instead of using dl_iterate_phdr(), parse /proc/self/maps. This is largely the same approach, but would avoid a hypothetical situation where for some reason dl_iterate_phdr() is hooked but the sigreturn syscalls are still in libc. I don't think we know of such a situation though. On the other hand, it would also avoid depending on glibc, instead using more Linux-specific interfaces. I doubt that this is the only glibc-specific logic in Wine, though.

* Implement upstream a libc interface to return the area that must be excluded, or, more likely, an interface that simply establishes SUD without any exclusion area, and lets libc establish the exclusion area itself. This will take some time, of course.

If this patch seems too hacky, or even "maybe hacky" such that judgement cannot be passed, I would appreciate an evaluation if any of these alternatives seems definitely better, or if none of them do.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/10330#note_132225