31 Mar, 2016

1 commit


14 Oct, 2014

2 commits

  • 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
    Cc: Al Viro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mike Frysinger
     
  • 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
    Cc: Al Viro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mike Frysinger
     

04 Aug, 2010

1 commit

  • Below you will find an updated version from the original series bunching all patches into one big patch
    updating broken web addresses that are located in Documentation/*
    Some of the addresses date as far far back as 1995 etc... so searching became a bit difficult,
    the best way to deal with these is to use web.archive.org to locate these addresses that are outdated.
    Now there are also some addresses pointing to .spec files some are located, but some(after searching
    on the companies site)where still no where to be found. In this case I just changed the address
    to the company site this way the users can contact the company and they can locate them for the users.

    Signed-off-by: Justin P. Mattock
    Signed-off-by: Thomas Weber
    Signed-off-by: Mike Frysinger
    Cc: Paulo Marques
    Cc: Randy Dunlap
    Cc: Michael Neuling
    Signed-off-by: Jiri Kosina

    Justin P. Mattock
     

09 May, 2007

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds