linux-toradex.git/scripts/kallsyms.c, branch v4.9.16

ARM: 8553/1: kallsyms: remove --page-offset command line option

2016-04-07T20:57:16+00:00

The --page-offset command line option was only used for ARM, to filter
symbol addresses below CONFIG_PAGE_OFFSET. This is no longer needed, so
remove the functionality altogether.

Acked-by: Nicolas Pitre 
Acked-by: Chris Brandt 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Russell King

ARM: 8555/1: kallsyms: ignore ARM mode switching veneers

2016-04-07T20:57:15+00:00

On ARM, the linker may emit veneers to deal with relative branch
instructions that appear too far away from their targets. Since the
second kallsyms pass results in an increase of the kernel size, it may
result in additional veneers to be emitted, potentially affecting the
output of kallsyms itself if these symbols are visible to it, and for
that reason, symbols whose names end in '_veneer' are ignored explicitly.

However, when building Thumb2 kernels, such veneers are named differently
if they also incur a mode switch, and since they are not filtered by
kallsyms, they may cause the build to fail. So filter symbols whose names
end in '_from_arm' or '_from_thumb' as well.

Tested-by: Arnd Bergmann 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Russell King

kallsyms: add support for relative offsets in kallsyms address table

2016-03-15T23:55:16+00:00

Similar to how relative extables are implemented, it is possible to emit
the kallsyms table in such a way that it contains offsets relative to
some anchor point in the kernel image rather than absolute addresses.

On 64-bit architectures, it cuts the size of the kallsyms address table
in half, since offsets between kernel symbols can typically be expressed
in 32 bits.  This saves several hundreds of kilobytes of permanent
.rodata on average.  In addition, the kallsyms address table is no
longer subject to dynamic relocation when CONFIG_RELOCATABLE is in
effect, so the relocation work done after decompression now doesn't have
to do relocation updates for all these values.  This saves up to 24
bytes (i.e., the size of a ELF64 RELA relocation table entry) per value,
which easily adds up to a couple of megabytes of uncompressed __init
data on ppc64 or arm64.  Even if these relocation entries typically
compress well, the combined size reduction of 2.8 MB uncompressed for a
ppc64_defconfig build (of which 2.4 MB is __init data) results in a ~500
KB space saving in the compressed image.

Since it is useful for some architectures (like x86) to retain the
ability to emit absolute values as well, this patch also adds support
for capturing both absolute and relative values when
KALLSYMS_ABSOLUTE_PERCPU is in effect, by emitting absolute per-cpu
addresses as positive 32-bit values, and addresses relative to the
lowest encountered relative symbol as negative values, which are
subtracted from the runtime address of this base symbol to produce the
actual address.

Support for the above is enabled by default for all architectures except
IA-64 and Tile-GX, whose symbols are too far apart to capture in this
manner.

Signed-off-by: Ard Biesheuvel 
Tested-by: Guenter Roeck 
Reviewed-by: Kees Cook 
Tested-by: Kees Cook 
Cc: Heiko Carstens 
Cc: Michael Ellerman 
Cc: Ingo Molnar 
Cc: H. Peter Anvin 
Cc: Benjamin Herrenschmidt 
Cc: Michal Marek 
Cc: Rusty Russell 
Cc: Arnd Bergmann 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kallsyms: don't overload absolute symbol type for percpu symbols

2016-03-15T23:55:16+00:00

Commit c6bda7c988a5 ("kallsyms: fix percpu vars on x86-64 with
relocation") overloaded the 'A' (absolute) symbol type to signify that a
symbol is not subject to dynamic relocation.  However, the original A
type does not imply that at all, and depending on the version of the
toolchain, many A type symbols are emitted that are in fact relative to
the kernel text, i.e., if the kernel is relocated at runtime, these
symbols should be updated as well.

For instance, on sparc32, the following symbols are emitted as absolute
(kindly provided by Guenter Roeck):

  f035a420 A _etext
  f03d9000 A _sdata
  f03de8c4 A jiffies
  f03f8860 A _edata
  f03fc000 A __init_begin
  f041bdc8 A __init_text_end
  f0423000 A __bss_start
  f0423000 A __init_end
  f044457d A __bss_stop
  f044457d A _end

On x86_64, similar behavior can be observed:

  ffffffff81a00000 A __end_rodata_hpage_align
  ffffffff81b19000 A __vvar_page
  ffffffff81d3d000 A _end

Even if only a couple of them pass the symbol range check that results
in them to be taken into account for the final kallsyms symbol table, it
is obvious that 'A' does not mean the symbol does not need to be updated
at relocation time, and overloading its meaning to signify that is
perhaps not a good idea.

So instead, add a new percpu_absolute member to struct sym_entry, and
when --absolute-percpu is in effect, use it to record symbols whose
addresses should be emitted as final values rather than values that
still require relocation at runtime.  That way, we can drop the check
against the 'A' type.

Signed-off-by: Ard Biesheuvel 
Tested-by: Guenter Roeck 
Reviewed-by: Kees Cook 
Tested-by: Kees Cook 
Cc: Heiko Carstens 
Cc: Michael Ellerman 
Cc: Ingo Molnar 
Cc: H. Peter Anvin 
Cc: Benjamin Herrenschmidt 
Cc: Michal Marek 
Acked-by: Rusty Russell 
Cc: Arnd Bergmann 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Kbuild: kallsyms: drop special handling of pre-3.0 GCC symbols

2015-04-07T11:04:51+00:00

Since we have required at least GCC v3.2 for some time now, we
can drop the special handling of the 'gcc[0-9]_compiled.' label
which is not emitted anymore since GCC v3.0.

Signed-off-by: Ard Biesheuvel 
Signed-off-by: Michal Marek

Kbuild: kallsyms: ignore veneers emitted by the ARM linker

2015-04-07T11:04:50+00:00

When linking large kernels on ARM, the linker will insert veneers
(i.e., PLT like stubs) when function symbols are out of reach for
the ordinary relative branch/branch-and-link instructions.

However, due to the fact that the kallsyms region sits in .rodata,
which is between .text and .init.text, additional veneers may be
emitted in the second pass due to the fact that the size of the
kallsyms region itself has pushed the .init.text section further
apart, requiring even more veneers.

So ignore the veneers when generating the symbol table. Veneers
have no corresponding source code, and they will not turn up in
backtraces anyway.

This patch also lightly refactors the symbol_valid() function
to use a local 'sym_name' rather than the obfuscated 'sym + 1'
and 'sym + offset'

Signed-off-by: Ard Biesheuvel 
Signed-off-by: Michal Marek

aarch64: filter $x from kallsyms

2014-10-02T16:01:51+00:00

Similar to ARM, AArch64 is generating $x and $d syms... which isn't
terribly helpful when looking at %pF output and the like. Filter those
out in kallsyms, modpost and when looking at module symbols.

Seems simplest since none of these check EM_ARM anyway, to just add it
to the strchr used, rather than trying to make things overly
complicated.

initcall_debug improves:
dmesg_before.txt: initcall $x+0x0/0x154 [sg] returned 0 after 26331 usecs
dmesg_after.txt: initcall init_sg+0x0/0x154 [sg] returned 0 after 15461 usecs

Signed-off-by: Kyle McMartin 
Acked-by: Rusty Russell 
Signed-off-by: Catalin Marinas

kbuild: trivial - use tabs for code indent where possible

2014-06-10T12:00:53+00:00

Signed-off-by: Masahiro Yamada 
Signed-off-by: Michal Marek

kallsyms: fix percpu vars on x86-64 with relocation.

2014-03-17T04:25:27+00:00

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: Andy Honig 
Signed-off-by: Rusty Russell 
Acked-by: Kees Cook

kallsyms: generalize address range checking

2014-03-17T04:24:50+00:00

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: Kees Cook 
Signed-off-by: Rusty Russell