On 2/13/21 11:58 PM, Michael Tokarev wrote:
I can think of another hack. Qemu-user binary may look at its
name and if it sees some magic prefix (eg, qemu-foo-binfmt-trigger),
it will assume it is run from within the binfmt subsystem with
the P flag in effect. Yes it is hacky, but it *might* work.
Actually this is something I like. Yes it is hackish but it works.
So I implemented this, using /usr/libexec/qemu-binfmt/foo-binfmt-P
symlinks to ../../bin/qemu-foo[-static], and detecting "-binfmt-P"
prefix in qemu-user/main.c.
It's not fully clear to me yet, how this solves all problems,
so I'm really looking forward to your patches!
For usage with buildd chroots, what will then be written to
/proc/sys/fs/binfmt_misc/* ?
Currently I see:
interpreter /usr/bin/qemu-foo-static
flags OCF
With your idea, it seems you will then need to drop the "F" flag (which means
you basically revert fix-binary binfmt-misc flag and #868030) ?
If so, you will then need to have the "foo-binfmt-P" symlink and qemu-foo-static
inside the chroots too (which mostly prevents usage of non-static qemu-foo
binaries).
I've picked up Laurents kernel patch:
https://patchwork.kernel.org/project/linux-fsdevel/patch/[email protected]/
into my parisc kernel git tree for inclusion into kernel v5.12 (if nobody
objects this happens next week or the week after).
But in case we now have a viable other solution I prefer to drop it again.
Or this your approach too hackish or has other downsides (like loosing F flags),
so that we generally still prefer an "clean" kernel patch as proposed by
Laurent?
Helge
