On 10/5/21 07:43, Emil Velikov wrote:
Hi Zebediah,
On Tue, 5 Oct 2021 at 01:21, Zebediah Figura zfigura@codeweavers.com wrote:
Signed-off-by: Zebediah Figura zfigura@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.