All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
To: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	linux-fsdevel
	<linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Cc: Jan Kara <jack-AlSwsSmVLrQ@public.gmane.org>,
	Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
Subject: [Patch v3 0/3] allow the creation of architecture emulation containers where the emulator binary is outside the container
Date: Thu, 31 Mar 2016 07:54:06 -0700	[thread overview]
Message-ID: <1459436046.2958.21.camel@HansenPartnership.com> (raw)

Changes in v3:
 * Collected acks from Jan Kara and Serge Hallyn
 * Fixed doc spelling errors
 * fput -> put_filp in error path

Changes in v2:

 * Use oldfile f_creds for the vfs_open credentials in
   filp_clone_open()
 * remove spurious fput() after filp_close()
 * Add documentation for the F option

There's also now a git tree at

https://git.kernel.org/cgit/linux/kernel/git/jejb/binfmt_misc.git

Original cover letter:

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 (3):
  fs: add filp_clone_open API
  binfmt_misc: add persistent opened binary handler for containers
  binfmt_misc: add F option description to documentation

 Documentation/binfmt_misc.txt |  7 +++++++
 fs/binfmt_misc.c              | 41 +++++++++++++++++++++++++++++++++++++++--
 fs/internal.h                 |  1 +
 fs/open.c                     | 20 ++++++++++++++++++++
 4 files changed, 67 insertions(+), 2 deletions(-)

WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: containers@lists.linux-foundation.org,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Cc: Al Viro <viro@ZenIV.linux.org.uk>, Jan Kara <jack@suse.cz>
Subject: [Patch v3 0/3] allow the creation of architecture emulation containers where the emulator binary is outside the container
Date: Thu, 31 Mar 2016 07:54:06 -0700	[thread overview]
Message-ID: <1459436046.2958.21.camel@HansenPartnership.com> (raw)

Changes in v3:
 * Collected acks from Jan Kara and Serge Hallyn
 * Fixed doc spelling errors
 * fput -> put_filp in error path

Changes in v2:

 * Use oldfile f_creds for the vfs_open credentials in
   filp_clone_open()
 * remove spurious fput() after filp_close()
 * Add documentation for the F option

There's also now a git tree at

https://git.kernel.org/cgit/linux/kernel/git/jejb/binfmt_misc.git

Original cover letter:

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 (3):
  fs: add filp_clone_open API
  binfmt_misc: add persistent opened binary handler for containers
  binfmt_misc: add F option description to documentation

 Documentation/binfmt_misc.txt |  7 +++++++
 fs/binfmt_misc.c              | 41 +++++++++++++++++++++++++++++++++++++++--
 fs/internal.h                 |  1 +
 fs/open.c                     | 20 ++++++++++++++++++++
 4 files changed, 67 insertions(+), 2 deletions(-)



             reply	other threads:[~2016-03-31 14:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-31 14:54 James Bottomley [this message]
2016-03-31 14:54 ` [Patch v3 0/3] allow the creation of architecture emulation containers where the emulator binary is outside the container James Bottomley
     [not found] ` <1459436046.2958.21.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2016-03-31 14:55   ` [Patch v3 1/3] fs: add filp_clone_open API James Bottomley
2016-03-31 14:55     ` James Bottomley
2016-03-31 14:56   ` [Patch v3 2/3] binfmt_misc: add persistent opened binary handler for containers James Bottomley
2016-03-31 14:56     ` James Bottomley
     [not found]     ` <1459436179.2958.23.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2016-04-13 21:02       ` Matthew Helsley
     [not found]         ` <CA+RrjuV3VOjLRMm_bnk-9CKF_3NqX6DVNBgAUVpxW0+NE0bLHg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-04-14 22:33           ` johnny frazier
2016-03-31 14:57   ` [Patch v3 3/3] binfmt_misc: add F option description to documentation James Bottomley
2016-03-31 14:57     ` James Bottomley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1459436046.2958.21.camel@HansenPartnership.com \
    --to=james.bottomley-d9phhud1jfjcxq6kfmz53/egyhegw8jk@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=jack-AlSwsSmVLrQ@public.gmane.org \
    --cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.