I've recently been playing a lot with architecture emulation containers using qemu, mainly so I can build and test the arm secure boot toolchain on my x86 laptop (not having any arm server hardware). The process for bringing up architecture emulation containers using qemu-user is very cumbersome because the emulation has to be installed within the container. This is bad for several reasons, firstly because it contaminates the container image to have an emulator sitting inside it. Secondly it means that all orchestration systems have to be explicitly modified to work with non-native architectures and thirdly it means that the consumer of the container can accidentally destroy the emulation and thus permanently crash the container. The fix for this is to add a mode to binfmt_misc where the emulation can be permanently installed from the current mount namespace and where it survives both chroot and changes of mount namespace, effectively allowing the container to run using the emulator, but where the emulator itself isn't present within the container. There are a couple of downsides to this, firstly the mapping of the interpreter is accessible inside the container even if the actual file isn't (I don't think this is really a security problem) and secondly, to update the emulator package, you now have to remove the emulation update and reinstall it, but this should be easy to do with packaging scripts. Finally, the emulator must be static otherwise the container would crash when the elf binary format attempted to run the elf interpreter. I'm not really a regular FS developer, so I'd appreciate FS people taking a look at the new filp_clone_open() API and whether I got everything correct. Thanks, James --- James Bottomley (2): fs: add filp_clone_open API binfmt_misc: add persistent opened binary handler for containers fs/binfmt_misc.c | 42 ++++++++++++++++++++++++++++++++++++++++-- fs/internal.h | 1 + fs/open.c | 20 ++++++++++++++++++++ 3 files changed, 61 insertions(+), 2 deletions(-) -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
