[PATCH 3/4] winegstreamer: Convert the Unix library to the __wine_unix_call interface.

[Zebediah Figura (she/her)]

On 10/5/21 07:43, Emil Velikov wrote:
> Hi Zebediah,
> 
> On Tue, 5 Oct 2021 at 01:21, Zebediah Figura <zfigura at codeweavers.com> wrote:
>>
>> Signed-off-by: Zebediah Figura <zfigura at codeweavers.com>
>> ---
>>   dlls/winegstreamer/Makefile.in     |   1 +
>>   dlls/winegstreamer/gst_private.h   |  32 ++++-
>>   dlls/winegstreamer/main.c          | 197 ++++++++++++++++++++++++++-
>>   dlls/winegstreamer/media_source.c  |  44 +++---
>>   dlls/winegstreamer/quartz_parser.c |  72 +++++-----
>>   dlls/winegstreamer/unixlib.h       | 139 +++++++++++++++----
>>   dlls/winegstreamer/wg_parser.c     | 210 ++++++++++++++++++-----------
>>   7 files changed, 528 insertions(+), 167 deletions(-)
>>
> I've looked around for information about the unix library -> unix call
> transition, and didn't spot much.
> So if you don't mind I'll be asking a couple of, perhaps silly, questions :-)
> 
> The transition seems to move the unix library across the user->kernel
> space line, from Windows app POV, does it not? At the same time,
> what's the practical reason - do apps search through the
> process/namespace and fail, as they find the unix libs. Is there any
> overhead change - I would imagine it has increased to a point?

Broadly speaking, yes. There's basically three reasons I'm aware of (and 
can remember at the moment) for patches like this or d6d32434a7:

* By putting the Unix side behind the syscall interface, we essentially 
prevent debuggers from seeing it when debugging. We want this because 
debuggers just get confused when they see Unix code. (E.g. if you set a 
breakpoint in a signal handler, things tend to break badly.)

* The syscall interface can be used to swap architecture boundaries. Mac 
dropped 32-bit, some enterprise Linux distributions want to do the same; 
this would allow us to no longer require 32-bit Unix libraries.

* This one hasn't been discussed, but we have a bug (47808) where an 
application (Cygwin) replaces the normal thread stack with one that's 
actually split into reserved/committed parts, but then libfreetype jumps 
several pages at once expecting it to all be committed. This is a moot 
point for libfreetype specifically, because we'll probably compile it 
with MinGW and keep it on the PE side (in theory it has the same 
problem, but Windows applications should emit chkstk or something 
similar here and MinGW indeed does so). On the other hand, another 
library could run into something similar.

> 
> In addition, did the team consider using linux kernel style ioctls?
> These will allow you to preserve the type of the arguments, their
> respective size, as well as access level. This should help with
> out-of-bounds access and potentially writing into read-only memory,
> say due to a bug or security vulnerability in the unix lib.

I don't think it was thought of before. I don't think there was really 
any internal discussion about it either. I can definitely see the value 
in checking argument size—that's pretty easy to get wrong—although I'm 
not sure we can reasonably check access level.