Ubuntu soft links a bunch of binaries in /usr/bin to softlinks that live
in /etc/alternatives/
When hitting any of these alternative softlinks execve would fail if the
host also didn't have the same softlink paths.
Allows us to correctly follow the symlinks on execve as well which fixes
launching wine directly from the wine symlink.
Alternatively you could have launched /usr/bin/wine-stable directly.
Also fixes FEX strace again.
glibc 2.34 changed the select interface to update the timeout on return
to more closely match the kernel interface.
glibc 2.33 always made a copy instead of updating.
Make sure to set the timeout on each iteration of select otherwise we
will end up having a timeout of zero. Thus burning a CPU core.
Only a partial fix for #1330, still needs preemption disabled to work.
On x86-64 hosts the Linux kernel resides in the top bit of VA which
isn't mapped in to userspace.
This means that userspace will never receive pointers living with that
top bit set unless you're running a 57bit VA host.
This results in userspace pointers never needing to do the sign
extending pointer canonicalization. But additionally some applications
actually don't understand the pointer canonicalization.
This results in bugs like: https://github.com/golang/go/issues/49405
Now if you're running on a 57bit VA host, this will end up behaving like
FEX but it seems like no one in golang land has really messed with 57bit
VA yet.
In AArch64, when configured with a 48bit VA, the userspace gets the full
48bit VA space and on EL mode switch has the full address range change
to the kernel's 48bit VA.
This means that we will /very/ likely allocate pointers in the high
48bit space since Linux currently allocates top-down.
So behave more like x86-64, hide the top 128TB of memory space from the
guest before boot.
Testing: Took the M1Max 15ms to 21ms allocate the top 128TB.
In the case of binfmt_misc being installed, but the user was still using
FEXLoader to pass in arguments then we wouldn't pass the arguments
forward to applications passed through execve.
This resolves an issue where Wine would fail to know where the rootfs
is since Wine launches a bunch of processes.
eg: `FEXLoader -R Ubuntu_21_04 wine winecfg` would fail before
Fixes#1323
This adds a new `ThunksDB.json` file to the config folder.
This file lets users describe thunks in a meaningful way without
duplicating it amongst multiple configuration files.
eg:
```
{
"DB": {
"GL": {
"Library" : "libGL-guest.so",
"Depends": [
"X11"
],
"Overlay": [
"/usr/lib/x86_64-linux-gnu/libGL.so",
"/usr/lib/x86_64-linux-gnu/libGL.so.1",
"/usr/lib/x86_64-linux-gnu/libGL.so.1.2.0",
"/usr/lib/x86_64-linux-gnu/libGL.so.1.7.0",
"/lib/x86_64-linux-gnu/libGL.so",
"/lib/x86_64-linux-gnu/libGL.so.1",
"/lib/x86_64-linux-gnu/libGL.so.1.2.0",
"/lib/x86_64-linux-gnu/libGL.so.1.7.0"
]
},
"X11": {
"Library": "libX11-guest.so",
"Overlay": [
"/usr/lib/x86_64-linux-gnu/libX11.so.6",
"/lib/x86_64-linux-gnu/libX11.so.6"
]
}
}
}
```
This file lets the user describe the library with an nicer name, in this instance
`GL` instead of `libGL-guest.so`.
It also tracks depedencies, like how GL currently has a hard dependency on X11.
This allows the loader to automatically enable the dependencies if described.
The `Overlays` array is like the regular Thunks config file but now in this DB file.
With the DB file now describing the libraries, this allows us to then stick a lighter
description inside of the Thunk Config file.
```
{
"ThunksDB": {
"GL": 1
}
}
```
With this example Thunk config file (Which can be configured per application), There is
a new property of name `ThunksDB`.
All this takes is key:value pairs which describe the user friendly library name and an Integer
to state if the thunk should be enabled or not.
This allows very quick toggling of thunks directly inside of the configuration files rather than
breaking the configuration to disable it.
There was a hard upper limit to 128 json elements, this has now been
removed.
The debugging text for the thunk overlay is now disabled. It can get
very spammy but it is useful for debugging purposes.
Fixes an issue where thunks would be entirely disabled if a RootFS isn't
set.
This meant debugging in a chroot or x86_64 host was breaking rootfs
epoll_pwait has a sigsetsize argument, which was unused in this case but
it caused strace to look ugly.
On epoll_ctl, don't write back the resulting event. The event isn't
written and depending on how the guest allocated the object, we could
have a 4byte overwrite.
Needed to fix rt_sigtimedwait to use the raw syscall.
Needed to have sigtimedwait and sigtimedwait_time64 parse siginfo_t
correctly.
glibc uses this to ensure it is sending the correct signal across from
their helper thread.
Needed to correctly parse sigval and sigevent for 32-bit.
Passes my unit test for timer_create
wine walks the file structure to ensure the cwdir is safe for use. It
does this with a combination of `getcwd` and `statx`.
Once it reachs `/` then in rootfs environments it would fail to find
directories we've deleted.
Thus making it impossible to find folders like `/mnt` and `/home`
Should be safe since it just gives the application a larger world view
In the case of running inside of a container then we need to redirect
where we look for configuration.
Currently we only care about pressure vessel so we just redirect some
options to check inside of `/run/host/`
This will resolve an issue where installed thunks wouldn't be found.
32-bit versions of these syscalls saturate on the upper limit.
Depending on which syscall it'll saturate signed or unsigned.
With set if the 32-bit value is UINT32_MAX then it'll saturate to the
maximum 64-bit value
This solves a problem where sometimes FEX would spin up a new process
while FEXMountDaemon was in the process of shutting down. Breaking
things on both sides.
Now the race conditions are squashed that I could see.
Also fixes one race where FEX is starting up and FEXMountDaemon is
spinning up. This case is where FEX managed to pull the lock file just
before it got deleted. Then sent the FEXMountDaemon a request to be
observed. With DGRAM sockets we would fire and forget. Use a STREAM with
a ack result so we know we can return.
The FEXMountDaemon no longer uses the inotify interface for refcounting
instances of FEX.
The inotify interface fails to send close events when an application
crashes. Which is either an API oversight or intentional choice.
Now to use FEXMountDaemon the FEX process must send the daemon a pipe
fd.
The FEXMountDaemon then uses the write end of the pipe to determine if
the read end of the pipe is still open. It does this using the epoll API
and ref counting how many pipes are still active.
This is possible since epoll will tell us if pipe status has changed to
error. Signalling to the write end that the read end has closed for
whatever reason.
Now we only use the "lock" file to remove races and tell the new
instances of FEX where the rootfs is mounted
Due to how we emulate the guest signal handlers, we do the state setup
in the real host signal handler, then we jump out after state setup.
This was causing a situation where we were setting up the guest signal
handler state with the correct sa_mask.
Then after setting up the guest state we would leave the FEX signal
handler, restoring the signal mask to our original mask.
Instead now as we are setting up the guest state, we save our host
signal mask. Then on signal handler return we modify our host signal
mask to match what the guest wants.
Once we hit our sigreturn emulation we then restore the original signal
mask.
This looks to improve some stability problems regarding how wine uses
signals but it still doesn't fix the gvisor test sadly.
Now that we deparent FEXMountDaemon we can no longer use
PR_SET_PDEATHSIG.
Instead we rely on the ref counting and checking the pipe status to see
if the original parent has left us.
Further improvements that could be done in the future is that every user
of the mount point talks to the daemon to give it a pipe to check is
still live, since the ref counting sometimes is incorrect.
This flag is ignored with sigaltstack.
Fixes an early assert in:
- Splice
- No Time to Explain Remastered
- Ittledew
- Hyperdrive Massacre
- English Country Tune
This allows FEXMountDaemon to remove FEXInterpreter as its parent.
Instead becoming the parent of whatever the current reaper process is.
Do it as early as possible this way FEXInterpreter won't get an
erroneous SIGCHLD.
Ryan Houdek