1. 13 Dec, 2014 1 commit
    • Andi Kleen's avatar
      usr/Kconfig: make initrd compression algorithm selection not expert · ec72c666
      Andi Kleen authored
      The kernel has support for (nearly) every compression algorithm known to
      man, each to handle some particular microscopic niche.
      Unfortunately all of these always get compiled in if you want to support
      INITRDs, and can be only disabled when CONFIG_EXPERT is set.
      I don't see why I need to set EXPERT just to properly configure the initrd
      compression algorithms, and not always include every possible algorithm
      Usually the initrd is just compressed with gzip anyways, at least that's
      true on all distributions I use.
      Remove the dependencies for initrd compression on CONFIG_EXPERT.
      Make the various options just default y, which should be good enough to
      not break any previous configuration.
      Signed-off-by: default avatarAndi Kleen <ak@linux.intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  2. 06 Jun, 2014 1 commit
  3. 13 Nov, 2013 2 commits
    • P J P's avatar
      initramfs: read CONFIG_RD_ variables for initramfs compression · 9ba4bcb6
      P J P authored
      When expert configuration option(CONFIG_EXPERT) is enabled, menuconfig
      offers a choice of compression algorithm to compress initial ramfs image;
      This choice is stored into CONFIG_RD_* variables.  But usr/Makefile uses
      earlier INITRAMFS_COMPRESSION_* macros to build initial ramfs file.  Since
      none of them is defined, resulting 'initramfs_data.cpio' file remains
      This patch updates the Makefile to use CONFIG_RD_* variables and adds
      support for LZ4 compression algorithm.  Also updates the
      'gen_initramfs_list.sh' script to check whether a selected compression
      command is accessible or not.  And fall-back to default gzip(1)
      compression when it is not.
      Signed-off-by: default avatarP J P <prasad@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Michal Nazarewicz's avatar
      gen_init_cpio: avoid NULL pointer dereference and rework env expanding · c725ee54
      Michal Nazarewicz authored
      getenv() may return NULL if given environment variable does not exist
      which leads to NULL dereference when calling strncat.
      Besides that, the environment variable name was copied to a temporary
      env_var buffer, but this copying can be avoided by simply using the input
      Lastly, the whole loop can be greatly simplified by using the snprintf
      function instead of the playing with strncat.
       By the way, the current implementation allows a recursive variable
       expansion, as in:
         $ echo 'out ${A} out ' | A='a ${B} a' B=b /tmp/a
         out a b a out
       I'm assuming this is just a side effect and not a conscious decision
       (especially as this may lead to infinite loop), but I didn't want to
       change this behaviour without consulting.
       If the current behaviour is deamed incorrect, I'll be happy to send
       a patch without recursive processing.
      Signed-off-by: default avatarMichal Nazarewicz <mina86@mina86.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Jesper Juhl <jj@codesealer.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  4. 09 Jul, 2013 1 commit
  5. 19 Nov, 2012 1 commit
  6. 25 Oct, 2012 1 commit
    • Kees Cook's avatar
      gen_init_cpio: avoid stack overflow when expanding · 20f1de65
      Kees Cook authored
      Fix possible overflow of the buffer used for expanding environment
      variables when building file list.
      In the extremely unlikely case of an attacker having control over the
      environment variables visible to gen_init_cpio, control over the
      contents of the file gen_init_cpio parses, and gen_init_cpio was built
      without compiler hardening, the attacker can gain arbitrary execution
      control via a stack buffer overflow.
        $ cat usr/crash.list
        file foo ${BIG}${BIG}${BIG}${BIG}${BIG}${BIG} 0755 0 0
        $ BIG=$(perl -e 'print "A" x 4096;') ./usr/gen_init_cpio usr/crash.list
        *** buffer overflow detected ***: ./usr/gen_init_cpio terminated
      This also replaces the space-indenting with tabs.
      Patch based on existing fix extracted from grsecurity.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Brad Spengler <spender@grsecurity.net>
      Cc: PaX Team <pageexec@freemail.hu>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  7. 01 Jun, 2012 1 commit
  8. 18 Apr, 2011 1 commit
  9. 21 Jan, 2011 1 commit
    • David Rientjes's avatar
      kconfig: rename CONFIG_EMBEDDED to CONFIG_EXPERT · 6a108a14
      David Rientjes authored
      The meaning of CONFIG_EMBEDDED has long since been obsoleted; the option
      is used to configure any non-standard kernel with a much larger scope than
      only small devices.
      This patch renames the option to CONFIG_EXPERT in init/Kconfig and fixes
      references to the option throughout the kernel.  A new CONFIG_EMBEDDED
      option is added that automatically selects CONFIG_EXPERT when enabled and
      can be used in the future to isolate options that should only be
      considered for embedded systems (RISC architectures, SLOB, etc).
      Calling the option "EXPERT" more accurately represents its intention: only
      expert users who understand the impact of the configuration changes they
      are making should enable it.
      Reviewed-by: default avatarIngo Molnar <mingo@elte.hu>
      Acked-by: default avatarDavid Woodhouse <david.woodhouse@intel.com>
      Signed-off-by: default avatarDavid Rientjes <rientjes@google.com>
      Cc: Greg KH <gregkh@suse.de>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Robin Holt <holt@sgi.com>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  10. 13 Jan, 2011 1 commit
    • Lasse Collin's avatar
      decompressors: add boot-time XZ support · 3ebe1243
      Lasse Collin authored
      This implements the API defined in <linux/decompress/generic.h> which is
      used for kernel, initramfs, and initrd decompression.  This patch together
      with the first patch is enough for XZ-compressed initramfs and initrd;
      XZ-compressed kernel will need arch-specific changes.
      The buffering requirements described in decompress_unxz.c are stricter
      than with gzip, so the relevant changes should be done to the
      arch-specific code when adding support for XZ-compressed kernel.
      Similarly, the heap size in arch-specific pre-boot code may need to be
      increased (30 KiB is enough).
      The XZ decompressor needs memmove(), memeq() (memcmp() == 0), and
      memzero() (memset(ptr, 0, size)), which aren't available in all
      arch-specific pre-boot environments.  I'm including simple versions in
      decompress_unxz.c, but a cleaner solution would naturally be nicer.
      Signed-off-by: default avatarLasse Collin <lasse.collin@tukaani.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Alain Knaff <alain@knaff.lu>
      Cc: Albin Tonnerre <albin.tonnerre@free-electrons.com>
      Cc: Phillip Lougher <phillip@lougher.demon.co.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  11. 05 Jan, 2011 1 commit
  12. 29 Dec, 2010 1 commit
  13. 02 Dec, 2010 1 commit
    • Thomas Chou's avatar
      gen_init_cpio: remove leading `/' from file names · 43f901fb
      Thomas Chou authored
      When we extracted the generated cpio archive using "cpio -id" command,
      it complained,
      cpio: Removing leading `/' from member names
      cpio: Removing leading `/' from member names
      cpio: Removing leading `/' from member names
      It is worse with the latest "cpio" or "pax", which tries to overwrite
      the host file system with the leading '/'.
      So the leading '/' of file names should be removed. This is consistent
      with the initramfs come with major distributions such as Fedora or
      Debian, etc.
      Signed-off-by: default avatarThomas Chou <thomas@wytron.com.tw>
      Acked-by: Mike Frysinger<vapier@gentoo.org>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
  14. 01 Dec, 2010 1 commit
  15. 31 Oct, 2010 1 commit
    • Geert Uytterhoeven's avatar
      initramfs: Fix initramfs size for 32-bit arches · 96f93593
      Geert Uytterhoeven authored
      Commit ffe8018c ("initramfs: fix initramfs size calculation") broke
      32-bit big-endian arches like (on ARAnyM):
          VFS: Cannot open root device "hda1" or unknown-block(3,1)
          Please append a correct "root=" boot option; here are the available partitions:
          fe80         1059408 nfhd8  (driver?)
            fe81          921600 nfhd8p1 00000000-0000-0000-0000-000000000nfhd8p1
            fe82          137807 nfhd8p2 00000000-0000-0000-0000-000000000nfhd8p2
          0200            3280 fd0  (driver?)
          0201            3280 fd1  (driver?)
          0300         1059408 hda  driver: ide-gd
            0301          921600 hda1 00000000-0000-0000-0000-000000000hda1
            0302          137807 hda2 00000000-0000-0000-0000-000000000hda2
          Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(3,1)
      As pointed out by Kerstin Jonsson <kerstin.jonsson@ericsson.com>, this
      is due to CONFIG_32BIT not being defined, so the initramfs size field is
      done as a 64-bit quad.  On little-endian (like x86) this doesn matter,
      but on a big-endian machine the 32-bit reads will see the (zero) high
      Only mips, s390, and score set CONFIG_32BIT for 32-bit builds, so fix it for
      all other 32-bit arches by inverting the logic and testing for CONFIG_64BIT,
      which should be defined on all 64-bit arches.
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      [ I think we should just make it "u64" on all architectures and get
        rid of the whole #ifdef CONFIG_xxBIT   - Linus ]
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  16. 29 Sep, 2010 2 commits
    • Hendrik Brueckner's avatar
      initramfs: fix initramfs size calculation · ffe8018c
      Hendrik Brueckner authored
      The size of a built-in initramfs is calculated in init/initramfs.c by
      "__initramfs_end - __initramfs_start".  Those symbols are defined in the
      linker script include/asm-generic/vmlinux.lds.h:
      #define INIT_RAM_FS                                                     \
              . = ALIGN(PAGE_SIZE);                                           \
              VMLINUX_SYMBOL(__initramfs_start) = .;                          \
              *(.init.ramfs)                                                  \
              VMLINUX_SYMBOL(__initramfs_end) = .;
      If the initramfs file has an odd number of bytes, the "__initramfs_end"
      symbol points to an odd address, for example, the symbols in the
      System.map might look like:
          0000000000572000 T __initramfs_start
          00000000005bcd05 T __initramfs_end	  <-- odd address
      At least on s390 this causes a problem:
      Certain s390 instructions, especially instructions for loading addresses
      (larl) or branch addresses must be on even addresses.  The compiler loads
      the symbol addresses with the "larl" instruction.  This instruction sets
      the last bit to 0 and, therefore, for odd size files, the calculated size
      is one byte less than it should be:
          0000000000540a9c <populate_rootfs>:
            540a9c:     eb cf f0 78 00 24       stmg    %r12,%r15,120(%r15),
            540aa2:     c0 10 00 01 8a af       larl    %r1,572000 <__initramfs_start>
            540aa8:     c0 c0 00 03 e1 2e       larl    %r12,5bcd04 <initramfs_end>
                                                        (Instead of  5bcd05)
            540abe:     1b c1                   sr      %r12,%r1
      To fix the problem, this patch introduces the global variable
      __initramfs_size, which is calculated in the "usr/initramfs_data.S" file.
      The populate_rootfs() function can then use the start marker of the
      .init.ramfs section and the value of __initramfs_size for loading the
      initramfs.  Because the start marker and size is sufficient, the
      __initramfs_end symbol is no longer needed and is removed.
      Signed-off-by: default avatarMichael Holzheu <holzheu@linux.vnet.ibm.com>
      Signed-off-by: default avatarHendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Reviewed-by: default avatarWANG Cong <xiyou.wangcong@gmail.com>
      Acked-by: default avatarMichal Marek <mmarek@suse.cz>
      Acked-by: default avatar"H. Peter Anvin" <hpa@zytor.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
    • Hendrik Brueckner's avatar
      initramfs: generalize initramfs_data.xxx.S variants · 6ae64e42
      Hendrik Brueckner authored
      Remove initramfs_data.{lzo,lzma,gz,bz2}.S variants and use a common
      implementation in initramfs_data.S.  The common implementation expects the
      file name of the initramfs to be defined in INITRAMFS_IMAGE.
      Change the Makefile to set the INITRAMFS_IMAGE define symbol according
      to the selected compression method.
      Signed-off-by: default avatarHendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Cc: WANG Cong <xiyou.wangcong@gmail.com>
      Acked-by: default avatarMichal Marek <mmarek@suse.cz>
      Acked-by: default avatar"H. Peter Anvin" <hpa@zytor.com>
      Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
  17. 23 Aug, 2010 1 commit
  18. 27 May, 2010 1 commit
  19. 11 Jan, 2010 1 commit
  20. 12 Dec, 2009 1 commit
  21. 23 Sep, 2009 1 commit
  22. 20 Sep, 2009 2 commits
  23. 01 Apr, 2009 1 commit
  24. 29 Mar, 2009 1 commit
  25. 28 Mar, 2009 3 commits
  26. 19 Feb, 2009 1 commit
  27. 07 Jan, 2009 2 commits
    • Alain Knaff's avatar
      bzip2/lzma: fix built-in initramfs vs CONFIG_RD_GZIP · a26ee60f
      Alain Knaff authored
      Impact: Resolves build failures in some configurations
      Makes it possible to disable CONFIG_RD_GZIP . In that case, the
      built-in initramfs will be compressed by whatever compressor is
      available (bzip2 or lzma) or left uncompressed if none is available.
      It also removes a couple of warnings which occur when no ramdisk
      compression at all is chosen.
      It also restores the select ZLIB_INFLATE in drivers/block/Kconfig
      which somehow came missing. This is needed to activate compilation of
      the stuff in zlib_deflate.
      Signed-off-by: default avatarAlain Knaff <alain@knaff.lu>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
    • H. Peter Anvin's avatar
      bzip2/lzma: move initrd/ramfs options out of BLK_DEV · fb9a4ca9
      H. Peter Anvin authored
      Impact: Partial resolution of build failure
      Move the initrd/initramfs configuration options from
      drivers/block/Kconfig to usr/Kconfig, since they do not and should not
      depend on CONFIG_BLK_DEV.  This fixes builds when CONFIG_BLK_DEV=n.
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
  28. 03 Dec, 2008 1 commit
    • Sally, Gene's avatar
      kbuild: gen_init_cpio expands shell variables in file names · 3b1ec9fb
      Sally, Gene authored
      Modify gen_init_cpio so that lines that specify files can contain
      what looks like a shell variable that's expanded during processing.
      For example:
         file /sbin/kinit ${RFS_BASE}/usr/src/klibc/kinit/kinit 0755 0 0
      given RFS_BASE is "/some/directory" in the environment
      would be expanded to
         file /sbin/kinit /some/directory/usr/src/klibc/kinit/kinit 0755 0 0
      If several environment variables appear in a line, they are all expanded
      with processing happening from left to right.
      Undefined variables expand to a null string.
      Syntax errors stop processing, letting the existing error handling
      show the user offending line.
      This patch helps embedded folks who frequently create several
      RFS directories and then switch between them as they're tuning
      an initramfs.
      Signed-off-by: gene.sally@timesys.com
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
  29. 16 Jul, 2007 2 commits
  30. 02 May, 2007 1 commit
  31. 11 Feb, 2007 2 commits
    • Luciano Rocha's avatar
      [PATCH] usr/gen_init_cpio.c: support for hard links · 24fa5096
      Luciano Rocha authored
      Extend usr/gen_init_cpio.c "file" entry, adding support for hard links.
      Previous format:
      file <name> <location> <mode> <uid> <gid>
      New format:
      file <name> <location> <mode> <uid> <gid> [<hard links>]
      The hard links specification is optional, keeping the previous
      All hard links are defined sequentially in the resulting cpio and the
      file data is present only in the last link. This is the behaviour of
      GNU's cpio and is supported by the kernel initramfs extractor.
      Signed-off-by: default avatarLuciano Rocha <strange@nsk.no-ip.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Jean-Paul Saman's avatar
      [PATCH] disable init/initramfs.c · c33df4ea
      Jean-Paul Saman authored
      The file init/initramfs.c is always compiled and linked in the kernel
      vmlinux even when BLK_DEV_RAM and BLK_DEV_INITRD are disabled and the
      system isn't using any form of an initramfs or initrd.  In this situation
      the code is only used to unpack a (static) default initial rootfilesystem.
      The current init/initramfs.c code.  usr/initramfs_data.o compiles to a size
      of ~15 kbytes.  Disabling BLK_DEV_RAM and BLK_DEV_INTRD shrinks the kernel
      code size with ~60 Kbytes.
      This patch avoids compiling in the code and data for initramfs support if
      CONFIG_BLK_DEV_INITRD is not defined.  Instead of the initramfs code and
      data it uses a small routine in init/noinitramfs.c to setup an initial
      static default environment for mounting a rootfilesystem later on in the
      kernel initialisation process.  The new code is: 164 bytes of size.
      The patch is separated in two parts:
      1) doesn't compile initramfs code when CONFIG_BLK_DEV_INITRD is not set
      2) changing all plaforms vmlinux.lds.S files to not reserve an area of
      PAGE_SIZE when CONFIG_BLK_DEV_INITRD is not set.
      [deweerdt@free.fr: warning fix]
      Signed-off-by: default avatarJean-Paul Saman <jean-paul.saman@nxp.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: default avatarFrederik Deweerdt <frederik.deweerdt@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  32. 25 Nov, 2006 1 commit