1. 03 Oct, 2017 1 commit
  2. 21 Aug, 2017 1 commit
    • Ard Biesheuvel's avatar
      arm/efi: Split zImage code and data into separate PE/COFF sections · e4bae4d0
      Ard Biesheuvel authored
      To prevent unintended modifications to the kernel text (malicious or
      otherwise) while running the EFI stub, describe the kernel image as
      two separate sections: a .text section with read-execute permissions,
      covering .text, .rodata, .piggytext and the GOT sections (which the
      stub does not care about anyway), and a .data section with read-write
      permissions, covering .data and .bss.
      This relies on the firmware to actually take the section permission
      flags into account, but this is something that is currently being
      implemented in EDK2, which means we will likely start seeing it in
      the wild between one and two years from now.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/20170818194947.19347-12-ard.biesheuvel@linaro.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
  3. 14 Dec, 2015 1 commit
  4. 01 Jul, 2014 2 commits
  5. 14 Sep, 2011 1 commit
  6. 07 Jul, 2011 1 commit
  7. 07 May, 2011 1 commit
  8. 26 Feb, 2011 1 commit
    • Nicolas Pitre's avatar
      ARM: 6746/1: remove the 4x expansion presumption while decompressing the kernel · d239b1dc
      Nicolas Pitre authored
      We currently presume a 4x expansion to guess the decompressed kernel size
      in order to determine if the decompressed kernel is in conflict with
      the location where zImage is loaded.  This guess may cause many issues
      by overestimating the final kernel image size:
      - This may force a needless relocation if the location of zImage was
        fine, wasting some precious microseconds of boot time.
      - The relocation may be located way too far, possibly overwriting the
        initrd image in RAM.
      - If the kernel image includes a large already-compressed initramfs image
        then the problem is even more exacerbated.
      And if by some strange means the 4x guess is too low then we may overwrite
      ourselves with the decompressed image.
      So let's use the exact decompressed kernel image size instead.  For that
      we need to rely on the stat command, but this is hardly a new build
      dependency as the kernel already depends on many external commands
      to be built provided by the coreutils package where stat is found.
      Signed-off-by: default avatarNicolas Pitre <nicolas.pitre@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  9. 22 Nov, 2010 1 commit
  10. 26 Feb, 2010 1 commit
    • Russell King's avatar
      ARM: Fix decompressor's kernel size estimation for ROM=y · 98e12b5a
      Russell King authored
      Commit 2552fc27
       changed the way the decompressor decides if it is safe
      to decompress the kernel directly to its final location.  Unfortunately,
      it took the top of the compressed data as being the stack pointer,
      which it is for ROM=n cases.  However, for ROM=y, the stack pointer
      is not relevant, and results in the wrong answer.
      Fix this by explicitly storing the end of the biggybacked data in the
      decompressor, and use that to calculate the compressed image size.
      CC: <stable@kernel.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  11. 25 Feb, 2010 1 commit
    • Russell King's avatar
      ARM: Eliminate decompressor -Dstatic= PIC hack · 5de813b6
      Russell King authored
      We used to build decompressors with -Dstatic= to avoid any local data
      being generated.  The problem is that local data generates GOTOFF
      relocations, which means we can't relocate the data relative to the
      text segment.
      Global data, on the other hand, goes through the GOT, and can be
      relocated anywhere.
      Unfortunately, with the new decompressors, this presents a problem
      since they declare static data within functions, and this leads to
      stack overflow.
      Fix this by separating out the decompressor code into a separate file,
      and removing 'static' from BSS data in misc.c.
      Also, discard the .data section - this means that should we end up
      with read/write initialized data, the decompressor will fail to link
      and the problem will be obvious.
      Acked-by: default avatarNicolas Pitre <nico@fluxnic.net>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  12. 19 Feb, 2009 1 commit
  13. 09 Apr, 2006 1 commit
  14. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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!