Skip to contentSkip to conversation

allow the creation of architecture emulation containers where the emulator binary is outside the container

PATCH RESEND In review James Bottomley 3 participants 9 messages Apr 19, 2016 2 messages not in the archive

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

v3 cover allow the creation of architecture emulation containers where the emulator binary is outside the container

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(-)

A message that is not in the archive (sent off-list or not yet received): 1461068670.2435.0.camel-d9PhHud1JfjCXq6kfMZ53/[email protected]

#2 lore raw

PATCH RESEND v3 1/3 fs: add filp_clone_open API

I need an API that allows me to obtain a clone of the current file pointer to pass in to an exec handler. I've labelled this as an internal API because I can't see how it would be useful outside of the fs subsystem. The use case will be a persistent binfmt_misc handler.

---
 fs/internal.h |  1 +
 fs/open.c     | 20 ++++++++++++++++++++
 2 files changed, 21 insertions(+)
fs/internal.h +1 -0
index b71deee..c8ca0c9 100644
@@ -108,6 +108,7 @@ extern long do_handle_open(int mountdirfd,
 			   struct file_handle __user *ufh, int open_flag);
 extern int open_check_o_direct(struct file *f);
 extern int vfs_open(const struct path *, struct file *, const struct cred *);
+extern struct file *filp_clone_open(struct file *);
 
 /*
  * inode.c
fs/open.c +20 -0
index 17cb6b1..bfe6f2b 100644
@@ -1002,6 +1002,26 @@ struct file *file_open_root(struct dentry *dentry, struct vfsmount *mnt,
 }
 EXPORT_SYMBOL(file_open_root);
 
+struct file *filp_clone_open(struct file *oldfile)
+{
+	struct file *file;
+	int retval;
+
+	file = get_empty_filp();
+	if (IS_ERR(file))
+		return file;
+
+	file->f_flags = oldfile->f_flags;
+	retval = vfs_open(&oldfile->f_path, file, oldfile->f_cred);
+	if (retval) {
+		put_filp(file);
+		return ERR_PTR(retval);
+	}
+
+	return file;
+}
+EXPORT_SYMBOL(filp_clone_open);
+
 long do_sys_open(int dfd, const char __user *filename, int flags, umode_t mode)
 {
 	struct open_flags op;
Signature · 1 line
2.6.6
#3 lore raw

PATCH RESEND v3 3/3 binfmt_misc: add F option description to documentation

In reply to a message not in the archive
---
 Documentation/binfmt_misc.txt | 7 +++++++
 1 file changed, 7 insertions(+)
Documentation/binfmt_misc.txt +7 -0
index 6b1de70..ec83bbc 100644
@@ -66,6 +66,13 @@ Here is what the fields mean:
             This feature should be used with care as the interpreter
             will run with root permissions when a setuid binary owned by root
             is run with binfmt_misc.
+      'F' - fix binary.  The usual behaviour of binfmt_misc is to spawn the
+      	    binary lazily when the misc format file is invoked.  However,
+	    this doesn't work very well in the face of mount namespaces and
+	    changeroots, so the F mode opens the binary as soon as the
+	    emulation is installed and uses the opened image to spawn the
+	    emulator, meaning it is always available once installed,
+	    regardless of how the environment changes.
 
 
 There are some restrictions:
Signature · 1 line
2.6.6
#4 lore raw

PATCH RESEND v3 1/3 fs: add filp_clone_open API

In reply to James Bottomley

I need an API that allows me to obtain a clone of the current file pointer to pass in to an exec handler. I've labelled this as an internal API because I can't see how it would be useful outside of the fs subsystem. The use case will be a persistent binfmt_misc handler.

---
 fs/internal.h |  1 +
 fs/open.c     | 20 ++++++++++++++++++++
 2 files changed, 21 insertions(+)
fs/internal.h +1 -0
index b71deee..c8ca0c9 100644
@@ -108,6 +108,7 @@ extern long do_handle_open(int mountdirfd,
 			   struct file_handle __user *ufh, int open_flag);
 extern int open_check_o_direct(struct file *f);
 extern int vfs_open(const struct path *, struct file *, const struct cred *);
+extern struct file *filp_clone_open(struct file *);
 
 /*
  * inode.c
fs/open.c +20 -0
index 17cb6b1..bfe6f2b 100644
@@ -1002,6 +1002,26 @@ struct file *file_open_root(struct dentry *dentry, struct vfsmount *mnt,
 }
 EXPORT_SYMBOL(file_open_root);
 
+struct file *filp_clone_open(struct file *oldfile)
+{
+	struct file *file;
+	int retval;
+
+	file = get_empty_filp();
+	if (IS_ERR(file))
+		return file;
+
+	file->f_flags = oldfile->f_flags;
+	retval = vfs_open(&oldfile->f_path, file, oldfile->f_cred);
+	if (retval) {
+		put_filp(file);
+		return ERR_PTR(retval);
+	}
+
+	return file;
+}
+EXPORT_SYMBOL(filp_clone_open);
+
 long do_sys_open(int dfd, const char __user *filename, int flags, umode_t mode)
 {
 	struct open_flags op;
Signature · 1 line
2.6.6
#5 lore raw

PATCH RESEND v3 2/3 binfmt_misc: add persistent opened binary handler for containers

In reply to James Bottomley

From a119fa7e0d4eb96a6290eb63a5bd597f5844fab4 Mon Sep 17 00:00:00 2001
From: James Bottomley <James.Bottomley-d9PhHud1JfjCXq6kfMZ53/[email protected]>
Date: Wed, 17 Feb 2016 16:51:16 -0800
Subject: [PATCH 2/3] binfmt_misc: add persistent opened binary handler for
containers

This patch adds a new flag 'F' to the binfmt handlers. If you pass in 'F' the binary that runs the emulation will be opened immediately and in future, will be cloned from the open file.

The net effect is that the handler survives both changeroots and mount namespace changes, making it easy to work with foreign architecture containers without contaminating the container image with the emulator.

---
 fs/binfmt_misc.c | 41 +++++++++++++++++++++++++++++++++++++++--
 1 file changed, 39 insertions(+), 2 deletions(-)
fs/binfmt_misc.c +39 -2
index 3a3ced7..8a108c4 100644
@@ -26,6 +26,8 @@
 #include <linux/fs.h>
 #include <linux/uaccess.h>
 
+#include "internal.h"
+
 #ifdef DEBUG
 # define USE_DEBUG 1
 #else
@@ -43,6 +45,7 @@ enum {Enabled, Magic};
 #define MISC_FMT_PRESERVE_ARGV0 (1 << 31)
 #define MISC_FMT_OPEN_BINARY (1 << 30)
 #define MISC_FMT_CREDENTIALS (1 << 29)
+#define MISC_FMT_OPEN_FILE (1 << 28)
 
 typedef struct {
 	struct list_head list;
@@ -54,6 +57,7 @@ typedef struct {
 	char *interpreter;		/* filename of interpreter */
 	char *name;
 	struct dentry *dentry;
