1. 29 5月, 2014 1 次提交
    • A
      ftrace: Add arm64 support to recordmcount · af64d2aa
      AKASHI Takahiro 提交于
      Recordmcount utility under scripts is run, after compiling each object,
      to find out all the locations of calling _mcount() and put them into
      specific seciton named __mcount_loc.
      Then linker collects all such information into a table in the kernel image
      (between __start_mcount_loc and __stop_mcount_loc) for later use by ftrace.
      
      This patch adds arm64 specific definitions to identify such locations.
      There are two types of implementation, C and Perl. On arm64, only C version
      is used to build the kernel now that CONFIG_HAVE_C_RECORDMCOUNT is on.
      But Perl version is also maintained.
      
      This patch also contains a workaround just in case where a header file,
      elf.h, on host machine doesn't have definitions of EM_AARCH64 nor
      R_AARCH64_ABS64. Without them, compiling C version of recordmcount will
      fail.
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NAKASHI Takahiro <takahiro.akashi@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      af64d2aa
  2. 10 4月, 2014 2 次提交
  3. 08 4月, 2014 4 次提交
  4. 04 4月, 2014 23 次提交
  5. 02 4月, 2014 1 次提交
  6. 30 3月, 2014 2 次提交
  7. 17 3月, 2014 2 次提交
    • R
      kallsyms: fix percpu vars on x86-64 with relocation. · c6bda7c9
      Rusty Russell 提交于
      x86-64 has a problem: per-cpu variables are actually represented by
      their absolute offsets within the per-cpu area, but the symbols are
      not emitted as absolute.  Thus kallsyms naively creates them as offsets
      from _text, meaning their values change if the kernel is relocated
      (especially noticeable with CONFIG_RANDOMIZE_BASE):
      
       $ egrep ' (gdt_|_(stext|_per_cpu_))' /root/kallsyms.nokaslr
       0000000000000000 D __per_cpu_start
       0000000000004000 D gdt_page
       0000000000014280 D __per_cpu_end
       ffffffff810001c8 T _stext
       ffffffff81ee53c0 D __per_cpu_offset
       $ egrep ' (gdt_|_(stext|_per_cpu_))' /root/kallsyms.kaslr1
       000000001f200000 D __per_cpu_start
       000000001f204000 D gdt_page
       000000001f214280 D __per_cpu_end
       ffffffffa02001c8 T _stext
       ffffffffa10e53c0 D __per_cpu_offset
      
      Making them absolute symbols is the Right Thing, but requires fixes to
      the relocs tool.  So for the moment, we add a --absolute-percpu option
      which makes them absolute from a kallsyms perspective:
      
       $ egrep ' (gdt_|_(stext|_per_cpu_))' /proc/kallsyms # no KASLR
       0000000000000000 A __per_cpu_start
       000000000000a000 A gdt_page
       0000000000013040 A __per_cpu_end
       ffffffff802001c8 T _stext
       ffffffff8099b180 D __per_cpu_offset
       ffffffff809a3000 D __per_cpu_load
       $ egrep ' (gdt_|_(stext|_per_cpu_))' /proc/kallsyms # With KASLR
       0000000000000000 A __per_cpu_start
       000000000000a000 A gdt_page
       0000000000013040 A __per_cpu_end
       ffffffff89c001c8 T _stext
       ffffffff8a39d180 D __per_cpu_offset
       ffffffff8a3a5000 D __per_cpu_load
      Based-on-the-original-screenplay-by: NAndy Honig <ahonig@google.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Acked-by: NKees Cook <keescook@chromium.org>
      c6bda7c9
    • K
      kallsyms: generalize address range checking · 78eb7159
      Kees Cook 提交于
      This refactors the address range checks to be generalized instead of
      specific to text range checks, in preparation for other range checks.
      Also extracts logic for "is the symbol absolute" into a function.
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      78eb7159
  8. 15 3月, 2014 1 次提交
  9. 13 3月, 2014 1 次提交
  10. 11 3月, 2014 1 次提交
  11. 04 3月, 2014 2 次提交
    • A
      kallsyms: fix absolute addresses for kASLR · 0f55159d
      Andy Honig 提交于
      Currently symbols that are absolute addresses are incorrectly displayed
      in /proc/kallsyms if the kernel is loaded with kASLR.
      
      The problem was that the scripts/kallsyms.c file which generates the
      array of symbol names and addresses uses an relocatable value for all
      symbols, even absolute symbols.  This patch fixes that.
      
      Several kallsyms output in different boot states for comparison:
      
        $ egrep '_(stext|_per_cpu_(start|end))' /root/kallsyms.nokaslr
        0000000000000000 D __per_cpu_start
        0000000000014280 D __per_cpu_end
        ffffffff810001c8 T _stext
        $ egrep '_(stext|_per_cpu_(start|end))' /root/kallsyms.kaslr1
        000000001f200000 D __per_cpu_start
        000000001f214280 D __per_cpu_end
        ffffffffa02001c8 T _stext
        $ egrep '_(stext|_per_cpu_(start|end))' /root/kallsyms.kaslr2
        000000000d400000 D __per_cpu_start
        000000000d414280 D __per_cpu_end
        ffffffff8e4001c8 T _stext
        $ egrep '_(stext|_per_cpu_(start|end))' /root/kallsyms.kaslr-fixed
        0000000000000000 D __per_cpu_start
        0000000000014280 D __per_cpu_end
        ffffffffadc001c8 T _stext
      Signed-off-by: NAndy Honig <ahonig@google.com>
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0f55159d
    • D
      scripts/gen_initramfs_list.sh: fix flags for initramfs LZ4 compression · 5ec384d4
      Daniel M. Weeks 提交于
      LZ4 as implemented in the kernel differs from the default method now
      used by the reference implementation of LZ4.  Until the in-kernel method
      is updated to support the new default, passing the legacy flag (-l) to
      the compressor is necessary.  Without this flag the kernel-generated,
      LZ4-compressed initramfs is junk.
      
      Kyungsik said:
      
      : It seems that lz4 supports legacy format with the same option as lz4c
      : does.  Just looking at the first few bytes of lz4 compressed image, we can
      : see whether it is new format or not.
      :
      : It shows new format magic number without this patch.  New format magic
      : number is 0x184d2204.
      :
      : $ hexdump -C ./initramfs_data.cpio.lz4 |more
      : 00000000  04 22 4d 18 64 70 b9 69 (Little Endian)
      : ...
      :
      : Currently kernel supports legacy format only.
      Signed-off-by: NDaniel M. Weeks <dan@danweeks.net>
      Cc: Michal Marek <mmarek@suse.cz>
      Acked-by: NKyungsik Lee <kyungsik.lee@lge.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5ec384d4