On Tue, 12 May 2020 16:32:35 +0300 Michael Tokarev <[email protected]> wrote: > 12.05.2020 16:14, L3P3 wrote: > > I used auditd to log all executions. > > The commands I catched are these, the first one being the initial one. > > /usr/bin/qemu-x86_64-static /usr/share/code/bin/../code > > /usr/share/code/bin/../resources/app/out/cli.js --verbose > > -> /usr/bin/qemu-x86_64-static /usr/share/code/code --verbose --no-sandbox > > -> /usr/bin/qemu-x86_64-static /usr/share/code/code --type=zygote --no-sandbox > > Okay. > > > These commands are run successfully. Note the --type=zygote thing on > > the last one. Since we get the qemu error that type=gpu-process is not > > supported, it is weird, that type=zygote is properly executed. In the > > Nope, your interpretation here is not correct. qemu-user does not interpret > options after the first non-optional argument, this has always been the > case, it stops at /usr/share/code/code and does not look further. This > is unlike most other GNU utilitites who interprets --options after > non-option arguments. For qemu-user the only problem is when the _first_ > argument starts with a minus sign, - should it be qemu-user's option or the > executable name?
I found out the reason! code, like all electron (chromium) apps, calls /proc/self/exec to start its integrated gpu process. The other subprocesses like zygote get called by the actual path of the electron binary. In qemu, for some weird reason, this link points to the qemu binary instead of the target binary. There are actually some other target apps that fail due to that violation. A workaround would be to just not use /proc/self/exec but in my opinion it is a qemu-user bug since it is violating the principle of transparency. L3P3
