1 files changed, 51 insertions, 0 deletions
diff --git a/results/classifier/118/none/1222 b/results/classifier/118/none/1222
new file mode 100644
index 000000000..d0684bc8e
--- /dev/null
+++ b/results/classifier/118/none/1222
@@ -0,0 +1,51 @@
+semantic: 0.711
+permissions: 0.705
+performance: 0.671
+socket: 0.645
+kernel: 0.639
+ppc: 0.634
+network: 0.629
+user-level: 0.628
+device: 0.627
+architecture: 0.600
+peripherals: 0.588
+register: 0.585
+hypervisor: 0.570
+files: 0.565
+mistranslation: 0.505
+risc-v: 0.498
+graphic: 0.497
+vnc: 0.490
+PID: 0.488
+i386: 0.455
+x86: 0.451
+VMM: 0.447
+arm: 0.424
+KVM: 0.416
+debug: 0.409
+TCG: 0.399
+boot: 0.387
+virtual: 0.383
+assembly: 0.239
+
+/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.