linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 1/2] binfmt_misc: expand the register format limit to 1920 bytes
@ 2014-09-01  9:38 Mike Frysinger
  2014-09-01  9:38 ` [PATCH 2/2] binfmt_misc: touch up documentation a bit Mike Frysinger
  0 siblings, 1 reply; 2+ messages in thread
From: Mike Frysinger @ 2014-09-01  9:38 UTC (permalink / raw)
  To: linux-kernel; +Cc: Andrew Morton, Al Viro, linux-fsdevel

The current code places a 256 byte limit on the registration format.
This ends up being fairly limited when you try to do matching against
a binary format like ELF:
 - the magic & mask formats cannot have any embedded NUL chars
   (string_unescape_inplace halts at the first NUL)
 - each escape sequence quadruples the size: \x00 is needed for NUL
 - trying to match bytes at the start of the file as well as further
   on leads to a lot of \x00 sequences in the mask
 - magic & mask have to be the same length (when decoded)
 - still need bytes for the other fields
 - impossible!

Let's look at a concrete (and common) example: using QEMU to run MIPS
ELFs.  The name field uses 11 bytes "qemu-mipsel".  The interp uses 20
bytes "/usr/bin/qemu-mipsel".  The type & flags takes up 4 bytes.  We
need 7 bytes for the delimiter (usually ":").  We can skip offset.  So
already we're down to 107 bytes to use with the magic/mask instead of
the real limit of 128 (BINPRM_BUF_SIZE).  If people use shell code to
register (which they do the majority of the time), they're down to ~26
possible bytes since the escape sequence must be \x##.

The ELF format looks like (both 32 & 64 bit):
	e_ident: 16 bytes
	e_type: 2 bytes
	e_machine: 2 bytes
Those 20 bytes are enough for most architectures because they have so
few formats in the first place, thus they can be uniquely identified.
That also means for shell users, since 20 is smaller than 26, they can
sanely register a handler.

But for some targets (like MIPS), we need to poke further.  The ELF
fields continue on:
	e_entry: 4 or 8 bytes
	e_phoff: 4 or 8 bytes
	e_shoff: 4 or 8 bytes
	e_flags: 4 bytes
We only care about e_flags here as that includes the bits to identify
whether the ELF is O32/N32/N64.  But now we have to consume another 16
bytes (for 32 bit ELFs) or 28 bytes (for 64 bit ELFs) just to match the
flags.  If every byte is escaped, we send 288 more bytes to the kernel
((20 {e_ident,e_type,e_machine} + 12 {e_entry,e_phoff,e_shoff} +
4 {e_flags}) * 2 {mask,magic} * 4 {escape}) and we've clearly blown our
budget.

Even if we try to be clever and do the decoding ourselves (rather than
relying on the kernel to process \x##), we still can't hit the mark --
string_unescape_inplace treats mask & magic as C strings so NUL cannot
be embedded.  That leaves us with having to pass \x00 for the 12/24
entry/phoff/shoff bytes (as those will be completely random addresses),
and that is a minimum requirement of 48/96 bytes for the mask alone.
Add up the rest and we blow through it (this is for 64 bit ELFs):
magic: 20 {e_ident,e_type,e_machine} + 24 {e_entry,e_phoff,e_shoff} +
       4 {e_flags} = 48              # ^^ See note below.
mask: 20 {e_ident,e_type,e_machine} + 96 {e_entry,e_phoff,e_shoff} +
       4 {e_flags} = 120
Remember above we had 107 left over, and now we're at 168.  This is of
course the *best* case scenario -- you'll also want to have NUL bytes
in the magic & mask too to match literal zeros.

Note: the reason we can use 24 in the magic is that we can work off of
the fact that for bytes the mask would clobber, we can stuff any value
into magic that we want.  So when mask is \x00, we don't need the magic
to also be \x00, it can be an unescaped raw byte like '!'.  This lets
us handle more formats (barely) under the current 256 limit, but that's
a pretty tall hoop to force people to jump through.

With all that said, let's bump the limit from 256 bytes to 1920.  This
way we support escaping every byte of the mask & magic field (which is
1024 bytes by themselves -- 128 * 4 * 2), and we leave plenty of room
for other fields.  Like long paths to the interpreter (when you have
source in your /really/long/homedir/qemu/foo).  Since the current code
stuffs more than one structure into the same buffer, we leave a bit of
space to easily round up to 2k.  1920 is just as arbitrary as 256 ;).

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
 Documentation/binfmt_misc.txt |  2 +-
 fs/binfmt_misc.c              | 19 +++++++++++++++++--
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/Documentation/binfmt_misc.txt b/Documentation/binfmt_misc.txt
index c1ed694..f64372b 100644
--- a/Documentation/binfmt_misc.txt
+++ b/Documentation/binfmt_misc.txt
@@ -58,7 +58,7 @@ Here is what the fields mean:
 
 
 There are some restrictions:
- - the whole register string may not exceed 255 characters
+ - the whole register string may not exceed 1920 characters
  - the magic must reside in the first 128 bytes of the file, i.e.
    offset+size(magic) has to be less than 128
  - the interpreter string may not exceed 127 characters
diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
index b605003..c96b855 100644
--- a/fs/binfmt_misc.c
+++ b/fs/binfmt_misc.c
@@ -62,7 +62,22 @@ static struct file_system_type bm_fs_type;
 static struct vfsmount *bm_mnt;
 static int entry_count;
 
-/* 
+/*
+ * Max length of the register string.  Determined by:
+ *  - 7 delimiters
+ *  - name:   ~50 bytes
+ *  - type:   1 byte
+ *  - offset: 3 bytes (has to be smaller than BINPRM_BUF_SIZE)
+ *  - magic:  128 bytes (512 in escaped form)
+ *  - mask:   128 bytes (512 in escaped form)
+ *  - interp: ~50 bytes
+ *  - flags:  5 bytes
+ * Round that up a bit, and then back off to hold the internal data
+ * (like struct Node).
+ */
+#define MAX_REGISTER_LENGTH 1920
+
+/*
  * Check if we support the binfmt
  * if we do, return the node, else NULL
  * locking is done in load_misc_binary
@@ -279,7 +294,7 @@ static Node *create_entry(const char __user *buffer, size_t count)
 
 	/* some sanity checks */
 	err = -EINVAL;
-	if ((count < 11) || (count > 256))
+	if ((count < 11) || (count > MAX_REGISTER_LENGTH))
 		goto out;
 
 	err = -ENOMEM;
-- 
2.0.0


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* [PATCH 2/2] binfmt_misc: touch up documentation a bit
  2014-09-01  9:38 [PATCH 1/2] binfmt_misc: expand the register format limit to 1920 bytes Mike Frysinger
@ 2014-09-01  9:38 ` Mike Frysinger
  0 siblings, 0 replies; 2+ messages in thread
