Find a way to support /proc/self/exe in a cleaner way
This is a byproduct of how binfmt_misc works and it seems like an oversight of the Linux kernel.

First, in a regular environment.
The Linux kernel loads the ELF.
If it is a static ELF, it can skip loading the interpreter.
If it is a dynamic ELF then it loads the interpreter and executes that.
At the end of the execution, `/proc/self/exe` points to the initial ELF execve, regardless of interpreter.

In the case of binfmt_misc, the interpreter is the binfmt_misc ELF.
In this case `/proc/self/exe` is set to the binfmt_misc interpreter rather than the initial ELF passed to execve.

**Kernel workaround?**
Seems like an oversight that the kernel doesn't set this up correctly.
in `fs/exec.c` the kernel sets the exe file with `set_mm_exe_file(bprm->mm, bprm->file);`
A kernel workaround would likely be at the end of that function there is a `if (bprm->have_execfd)` then the kernel can do a `set_mm_exe_file(bprm->mm, bprm->execfd);`

In the userspace there is currently only two ways to set this file.
1) `prctl(PR_SET_MM, PR_SET_MM_EXE_FILE, fd, 0, 0);`
The problem with this approach is that this requires the CAP_SYS_RESOURCE feature. Which gives permission to a lot of things.
Additionally we must unmap the original exe before setting the new exe file. The kernel checks the exe mapping to ensure it is completely unmapped. This is a bit of a pain since it breaks execution back through libc shutdown. 
2) `prctl(PR_SET_MM, PR_SET_MM_MAP, ...);`
This requires the loader application to setup a checkpoint/restore namespace. Which isn't always available anyway.
Same unmapping problem as the other prctl