In the case that multiple messages appearing in a single packet then we
were repeating the first message and dropping any subsequent messages.
Fixes#1496
Before doing anything that requires curl, actually check if it is
installed.
Then instruct the user to install curl before using.
Doesn't try installing curl itself since we don't have a clean way to
execute sudo from potentially GUI.
Fixes#1498
If the user passes in an absolute path then check to see if it exists in
the rootfs before executing.
Useful for launching applications directly out of the rootfs with
FEXInterpreter.
In the case that the absolute path doesn't exist in the rootfs then
fallback to the host system as usual
Some syscalls support `AT_SYMLINK_NOFOLLOW` In these instances we need
to follow the symlink on a couple of syscalls.
Fixes executing wine using the basic wine path
eg:
FEXBash "wine dxcapsviewer.exe"
Due to the way this syscall handles siginfo_t, we only need to shift
data through the padding.
This is due to the syscall not allowing you to send siginfo_t with
si_code being positive. Which is what the kernel uses to interpret the
data if it is reinterpreting it.
I thought this was incorrect but since it only supports IPC_64 it is
actually correct.
If a 32-bit application wants to use the old encoding then it needs to
use the ipc syscall instead.
Fixes#1253
In the case of having a stale lock file on the system, usually due to an
unclean shutdown, have FEX retry if the socket for that lock file is
also not available.
This resolves the exact case of:
```
FEXBash xeyes &
kill -9 `pidof FEXMountDaemon`
sudo shutdown -r now
FEXBash xeyes & <--- This command would now fail
```
The first command would do:
- Check lock file and socket
- Spin up FEXMountDaemon
- Create Lock file and Socket file
- Start executing XEyes in FEXInterpreter
The second command would do:
- Kills the FEXMountDaemon process
- This leaves squashfuse running
- The lock file and socket file are now unmanaged and just files on the filesystem
The third command would do:
- unmounts the squashfuse mount
- Leaving a dangling folder as a mount point
The fourth command would do:
- Check for lock file and socket
- Attempt to use lock file, socket, and mount that is dangling
- Fail with error
Now instead fourth command will do:
- Check for lock file and socket
- Check if filesystem is valid
- Knows that lock file exists but socket isn't active at all
- Deletes lock file
- Spin up FEXMountDaemon
- Create Lock File and Socket File
- Start executing XEyes in FEXInterpreter
The main one that we can't implement is readdir. Falls in to the same
problem space as getdents.
With this, we have the full entry tables filled out for both 64-bit and
32-bit. With some holes in the implementation, we have almost all
coverage now.
Adds a header only include utility folder that can be included from
everywhere.
Contains syscall helpers for older glibc and defines for older Linux
uapi headers missing some defines.
This tool supports both a zenity and tty interface.
TTY will be presented if available while Zenity will be used otherwise.
This tool pulls a rootfs list from https://rootfs.fex-emu.org/
It then allows you to select a rootfs from the list, download it, place
it in to the correct working folder, extract it if desired, and set it
as the current default RootFS.
This requires curl and potentially zenity installed to use.
Maybe also unsquashfs if the user chooses to extract the image.
This is an all in one tool to quickly get a new user up and running.
Additionally if you pass in a file path in to the tool, it will generate
an xxhash of the file and exit out. This is the hash used to ensure the
files are valid.
We were dereferencing the shmun ptr instead of using it directly.
Resulting in an almost immediate crash
Additionally IPC_SET doesn't write back to the shmid_ds provided.
Additional still SHM_STATE/SHM_STAT_ANY/IPC_STAT wasn't writing its
result back to the guest. Resulting in invalid stat information for the
guest.
Additionally SHM_INFO doesn't follow IPC64 behaviour since there is no
shm_info 64-bit type for a 32-bit OS.
The kernel just truncates the results in this case. Could be an
oversight on the kernel dev's side?
Fixes#1252
Syscalls on x86-64 have a gap in the range of [335, 424) where these are
defined as returning ENOSYS.
This was a decision that the Linux developers decided on so x86-64 can
realign its syscall numbers to a common infrastructure.
Turns out that Proton Experimental was using a 32-bit only syscall to
check if the feature existed and was listening for ENOSYS.
They did this unconditionally on both x86 and x86-64 and it hits this
gap section.
This was introduced in Proton Experimental with commit
563fb0fbe2a49734aede87bedccb20daefc553b0
Message: "ntdll: Use clock_gettime64 if supported."
This is technically valid since it falls within this gap section but
leaves a bad taste.
We can safely ignore this section so set it up with the
UnimplementedSyscallSafe handler and also assign it to Syscall MAX so it
can go down our fast handler.
Not that this is likely to be a performance critical path.
Fixes Proton Experimental crashing when run under FEX.
On FEXMountDaemon startup, fetch the FD limit and current number of open
files. This allows us to track the number of open FDs we have.
Once we get close the the safe threshold we then try increasing the soft
limit towards the hard limit. If we bump up to the max (Say someone
setting the hard limit to 256) then print some fairly big warning
messages.
With the previously fixed FD leak, we could very quickly hit the pipe
limit because Steam is constantly opening new processes all the time.
With the leak fixed, running Steam and idling, FEXMountDaemon only has
around 16 pipes being watched.
This is another edge case where if the process was sent a SIGTERM then
it can get in to a weird state where pipe tracking is broken.
We already check for zero pipes being tracked at the end of this loop,
just check for the shutdown variable to be set instead
Even though we were removing the pipe from the epoll interest list,
we were failing to close the pipe fd. This was leaking the FD and
running in to the Linux process FD limitation over time.
This fixes a class of issues where if you were running FEXMountDaemon
that hit the max, then there were FEX processes not being watched. Which
means that FEXMountDaemon could exit while FEX was still trying to run.
Usually a non-issue since squashfuse would keep running in the
background since open files in the mount were still in use.
Could hit fun race conditions because of it though.
On an overburdened system then FEXMountDaemon may notrespond within the two
seconds of FEX waiting for an ack.
In this case then we hit a bad edge case where we overwrite the lock
file with a new FEXMountDaemon instance then spin up a new
FEXMountDaemon.
This new FEXMountDaemon will recognize that one is still running and
early exit, but now that we've overwritten the lock file with a new
location, all future FEX instances won't be able to find the squashfs
rootfs.
Instead, ignore that the ack wasn't received and attempt running
instead.
FEXMountDaemon should still pick up the pipe message and monitor FEX
regardless.
This fixes the `/usr not found` messages and crashes resulting from it.
Each section map invocation was clearing the sections pointer, meaning
we only ever had one section in the vector.
We want to keep all of the sections around from the ELFCodeLoader.
Fixes a bug where we were effectively never catching any code segments
from the executable passed in.
Splits out the few required dependencies to a FEXCore_Base static
library.
FEXCore then links to this directly.
Then make it so the FEX Common code links to FEXCore_Base so the
jemalloc dependency doesn't get pulled in.
Had some idle time so I implemented this logic.
We do some tricky logic to have a big.little configuration even with
unknown CPU core types. Promoting or demoting a single MIDR depending on
if we have a mixed configuration or not.
In a non-hybrid design we only claim product names inside the CPUID
product string.
This will appear if you `/proc/cpuinfo` or read the CPUID registers
directly
eg on Snapdragon 888:
processor : 0
model name : FEX-2112-1-g13b14b85 Cortex-A55
processor : 1
model name : FEX-2112-1-g13b14b85 Cortex-A55
processor : 2
model name : FEX-2112-1-g13b14b85 Cortex-A55
processor : 3
model name : FEX-2112-1-g13b14b85 Cortex-A55
processor : 4
model name : FEX-2112-1-g13b14b85 Cortex-A78
processor : 5
model name : FEX-2112-1-g13b14b85 Cortex-A78
processor : 6
model name : FEX-2112-1-g13b14b85 Cortex-A78
processor : 7
model name : FEX-2112-1-g13b14b85 Cortex-X1
eg on Macbook Pro VM which can't see the CPU type:
processor : 0
model name : FEX-2112-1-g13b14b85 Unknown ARM CPU
processor : 1
model name : FEX-2112-1-g13b14b85 Unknown ARM CPU
processor : 2
model name : FEX-2112-1-g13b14b85 Unknown ARM CPU
processor : 3
model name : FEX-2112-1-g13b14b85 Unknown ARM CPU
processor : 4
model name : FEX-2112-1-g13b14b85 Unknown ARM CPU
processor : 5
model name : FEX-2112-1-g13b14b85 Unknown ARM CPU
processor : 6
model name : FEX-2112-1-g13b14b85 Unknown ARM CPU
processor : 7
model name : FEX-2112-1-g13b14b85 Unknown ARM CPU
.at(0) can blow up in the case we receive a message from user code with msg_iovlen=0
.data() will simply return a pointer to the empty buffer and we can
proceed with forwarding the call to the syscall.
Ryan Houdek