From: Mike Frysinger @ 2014-09-01  9:38 UTC (permalink / raw)
  To: linux-kernel; +Cc: Andrew Morton, Al Viro, linux-fsdevel

Line wrap the content to 80 cols, and add more details to various
fields to match the code.  Drop reference to a website that does
not exist anymore.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
 Documentation/binfmt_misc.txt | 48 +++++++++++++++++++++++++------------------
 1 file changed, 28 insertions(+), 20 deletions(-)

diff --git a/Documentation/binfmt_misc.txt b/Documentation/binfmt_misc.txt
index f64372b..6b1de70 100644
--- a/Documentation/binfmt_misc.txt
+++ b/Documentation/binfmt_misc.txt
@@ -15,39 +15,50 @@ First you must mount binfmt_misc:
 	mount binfmt_misc -t binfmt_misc /proc/sys/fs/binfmt_misc 
 
 To actually register a new binary type, you have to set up a string looking like
-:name:type:offset:magic:mask:interpreter:flags (where you can choose the ':' upon
-your needs) and echo it to /proc/sys/fs/binfmt_misc/register.
+:name:type:offset:magic:mask:interpreter:flags (where you can choose the ':'
+upon your needs) and echo it to /proc/sys/fs/binfmt_misc/register.
+
 Here is what the fields mean:
  - 'name' is an identifier string. A new /proc file will be created with this