+	struct file *interp_file;
 } Node;
 
 static DEFINE_RWLOCK(entries_lock);
@@ -201,7 +205,13 @@ static int load_misc_binary(struct linux_binprm *bprm)
 	if (retval < 0)
 		goto error;
 
-	interp_file = open_exec(iname);
+	if (fmt->flags & MISC_FMT_OPEN_FILE && fmt->interp_file) {
+		interp_file = filp_clone_open(fmt->interp_file);
+		if (!IS_ERR(interp_file))
+			deny_write_access(interp_file);
+	} else {
+		interp_file = open_exec(iname);
+	}
 	retval = PTR_ERR(interp_file);
 	if (IS_ERR(interp_file))
 		goto error;
@@ -285,6 +295,11 @@ static char *check_special_flags(char *sfs, Node *e)
 			e->flags |= (MISC_FMT_CREDENTIALS |
 					MISC_FMT_OPEN_BINARY);
 			break;
+		case 'F':
+			pr_debug("register: flag: F: open interpreter file now\n");
+			p++;
+			e->flags |= MISC_FMT_OPEN_FILE;
+			break;
 		default:
 			cont = 0;
 		}
@@ -543,6 +558,8 @@ static void entry_status(Node *e, char *page)
 		*dp++ = 'O';
 	if (e->flags & MISC_FMT_CREDENTIALS)
 		*dp++ = 'C';
