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

[Zebediah Figura (she/her)]

On 10/6/21 06:25, Emil Velikov wrote:
> Thanks for the elaborate answer Zebediah,
> 
> On Tue, 5 Oct 2021 at 17:57, Zebediah Figura (she/her)
> <zfigura at codeweavers.com> wrote:
> 
>> * 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.
>>
> 
> Due to the different struct sizes, paddings and alike, this means that
> Wine will need to add a "compat_ioctl" style wrapper, correct?
> I guess such code is planned, although I don't think it landed just yet.

Yes, and there's actually already a __wine_unix_call_wow64_funcs which I 
believe is supposed to serve that purpose, although nothing defines it 
yet. Of course, another alternative is just to use constant struct sizes 
(including e.g. a 64-bit integer for all pointers).

> 
>> * 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.
>>
> 
> That is an interesting way to workaround such "lovely" behaviour.
> Sounds like prime contender for the hall of shame :-P
> 
>>>
>>> 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.
> 
> Hope the team finds a way. Or at least get the infra in, so when the
> eureka moment comes it won't involve updating dozens of modules.
> 
> -Emil
>