blob: 72cd513eea21be035757795b1f42b37a6057a5ab (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
/proc/self/exe not handled in execve
Description of problem:
I am submitting this issue to track an issue for which it seems there have been a couple of patchsets (unsuccessfully) submitted. I am not able to give a detailed analysis of the problem as I am not aware of exactly what the issue is - I am raising this issue to attempt to bring one of these changes upstream as it seems there is a genuine bug here (hence multiple attempts to fix) but no tracking bug or attention. It's also causing my project to require a custom fork of qemu just for this.
My (laymans) understanding of the bug is that golang can escape the emulation environment when it execs something to do with `execve /proc/self/exe`. Here is an excerpt from my internal docs from someone who has left the project, sorry I cannot be of more use...
> Unfortunately, to run podman/buildah/skopeo using qemu-user (which just runs a single binary
> emulated, as opposed to qemu-system which runs an entire system but is harder to automate in
> toolchains) we need these patches because of a peculiar thing many golang applications do. They
> re-execute themselves using the execve syscall using /proc/self/exe as the executable. In
> non-emulated contexts this is fine, but in emulated contexts /proc/self/exe is actually the
> top-level emulator process and _not_ podman/buildah/skopeo. This causes all container storage
> operations to mysteriously fail, because the wrong binary is being executed. This issue was quite
> difficult to root cause.
Additional information:
Old patchsets that seem to be trying to fix this:
- http://next.patchew.org/QEMU/20210531055019.10149-1-yamamoto@midokura.com/20210531055019.10149-2-yamamoto@midokura.com/
- https://patchew.org/QEMU/20190916155545.29928-1-olivier.dion@polymtl.ca/
- https://patchew.org/QEMU/20190807135458.32440-1-dion@linutronix.de/
It seems that this github issue: https://github.com/golang/go/issues/42080 references the same issue.
|