+	if (e->flags & MISC_FMT_OPEN_FILE)
+		*dp++ = 'F';
 	*dp++ = '\n';
 
 	if (!test_bit(Magic, &e->flags)) {
@@ -590,6 +607,11 @@ static void kill_node(Node *e)
 	}
 	write_unlock(&entries_lock);
 
+	if ((e->flags & MISC_FMT_OPEN_FILE) && e->interp_file) {
+		filp_close(e->interp_file, NULL);
+		e->interp_file = NULL;
+	}
+
 	if (dentry) {
 		drop_nlink(d_inode(dentry));
 		d_drop(dentry);
@@ -698,6 +720,21 @@ static ssize_t bm_register_write(struct file *file, const char __user *buffer,
 		goto out2;
 	}
 
+	if (e->flags & MISC_FMT_OPEN_FILE) {
+		struct file *f;
+
+		f = open_exec(e->interpreter);
+		if (IS_ERR(f)) {
+			err = PTR_ERR(f);
+			pr_notice("register: failed to install interpreter file %s\n", e->interpreter);
+			simple_release_fs(&bm_mnt, &entry_count);
+			iput(inode);
+			inode = NULL;
+			goto out2;
+		}
+		e->interp_file = f;
+	}
+
 	e->dentry = dget(dentry);
 	inode->i_private = e;
 	inode->i_fop = &bm_entry_operations;
@@ -716,7 +753,7 @@ out:
 
 	if (err) {
 		kfree(e);
-		return -EINVAL;
+		return err;
 	}
 	return count;
 }
Signature · 1 line
2.6.6
#6 lore raw

PATCH RESEND v3 3/3 binfmt_misc: add F option description to documentation

In reply to James Bottomley
---
 Documentation/binfmt_misc.txt | 7 +++++++
 1 file changed, 7 insertions(+)
Documentation/binfmt_misc.txt +7 -0
index 6b1de70..ec83bbc 100644
@@ -66,6 +66,13 @@ Here is what the fields mean:
             This feature should be used with care as the interpreter
             will run with root permissions when a setuid binary owned by root
             is run with binfmt_misc.
+      'F' - fix binary.  The usual behaviour of binfmt_misc is to spawn the
+      	    binary lazily when the misc format file is invoked.  However,
+	    this doesn't work very well in the face of mount namespaces and
+	    changeroots, so the F mode opens the binary as soon as the
+	    emulation is installed and uses the opened image to spawn the
+	    emulator, meaning it is always available once installed,
+	    regardless of how the environment changes.
 
 
 There are some restrictions:
Signature · 1 line
2.6.6
Acked-by Serge Hallyn on v3 3/3
#7 lore raw

Re: [Patch resend v3 3/3] binfmt_misc: add F option description to documentation

Quoted 1 line · James Bottomley

Thanks, James. Which tree were you thinking this would go in through?

Quoted 29 lines
---
 Documentation/binfmt_misc.txt | 7 +++++++
 1 file changed, 7 insertions(+)
Documentation/binfmt_misc.txt +7 -0
index 6b1de70..ec83bbc 100644
@@ -66,6 +66,13 @@ Here is what the fields mean:
             This feature should be used with care as the interpreter
             will run with root permissions when a setuid binary owned by root
             is run with binfmt_misc.