-   name below /proc/sys/fs/binfmt_misc
+   name below /proc/sys/fs/binfmt_misc; cannot contain slashes '/' for obvious
+   reasons.
  - 'type' is the type of recognition. Give 'M' for magic and 'E' for extension.
  - 'offset' is the offset of the magic/mask in the file, counted in bytes. This
-   defaults to 0 if you omit it (i.e. you write ':name:type::magic...')
+   defaults to 0 if you omit it (i.e. you write ':name:type::magic...'). Ignored
+   when using filename extension matching.
  - 'magic' is the byte sequence binfmt_misc is matching for. The magic string
-   may contain hex-encoded characters like \x0a or \xA4. In a shell environment
-   you will have to write \\x0a to prevent the shell from eating your \.
+   may contain hex-encoded characters like \x0a or \xA4. Note that you must
+   escape any NUL bytes; parsing halts at the first one. In a shell environment
+   you might have to write \\x0a to prevent the shell from eating your \.
    If you chose filename extension matching, this is the extension to be
    recognised (without the '.', the \x0a specials are not allowed). Extension
-   matching is case sensitive!
+   matching is case sensitive, and slashes '/' are not allowed!
  - 'mask' is an (optional, defaults to all 0xff) mask. You can mask out some
    bits from matching by supplying a string like magic and as long as magic.
-   The mask is anded with the byte sequence of the file.
+   The mask is anded with the byte sequence of the file. Note that you must
+   escape any NUL bytes; parsing halts at the first one. Ignored when using
+   filename extension matching.
  - 'interpreter' is the program that should be invoked with the binary as first
    argument (specify the full path)
  - 'flags' is an optional field that controls several aspects of the invocation
-   of the interpreter. It is a string of capital letters, each controls a certain
-   aspect. The following flags are supported -
-      'P' - preserve-argv[0].  Legacy behavior of binfmt_misc is to overwrite the
-            original argv[0] with the full path to the binary.  When this flag is
-            included, binfmt_misc will add an argument to the argument vector for
-            this purpose, thus preserving the original argv[0].
+   of the interpreter. It is a string of capital letters, each controls a
+   certain aspect. The following flags are supported -
+      'P' - preserve-argv[0]. Legacy behavior of binfmt_misc is to overwrite
+            the original argv[0] with the full path to the binary. When this
+            flag is included, binfmt_misc will add an argument to the argument
+            vector for this purpose, thus preserving the original argv[0].
+            e.g. If your interp is set to /bin/foo and you run `blah` (which is
+            in /usr/local/bin), then the kernel will execute /bin/foo with
+            argv[] set to ["/bin/foo", "/usr/local/bin/blah", "blah"].  The
+            interp has to be aware of this so it can execute /usr/local/bin/blah
+            with argv[] set to ["blah"].
       'O' - open-binary. Legacy behavior of binfmt_misc is to pass the full path
             of the binary to the interpreter as an argument. When this flag is
             included, binfmt_misc will open the file for reading and pass its
             descriptor as an argument, instead of the full path, thus allowing
-            the interpreter to execute non-readable binaries. This feature should
-            be used with care - the interpreter has to be trusted not to emit
-            the contents of the non-readable binary.
+            the interpreter to execute non-readable binaries. This feature
+            should be used with care - the interpreter has to be trusted not to
+            emit the contents of the non-readable binary.
       'C' - credentials. Currently, the behavior of binfmt_misc is to calculate
             the credentials and security token of the new process according to
             the interpreter. When this flag is included, these attributes are
@@ -110,7 +121,4 @@ passes it the full filename (or the file descriptor) to use.  Using $PATH can
 cause unexpected behaviour and can be a security hazard.
 
 
-There is a web page about binfmt_misc at
-http://www.tat.physik.uni-tuebingen.de
-
 Richard Günther <rguenth@tat.physik.uni-tuebingen.de>
-- 
2.0.0


^ permalink raw reply related	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2014-09-01  9:38 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-01  9:38 [PATCH 1/2] binfmt_misc: expand the register format limit to 1920 bytes Mike Frysinger
2014-09-01  9:38 ` [PATCH 2/2] binfmt_misc: touch up documentation a bit Mike Frysinger

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).