On 13.11.23 19:29, Eric W. Biederman wrote:
"Guilherme G. Piccoli" <gpiccoli@xxxxxxxxxx> writes:
On 09/10/2023 14:37, Kees Cook wrote:
On Fri, Oct 06, 2023 at 02:07:16PM +0200, David Hildenbrand wrote:
On 07.09.23 22:24, Guilherme G. Piccoli wrote:
Currently the kernel provides a symlink to the executable binary, in the
form of procfs file exe_file (/proc/self/exe_file for example). But what
happens in interpreted scenarios (like binfmt_misc) is that such link
always points to the *interpreter*. For cases of Linux binary emulators,
like FEX [0] for example, it's then necessary to somehow mask that and
emulate the true binary path.
I'm absolutely no expert on that, but I'm wondering if, instead of modifying
exe_file and adding an interpreter file, you'd want to leave exe_file alone
and instead provide an easier way to obtain the interpreted file.
Can you maybe describe why modifying exe_file is desired (about which
consumers are we worrying? ) and what exactly FEX does to handle that (how
does it mask that?).
So a bit more background on the challenges without this change would be
appreciated.
Yeah, it sounds like you're dealing with a process that examines
/proc/self/exe_file for itself only to find the binfmt_misc interpreter
when it was run via binfmt_misc?
What actually breaks? Or rather, why does the process to examine
exe_file? I'm just trying to see if there are other solutions here that
would avoid creating an ambiguous interface...
Thanks Kees and David! Did Ryan's thorough comment addressed your
questions? Do you have any take on the TODOs?
I can maybe rebase against 6.7-rc1 and resubmit , if that makes sense!
But would be better having the TODOs addressed, I guess.
Currently there is a mechanism in the kernel for changing
/proc/self/exe. Would that be reasonable to use in this case?
It came from the checkpoint/restart work, but given that it is already
implemented it seems like the path of least resistance to get your
binfmt_misc that wants to look like binfmt_elf to use that mechanism.
I had that in mind as well, but
prctl_set_mm_exe_file()->replace_mm_exe_file() fails if the executable
is still mmaped (due to denywrite handling); that should be the case for
the emulator I strongly assume.
--
Cheers,
David / dhildenb