+      'F' - fix binary.  The usual behaviour of binfmt_misc is to spawn the
+      	    binary lazily when the misc format file is invoked.  However,
+	    this doesn't work very well in the face of mount namespaces and
+	    changeroots, so the F mode opens the binary as soon as the
+	    emulation is installed and uses the opened image to spawn the
+	    emulator, meaning it is always available once installed,
+	    regardless of how the environment changes.
 
 
 There are some restrictions:
Signature · 6 lines
2.6.6

_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

A message that is not in the archive (sent off-list or not yet received): [email protected]

#9 lore raw

Re: [Patch resend v3 3/3] binfmt_misc: add F option description to documentation

Quoted 8 lines · Serge E. Hallyn
Quoted 2 lines · James Bottomley

Signed-off-by: James Bottomley < James.Bottomley-d9PhHud1JfjCXq6kfMZ53/[email protected]>

Thanks, James. Which tree were you thinking this would go in through?

I'm happy to become binfmt_misc maintainer (on the grounds that last to touch it gets to keep it) and thus run my own tree, but I talked to Al at LSF/MM and he thinks it can go through the vfs tree.

James

Quoted 31 lines
Quoted 31 lines
---
 Documentation/binfmt_misc.txt | 7 +++++++
 1 file changed, 7 insertions(+)
Documentation/binfmt_misc.txt +0 -0
index 6b1de70..ec83bbc 100644
@@ -66,6 +66,13 @@ Here is what the fields mean:
             This feature should be used with care as the

interpreter
will run with root permissions when a setuid binary
owned by root
is run with binfmt_misc.
+ 'F' - fix binary. The usual behaviour of binfmt_misc is to
spawn the
+ binary lazily when the misc format file is
invoked. However,

Documentation/binfmt_misc.txt +1 -0
+	    this doesn't work very well in the face of mount

namespaces and

Documentation/binfmt_misc.txt +1 -0
+	    changeroots, so the F mode opens the binary as soon as

the

Documentation/binfmt_misc.txt +1 -0
+	    emulation is installed and uses the opened image to

spawn the

Documentation/binfmt_misc.txt +1 -0
+	    emulator, meaning it is always available once

installed,

Documentation/binfmt_misc.txt +1 -0
+	    regardless of how the environment changes.
 
 
 There are some restrictions:
#10 lore raw

Re: [Patch resend v3 3/3] binfmt_misc: add F option description to documentation

In reply to Serge E. Hallyn
Quoted 8 lines · Serge E. Hallyn
Quoted 2 lines · James Bottomley

Signed-off-by: James Bottomley <
[email protected]>

Thanks, James. Which tree were you thinking this would go in through?

I'm happy to become binfmt_misc maintainer (on the grounds that last to touch it gets to keep it) and thus run my own tree, but I talked to Al at LSF/MM and he thinks it can go through the vfs tree.

James

Quoted 31 lines
Quoted 31 lines
---
 Documentation/binfmt_misc.txt | 7 +++++++
 1 file changed, 7 insertions(+)
Documentation/binfmt_misc.txt +0 -0
index 6b1de70..ec83bbc 100644
@@ -66,6 +66,13 @@ Here is what the fields mean:
             This feature should be used with care as the

interpreter
will run with root permissions when a setuid binary
owned by root
is run with binfmt_misc.
+ 'F' - fix binary. The usual behaviour of binfmt_misc is to
spawn the
+ binary lazily when the misc format file is
invoked. However,

Documentation/binfmt_misc.txt +1 -0
+	    this doesn't work very well in the face of mount

namespaces and

Documentation/binfmt_misc.txt +1 -0
+	    changeroots, so the F mode opens the binary as soon as

the

Documentation/binfmt_misc.txt +1 -0
+	    emulation is installed and uses the opened image to

spawn the

Documentation/binfmt_misc.txt +1 -0
+	    emulator, meaning it is always available once

installed,

Documentation/binfmt_misc.txt +1 -0
+	    regardless of how the environment changes.
 
 
 There are some restrictions: