[Bug 297426] linuxulator: linprocfs /proc/self/exe host path breaks execve under Linux ABI
| Newsgroups | gmane.os.freebsd.bugs |
|---|---|
| Message-ID | <[email protected]/bugzilla/> |
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=297426
Bug ID: 297426
Summary: linuxulator: linprocfs /proc/self/exe host path breaks
execve under Linux ABI
Product: Base System
Version: 16.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: [email protected]
Reporter: [email protected]
Observed behavior
-----------------
Linux programs that re-execute themselves via /proc/self/exe fail under
the Linuxulator even though the same binary runs when invoked by its
real path.
A minimal check (Linux python under linux_base-rl9):
readlink(/proc/self/exe) succeeds and returns a path
stat(/proc/self/exe) fails with ENOENT
access(/proc/self/exe, X) fails
execve(/proc/self/exe) fails with ENOENT
execve(<same binary by its normal path>) succeeds
Chromium-family browsers under the Linuxulator (for example
www/linux-brave) hit this immediately: helper processes are started with
execvp("/proc/self/exe"), which fails with:
LaunchProcess: failed to execvp:
/proc/self/exe
The GPU process then exits (status 32512), and the browser aborts
(SIGTRAP / "GPU process isn't usable"). Sites and DRM are beside the
point; the process cannot spawn helpers at all. Native FreeBSD
www/chromium is not this bug.
Mechanism
---------
linprocfs exposes /proc/<pid>/exe as a symlink. The fill routine uses
proc_get_binpath(), which returns a FreeBSD host path. For a binary
installed under the emulator root that looks like:
/compat/linux/usr/bin/python3.9
Linux ABI absolute lookups start at compat.linux.emul_path (default
/compat/linux). Following the symlink therefore searches for:
/compat/linux/compat/linux/usr/bin/python3.9
which does not exist -- hence ENOENT on stat/access/execve of
/proc/self/exe, while execve of the Linux-visible path
(/usr/bin/python3.9) works.
On Linux, /proc/self/exe readlink returns a path already meaningful
inside that namespace (e.g. /usr/bin/python3.9), so follow/exec succeed.
Proposed direction
------------------
Patch forthcoming on Phabricator: when filling the linprocfs exe
symlink, report a Linux-visible path (strip the emul_path prefix when
present) so readlink, namei follow, and execve of /proc/self/exe behave
as on Linux. Native FreeBSD procfs should keep reporting the host path
for FreeBSD processes.
--
You are receiving this mail because:
You are the assignee for the bug.