2014-11-24 15:54:35 +00:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2014 Linaro Ltd. <ard.biesheuvel@linaro.org>
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License version 2 as
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/elf.h>
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/module.h>
|
2016-08-17 11:45:21 +00:00
|
|
|
#include <linux/sort.h>
|
2014-11-24 15:54:35 +00:00
|
|
|
|
|
|
|
#include <asm/cache.h>
|
|
|
|
#include <asm/opcodes.h>
|
|
|
|
|
|
|
|
#define PLT_ENT_STRIDE L1_CACHE_BYTES
|
|
|
|
#define PLT_ENT_COUNT (PLT_ENT_STRIDE / sizeof(u32))
|
|
|
|
#define PLT_ENT_SIZE (sizeof(struct plt_entries) / PLT_ENT_COUNT)
|
|
|
|
|
|
|
|
#ifdef CONFIG_THUMB2_KERNEL
|
|
|
|
#define PLT_ENT_LDR __opcode_to_mem_thumb32(0xf8dff000 | \
|
|
|
|
(PLT_ENT_STRIDE - 4))
|
|
|
|
#else
|
|
|
|
#define PLT_ENT_LDR __opcode_to_mem_arm(0xe59ff000 | \
|
|
|
|
(PLT_ENT_STRIDE - 8))
|
|
|
|
#endif
|
|
|
|
|
|
|
|
struct plt_entries {
|
|
|
|
u32 ldr[PLT_ENT_COUNT];
|
|
|
|
u32 lit[PLT_ENT_COUNT];
|
|
|
|
};
|
|
|
|
|
|
|
|
u32 get_module_plt(struct module *mod, unsigned long loc, Elf32_Addr val)
|
|
|
|
{
|
ARM: kernel: avoid brute force search on PLT generation
Given that we now sort the relocation sections in a way that guarantees
that entries that can share a single PLT entry end up adjacently, there
is no a longer a need to go over the entire list to look for an existing
entry that matches our jump target. If such a match exists, it was the
last one to be emitted, so we can simply check the preceding slot.
Note that this will still work correctly in the [theoretical] presence of
call/jump relocations against SHN_UNDEF symbols with non-zero addends,
although not optimally. Since the relocations are presented in the same
order that we checked them for duplicates, any duplicates that we failed
to spot the first time around will be accounted for in the PLT allocation
so there is guaranteed to be sufficient space for them when actually
emitting the PLT.
For instance, the following sequence of relocations:
000004d8 00058b0a R_ARM_THM_CALL 00000000 warn_slowpath_null
000004fc 00058b0a R_ARM_THM_CALL 00000000 warn_slowpath_null
0000050e 00058b0a R_ARM_THM_CALL 00000000 warn_slowpath_null
00000520 00058b0a R_ARM_THM_CALL 00000000 warn_slowpath_null
00000532 00058b0a R_ARM_THM_CALL 00000000 warn_slowpath_null
00000544 00058b0a R_ARM_THM_CALL 00000000 warn_slowpath_null
00000556 00058b0a R_ARM_THM_CALL 00000000 warn_slowpath_null
00000568 00058b0a R_ARM_THM_CALL 00000000 warn_slowpath_null
0000057a 00058b0a R_ARM_THM_CALL 00000000 warn_slowpath_null
0000058c 00058b0a R_ARM_THM_CALL 00000000 warn_slowpath_null
0000059e 00058b0a R_ARM_THM_CALL 00000000 warn_slowpath_null
000005b0 00058b0a R_ARM_THM_CALL 00000000 warn_slowpath_null
000005c2 00058b0a R_ARM_THM_CALL 00000000 warn_slowpath_null
000005d4 00058b0a R_ARM_THM_CALL 00000000 warn_slowpath_null
may result in several PLT entries to be allocated, and also emitted, if
any of the entries in the middle refer to a Place that contains a non-zero
addend (i.e., one for all the preceding zero-addend relocations, one for
all the following zero-addend relocations, and one for the non-zero addend
relocation itself)
Tested-by: Jongsung Kim <neidhard.kim@lge.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2016-08-18 08:58:49 +00:00
|
|
|
struct plt_entries *plt = (struct plt_entries *)mod->arch.plt->sh_addr;
|
|
|
|
int idx = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Look for an existing entry pointing to 'val'. Given that the
|
|
|
|
* relocations are sorted, this will be the last entry we allocated.
|
|
|
|
* (if one exists).
|
|
|
|
*/
|
|
|
|
if (mod->arch.plt_count > 0) {
|
|
|
|
plt += (mod->arch.plt_count - 1) / PLT_ENT_COUNT;
|
|
|
|
idx = (mod->arch.plt_count - 1) % PLT_ENT_COUNT;
|
|
|
|
|
|
|
|
if (plt->lit[idx] == val)
|
|
|
|
return (u32)&plt->ldr[idx];
|
|
|
|
|
|
|
|
idx = (idx + 1) % PLT_ENT_COUNT;
|
|
|
|
if (!idx)
|
|
|
|
plt++;
|
2014-11-24 15:54:35 +00:00
|
|
|
}
|
ARM: kernel: avoid brute force search on PLT generation
Given that we now sort the relocation sections in a way that guarantees
that entries that can share a single PLT entry end up adjacently, there
is no a longer a need to go over the entire list to look for an existing
entry that matches our jump target. If such a match exists, it was the
last one to be emitted, so we can simply check the preceding slot.
Note that this will still work correctly in the [theoretical] presence of
call/jump relocations against SHN_UNDEF symbols with non-zero addends,
although not optimally. Since the relocations are presented in the same
order that we checked them for duplicates, any duplicates that we failed
to spot the first time around will be accounted for in the PLT allocation
so there is guaranteed to be sufficient space for them when actually
emitting the PLT.
For instance, the following sequence of relocations:
000004d8 00058b0a R_ARM_THM_CALL 00000000 warn_slowpath_null
000004fc 00058b0a R_ARM_THM_CALL 00000000 warn_slowpath_null
0000050e 00058b0a R_ARM_THM_CALL 00000000 warn_slowpath_null
00000520 00058b0a R_ARM_THM_CALL 00000000 warn_slowpath_null
00000532 00058b0a R_ARM_THM_CALL 00000000 warn_slowpath_null
00000544 00058b0a R_ARM_THM_CALL 00000000 warn_slowpath_null
00000556 00058b0a R_ARM_THM_CALL 00000000 warn_slowpath_null
00000568 00058b0a R_ARM_THM_CALL 00000000 warn_slowpath_null
0000057a 00058b0a R_ARM_THM_CALL 00000000 warn_slowpath_null
0000058c 00058b0a R_ARM_THM_CALL 00000000 warn_slowpath_null
0000059e 00058b0a R_ARM_THM_CALL 00000000 warn_slowpath_null
000005b0 00058b0a R_ARM_THM_CALL 00000000 warn_slowpath_null
000005c2 00058b0a R_ARM_THM_CALL 00000000 warn_slowpath_null
000005d4 00058b0a R_ARM_THM_CALL 00000000 warn_slowpath_null
may result in several PLT entries to be allocated, and also emitted, if
any of the entries in the middle refer to a Place that contains a non-zero
addend (i.e., one for all the preceding zero-addend relocations, one for
all the following zero-addend relocations, and one for the non-zero addend
relocation itself)
Tested-by: Jongsung Kim <neidhard.kim@lge.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2016-08-18 08:58:49 +00:00
|
|
|
|
|
|
|
mod->arch.plt_count++;
|
|
|
|
BUG_ON(mod->arch.plt_count * PLT_ENT_SIZE > mod->arch.plt->sh_size);
|
|
|
|
|
|
|
|
if (!idx)
|
|
|
|
/* Populate a new set of entries */
|
|
|
|
*plt = (struct plt_entries){
|
|
|
|
{ [0 ... PLT_ENT_COUNT - 1] = PLT_ENT_LDR, },
|
|
|
|
{ val, }
|
|
|
|
};
|
|
|
|
else
|
|
|
|
plt->lit[idx] = val;
|
|
|
|
|
|
|
|
return (u32)&plt->ldr[idx];
|
2014-11-24 15:54:35 +00:00
|
|
|
}
|
|
|
|
|
2016-08-17 11:45:21 +00:00
|
|
|
#define cmp_3way(a,b) ((a) < (b) ? -1 : (a) > (b))
|
|
|
|
|
|
|
|
static int cmp_rel(const void *a, const void *b)
|
2014-11-24 15:54:35 +00:00
|
|
|
{
|
2016-08-17 11:45:21 +00:00
|
|
|
const Elf32_Rel *x = a, *y = b;
|
2014-11-24 15:54:35 +00:00
|
|
|
int i;
|
|
|
|
|
2016-08-17 11:45:21 +00:00
|
|
|
/* sort by type and symbol index */
|
|
|
|
i = cmp_3way(ELF32_R_TYPE(x->r_info), ELF32_R_TYPE(y->r_info));
|
|
|
|
if (i == 0)
|
|
|
|
i = cmp_3way(ELF32_R_SYM(x->r_info), ELF32_R_SYM(y->r_info));
|
|
|
|
return i;
|
|
|
|
}
|
2014-11-24 15:54:35 +00:00
|
|
|
|
2016-08-17 11:45:21 +00:00
|
|
|
static bool is_zero_addend_relocation(Elf32_Addr base, const Elf32_Rel *rel)
|
|
|
|
{
|
|
|
|
u32 *tval = (u32 *)(base + rel->r_offset);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Do a bitwise compare on the raw addend rather than fully decoding
|
|
|
|
* the offset and doing an arithmetic comparison.
|
|
|
|
* Note that a zero-addend jump/call relocation is encoded taking the
|
|
|
|
* PC bias into account, i.e., -8 for ARM and -4 for Thumb2.
|
|
|
|
*/
|
|
|
|
switch (ELF32_R_TYPE(rel->r_info)) {
|
|
|
|
u16 upper, lower;
|
|
|
|
|
|
|
|
case R_ARM_THM_CALL:
|
|
|
|
case R_ARM_THM_JUMP24:
|
|
|
|
upper = __mem_to_opcode_thumb16(((u16 *)tval)[0]);
|
|
|
|
lower = __mem_to_opcode_thumb16(((u16 *)tval)[1]);
|
|
|
|
|
|
|
|
return (upper & 0x7ff) == 0x7ff && (lower & 0x2fff) == 0x2ffe;
|
|
|
|
|
|
|
|
case R_ARM_CALL:
|
|
|
|
case R_ARM_PC24:
|
|
|
|
case R_ARM_JUMP24:
|
|
|
|
return (__mem_to_opcode_arm(*tval) & 0xffffff) == 0xfffffe;
|
2014-11-24 15:54:35 +00:00
|
|
|
}
|
2016-08-17 11:45:21 +00:00
|
|
|
BUG();
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool duplicate_rel(Elf32_Addr base, const Elf32_Rel *rel, int num)
|
|
|
|
{
|
|
|
|
const Elf32_Rel *prev;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Entries are sorted by type and symbol index. That means that,
|
|
|
|
* if a duplicate entry exists, it must be in the preceding
|
|
|
|
* slot.
|
|
|
|
*/
|
|
|
|
if (!num)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
prev = rel + num - 1;
|
|
|
|
return cmp_rel(rel + num, prev) == 0 &&
|
|
|
|
is_zero_addend_relocation(base, prev);
|
2014-11-24 15:54:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Count how many PLT entries we may need */
|
ARM: kernel: allocate PLT entries only for external symbols
When CONFIG_ARM_MODULE_PLTS is enabled, jump and call instructions in
modules no longer need to be within 16 MB (8 MB for Thumb2) of their
targets. If they are further away, a PLT entry will be generated on the
fly for each of them, which extends the range to the entire 32-bit
address space.
However, since these PLT entries will become the branch targets of the
original jump and call instructions, the PLT itself needs to be in
range, or we end up in the same situation we started in. Since the PLT
is in a separate section, this essentially means that all jumps and calls
inside the same module must be resolvable without PLT entries.
The PLT allocation code executes before the module itself is loaded in
its final location, and so it has to use a worst-case estimate for
which jumps and calls will require an entry in the PLT at relocation
time. As an optimization, this code deduplicates entries pointing to
the same symbol, using a O(n^2) algorithm. However, it does not take
the above into account, i.e., that PLT entries will only be needed for
jump and call relocations against symbols that are not defined in the
module.
So disregard relocations against symbols that are defined in the module
itself.
As an additional minor optimization, ignore input sections that lack
the SHF_EXECINSTR flag. Since jump and call relocations operate on
executable instructions only, there is no need to look in sections that
do not contain executable code.
Tested-by: Jongsung Kim <neidhard.kim@lge.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2016-08-16 14:49:56 +00:00
|
|
|
static unsigned int count_plts(const Elf32_Sym *syms, Elf32_Addr base,
|
|
|
|
const Elf32_Rel *rel, int num)
|
2014-11-24 15:54:35 +00:00
|
|
|
{
|
|
|
|
unsigned int ret = 0;
|
ARM: kernel: allocate PLT entries only for external symbols
When CONFIG_ARM_MODULE_PLTS is enabled, jump and call instructions in
modules no longer need to be within 16 MB (8 MB for Thumb2) of their
targets. If they are further away, a PLT entry will be generated on the
fly for each of them, which extends the range to the entire 32-bit
address space.
However, since these PLT entries will become the branch targets of the
original jump and call instructions, the PLT itself needs to be in
range, or we end up in the same situation we started in. Since the PLT
is in a separate section, this essentially means that all jumps and calls
inside the same module must be resolvable without PLT entries.
The PLT allocation code executes before the module itself is loaded in
its final location, and so it has to use a worst-case estimate for
which jumps and calls will require an entry in the PLT at relocation
time. As an optimization, this code deduplicates entries pointing to
the same symbol, using a O(n^2) algorithm. However, it does not take
the above into account, i.e., that PLT entries will only be needed for
jump and call relocations against symbols that are not defined in the
module.
So disregard relocations against symbols that are defined in the module
itself.
As an additional minor optimization, ignore input sections that lack
the SHF_EXECINSTR flag. Since jump and call relocations operate on
executable instructions only, there is no need to look in sections that
do not contain executable code.
Tested-by: Jongsung Kim <neidhard.kim@lge.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2016-08-16 14:49:56 +00:00
|
|
|
const Elf32_Sym *s;
|
2014-11-24 15:54:35 +00:00
|
|
|
int i;
|
|
|
|
|
ARM: kernel: allocate PLT entries only for external symbols
When CONFIG_ARM_MODULE_PLTS is enabled, jump and call instructions in
modules no longer need to be within 16 MB (8 MB for Thumb2) of their
targets. If they are further away, a PLT entry will be generated on the
fly for each of them, which extends the range to the entire 32-bit
address space.
However, since these PLT entries will become the branch targets of the
original jump and call instructions, the PLT itself needs to be in
range, or we end up in the same situation we started in. Since the PLT
is in a separate section, this essentially means that all jumps and calls
inside the same module must be resolvable without PLT entries.
The PLT allocation code executes before the module itself is loaded in
its final location, and so it has to use a worst-case estimate for
which jumps and calls will require an entry in the PLT at relocation
time. As an optimization, this code deduplicates entries pointing to
the same symbol, using a O(n^2) algorithm. However, it does not take
the above into account, i.e., that PLT entries will only be needed for
jump and call relocations against symbols that are not defined in the
module.
So disregard relocations against symbols that are defined in the module
itself.
As an additional minor optimization, ignore input sections that lack
the SHF_EXECINSTR flag. Since jump and call relocations operate on
executable instructions only, there is no need to look in sections that
do not contain executable code.
Tested-by: Jongsung Kim <neidhard.kim@lge.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2016-08-16 14:49:56 +00:00
|
|
|
for (i = 0; i < num; i++) {
|
2014-11-24 15:54:35 +00:00
|
|
|
switch (ELF32_R_TYPE(rel[i].r_info)) {
|
|
|
|
case R_ARM_CALL:
|
|
|
|
case R_ARM_PC24:
|
|
|
|
case R_ARM_JUMP24:
|
|
|
|
case R_ARM_THM_CALL:
|
|
|
|
case R_ARM_THM_JUMP24:
|
ARM: kernel: allocate PLT entries only for external symbols
When CONFIG_ARM_MODULE_PLTS is enabled, jump and call instructions in
modules no longer need to be within 16 MB (8 MB for Thumb2) of their
targets. If they are further away, a PLT entry will be generated on the
fly for each of them, which extends the range to the entire 32-bit
address space.
However, since these PLT entries will become the branch targets of the
original jump and call instructions, the PLT itself needs to be in
range, or we end up in the same situation we started in. Since the PLT
is in a separate section, this essentially means that all jumps and calls
inside the same module must be resolvable without PLT entries.
The PLT allocation code executes before the module itself is loaded in
its final location, and so it has to use a worst-case estimate for
which jumps and calls will require an entry in the PLT at relocation
time. As an optimization, this code deduplicates entries pointing to
the same symbol, using a O(n^2) algorithm. However, it does not take
the above into account, i.e., that PLT entries will only be needed for
jump and call relocations against symbols that are not defined in the
module.
So disregard relocations against symbols that are defined in the module
itself.
As an additional minor optimization, ignore input sections that lack
the SHF_EXECINSTR flag. Since jump and call relocations operate on
executable instructions only, there is no need to look in sections that
do not contain executable code.
Tested-by: Jongsung Kim <neidhard.kim@lge.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2016-08-16 14:49:56 +00:00
|
|
|
/*
|
|
|
|
* We only have to consider branch targets that resolve
|
|
|
|
* to undefined symbols. This is not simply a heuristic,
|
|
|
|
* it is a fundamental limitation, since the PLT itself
|
|
|
|
* is part of the module, and needs to be within range
|
|
|
|
* as well, so modules can never grow beyond that limit.
|
|
|
|
*/
|
|
|
|
s = syms + ELF32_R_SYM(rel[i].r_info);
|
|
|
|
if (s->st_shndx != SHN_UNDEF)
|
|
|
|
break;
|
|
|
|
|
2016-08-17 11:45:21 +00:00
|
|
|
/*
|
|
|
|
* Jump relocations with non-zero addends against
|
|
|
|
* undefined symbols are supported by the ELF spec, but
|
|
|
|
* do not occur in practice (e.g., 'jump n bytes past
|
|
|
|
* the entry point of undefined function symbol f').
|
|
|
|
* So we need to support them, but there is no need to
|
|
|
|
* take them into consideration when trying to optimize
|
|
|
|
* this code. So let's only check for duplicates when
|
|
|
|
* the addend is zero.
|
|
|
|
*/
|
|
|
|
if (!is_zero_addend_relocation(base, rel + i) ||
|
|
|
|
!duplicate_rel(base, rel, i))
|
2014-11-24 15:54:35 +00:00
|
|
|
ret++;
|
|
|
|
}
|
ARM: kernel: allocate PLT entries only for external symbols
When CONFIG_ARM_MODULE_PLTS is enabled, jump and call instructions in
modules no longer need to be within 16 MB (8 MB for Thumb2) of their
targets. If they are further away, a PLT entry will be generated on the
fly for each of them, which extends the range to the entire 32-bit
address space.
However, since these PLT entries will become the branch targets of the
original jump and call instructions, the PLT itself needs to be in
range, or we end up in the same situation we started in. Since the PLT
is in a separate section, this essentially means that all jumps and calls
inside the same module must be resolvable without PLT entries.
The PLT allocation code executes before the module itself is loaded in
its final location, and so it has to use a worst-case estimate for
which jumps and calls will require an entry in the PLT at relocation
time. As an optimization, this code deduplicates entries pointing to
the same symbol, using a O(n^2) algorithm. However, it does not take
the above into account, i.e., that PLT entries will only be needed for
jump and call relocations against symbols that are not defined in the
module.
So disregard relocations against symbols that are defined in the module
itself.
As an additional minor optimization, ignore input sections that lack
the SHF_EXECINSTR flag. Since jump and call relocations operate on
executable instructions only, there is no need to look in sections that
do not contain executable code.
Tested-by: Jongsung Kim <neidhard.kim@lge.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2016-08-16 14:49:56 +00:00
|
|
|
}
|
2014-11-24 15:54:35 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
int module_frob_arch_sections(Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
|
|
|
|
char *secstrings, struct module *mod)
|
|
|
|
{
|
2016-08-16 15:21:02 +00:00
|
|
|
unsigned long plts = 0;
|
2014-11-24 15:54:35 +00:00
|
|
|
Elf32_Shdr *s, *sechdrs_end = sechdrs + ehdr->e_shnum;
|
ARM: kernel: allocate PLT entries only for external symbols
When CONFIG_ARM_MODULE_PLTS is enabled, jump and call instructions in
modules no longer need to be within 16 MB (8 MB for Thumb2) of their
targets. If they are further away, a PLT entry will be generated on the
fly for each of them, which extends the range to the entire 32-bit
address space.
However, since these PLT entries will become the branch targets of the
original jump and call instructions, the PLT itself needs to be in
range, or we end up in the same situation we started in. Since the PLT
is in a separate section, this essentially means that all jumps and calls
inside the same module must be resolvable without PLT entries.
The PLT allocation code executes before the module itself is loaded in
its final location, and so it has to use a worst-case estimate for
which jumps and calls will require an entry in the PLT at relocation
time. As an optimization, this code deduplicates entries pointing to
the same symbol, using a O(n^2) algorithm. However, it does not take
the above into account, i.e., that PLT entries will only be needed for
jump and call relocations against symbols that are not defined in the
module.
So disregard relocations against symbols that are defined in the module
itself.
As an additional minor optimization, ignore input sections that lack
the SHF_EXECINSTR flag. Since jump and call relocations operate on
executable instructions only, there is no need to look in sections that
do not contain executable code.
Tested-by: Jongsung Kim <neidhard.kim@lge.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2016-08-16 14:49:56 +00:00
|
|
|
Elf32_Sym *syms = NULL;
|
2014-11-24 15:54:35 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* To store the PLTs, we expand the .text section for core module code
|
2016-08-16 15:21:02 +00:00
|
|
|
* and for initialization code.
|
2014-11-24 15:54:35 +00:00
|
|
|
*/
|
ARM: kernel: allocate PLT entries only for external symbols
When CONFIG_ARM_MODULE_PLTS is enabled, jump and call instructions in
modules no longer need to be within 16 MB (8 MB for Thumb2) of their
targets. If they are further away, a PLT entry will be generated on the
fly for each of them, which extends the range to the entire 32-bit
address space.
However, since these PLT entries will become the branch targets of the
original jump and call instructions, the PLT itself needs to be in
range, or we end up in the same situation we started in. Since the PLT
is in a separate section, this essentially means that all jumps and calls
inside the same module must be resolvable without PLT entries.
The PLT allocation code executes before the module itself is loaded in
its final location, and so it has to use a worst-case estimate for
which jumps and calls will require an entry in the PLT at relocation
time. As an optimization, this code deduplicates entries pointing to
the same symbol, using a O(n^2) algorithm. However, it does not take
the above into account, i.e., that PLT entries will only be needed for
jump and call relocations against symbols that are not defined in the
module.
So disregard relocations against symbols that are defined in the module
itself.
As an additional minor optimization, ignore input sections that lack
the SHF_EXECINSTR flag. Since jump and call relocations operate on
executable instructions only, there is no need to look in sections that
do not contain executable code.
Tested-by: Jongsung Kim <neidhard.kim@lge.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2016-08-16 14:49:56 +00:00
|
|
|
for (s = sechdrs; s < sechdrs_end; ++s) {
|
2016-08-16 15:21:02 +00:00
|
|
|
if (strcmp(".plt", secstrings + s->sh_name) == 0)
|
|
|
|
mod->arch.plt = s;
|
ARM: kernel: allocate PLT entries only for external symbols
When CONFIG_ARM_MODULE_PLTS is enabled, jump and call instructions in
modules no longer need to be within 16 MB (8 MB for Thumb2) of their
targets. If they are further away, a PLT entry will be generated on the
fly for each of them, which extends the range to the entire 32-bit
address space.
However, since these PLT entries will become the branch targets of the
original jump and call instructions, the PLT itself needs to be in
range, or we end up in the same situation we started in. Since the PLT
is in a separate section, this essentially means that all jumps and calls
inside the same module must be resolvable without PLT entries.
The PLT allocation code executes before the module itself is loaded in
its final location, and so it has to use a worst-case estimate for
which jumps and calls will require an entry in the PLT at relocation
time. As an optimization, this code deduplicates entries pointing to
the same symbol, using a O(n^2) algorithm. However, it does not take
the above into account, i.e., that PLT entries will only be needed for
jump and call relocations against symbols that are not defined in the
module.
So disregard relocations against symbols that are defined in the module
itself.
As an additional minor optimization, ignore input sections that lack
the SHF_EXECINSTR flag. Since jump and call relocations operate on
executable instructions only, there is no need to look in sections that
do not contain executable code.
Tested-by: Jongsung Kim <neidhard.kim@lge.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2016-08-16 14:49:56 +00:00
|
|
|
else if (s->sh_type == SHT_SYMTAB)
|
|
|
|
syms = (Elf32_Sym *)s->sh_addr;
|
|
|
|
}
|
2014-11-24 15:54:35 +00:00
|
|
|
|
2016-08-16 15:21:02 +00:00
|
|
|
if (!mod->arch.plt) {
|
|
|
|
pr_err("%s: module PLT section missing\n", mod->name);
|
2014-11-24 15:54:35 +00:00
|
|
|
return -ENOEXEC;
|
|
|
|
}
|
ARM: kernel: allocate PLT entries only for external symbols
When CONFIG_ARM_MODULE_PLTS is enabled, jump and call instructions in
modules no longer need to be within 16 MB (8 MB for Thumb2) of their
targets. If they are further away, a PLT entry will be generated on the
fly for each of them, which extends the range to the entire 32-bit
address space.
However, since these PLT entries will become the branch targets of the
original jump and call instructions, the PLT itself needs to be in
range, or we end up in the same situation we started in. Since the PLT
is in a separate section, this essentially means that all jumps and calls
inside the same module must be resolvable without PLT entries.
The PLT allocation code executes before the module itself is loaded in
its final location, and so it has to use a worst-case estimate for
which jumps and calls will require an entry in the PLT at relocation
time. As an optimization, this code deduplicates entries pointing to
the same symbol, using a O(n^2) algorithm. However, it does not take
the above into account, i.e., that PLT entries will only be needed for
jump and call relocations against symbols that are not defined in the
module.
So disregard relocations against symbols that are defined in the module
itself.
As an additional minor optimization, ignore input sections that lack
the SHF_EXECINSTR flag. Since jump and call relocations operate on
executable instructions only, there is no need to look in sections that
do not contain executable code.
Tested-by: Jongsung Kim <neidhard.kim@lge.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2016-08-16 14:49:56 +00:00
|
|
|
if (!syms) {
|
|
|
|
pr_err("%s: module symtab section missing\n", mod->name);
|
|
|
|
return -ENOEXEC;
|
|
|
|
}
|
2014-11-24 15:54:35 +00:00
|
|
|
|
|
|
|
for (s = sechdrs + 1; s < sechdrs_end; ++s) {
|
2016-08-17 11:45:21 +00:00
|
|
|
Elf32_Rel *rels = (void *)ehdr + s->sh_offset;
|
2014-11-24 15:54:35 +00:00
|
|
|
int numrels = s->sh_size / sizeof(Elf32_Rel);
|
|
|
|
Elf32_Shdr *dstsec = sechdrs + s->sh_info;
|
|
|
|
|
|
|
|
if (s->sh_type != SHT_REL)
|
|
|
|
continue;
|
|
|
|
|
ARM: kernel: allocate PLT entries only for external symbols
When CONFIG_ARM_MODULE_PLTS is enabled, jump and call instructions in
modules no longer need to be within 16 MB (8 MB for Thumb2) of their
targets. If they are further away, a PLT entry will be generated on the
fly for each of them, which extends the range to the entire 32-bit
address space.
However, since these PLT entries will become the branch targets of the
original jump and call instructions, the PLT itself needs to be in
range, or we end up in the same situation we started in. Since the PLT
is in a separate section, this essentially means that all jumps and calls
inside the same module must be resolvable without PLT entries.
The PLT allocation code executes before the module itself is loaded in
its final location, and so it has to use a worst-case estimate for
which jumps and calls will require an entry in the PLT at relocation
time. As an optimization, this code deduplicates entries pointing to
the same symbol, using a O(n^2) algorithm. However, it does not take
the above into account, i.e., that PLT entries will only be needed for
jump and call relocations against symbols that are not defined in the
module.
So disregard relocations against symbols that are defined in the module
itself.
As an additional minor optimization, ignore input sections that lack
the SHF_EXECINSTR flag. Since jump and call relocations operate on
executable instructions only, there is no need to look in sections that
do not contain executable code.
Tested-by: Jongsung Kim <neidhard.kim@lge.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2016-08-16 14:49:56 +00:00
|
|
|
/* ignore relocations that operate on non-exec sections */
|
|
|
|
if (!(dstsec->sh_flags & SHF_EXECINSTR))
|
|
|
|
continue;
|
|
|
|
|
2016-08-17 11:45:21 +00:00
|
|
|
/* sort by type and symbol index */
|
|
|
|
sort(rels, numrels, sizeof(Elf32_Rel), cmp_rel, NULL);
|
|
|
|
|
ARM: kernel: allocate PLT entries only for external symbols
When CONFIG_ARM_MODULE_PLTS is enabled, jump and call instructions in
modules no longer need to be within 16 MB (8 MB for Thumb2) of their
targets. If they are further away, a PLT entry will be generated on the
fly for each of them, which extends the range to the entire 32-bit
address space.
However, since these PLT entries will become the branch targets of the
original jump and call instructions, the PLT itself needs to be in
range, or we end up in the same situation we started in. Since the PLT
is in a separate section, this essentially means that all jumps and calls
inside the same module must be resolvable without PLT entries.
The PLT allocation code executes before the module itself is loaded in
its final location, and so it has to use a worst-case estimate for
which jumps and calls will require an entry in the PLT at relocation
time. As an optimization, this code deduplicates entries pointing to
the same symbol, using a O(n^2) algorithm. However, it does not take
the above into account, i.e., that PLT entries will only be needed for
jump and call relocations against symbols that are not defined in the
module.
So disregard relocations against symbols that are defined in the module
itself.
As an additional minor optimization, ignore input sections that lack
the SHF_EXECINSTR flag. Since jump and call relocations operate on
executable instructions only, there is no need to look in sections that
do not contain executable code.
Tested-by: Jongsung Kim <neidhard.kim@lge.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2016-08-16 14:49:56 +00:00
|
|
|
plts += count_plts(syms, dstsec->sh_addr, rels, numrels);
|
2014-11-24 15:54:35 +00:00
|
|
|
}
|
|
|
|
|
2016-08-16 15:21:02 +00:00
|
|
|
mod->arch.plt->sh_type = SHT_NOBITS;
|
|
|
|
mod->arch.plt->sh_flags = SHF_EXECINSTR | SHF_ALLOC;
|
|
|
|
mod->arch.plt->sh_addralign = L1_CACHE_BYTES;
|
|
|
|
mod->arch.plt->sh_size = round_up(plts * PLT_ENT_SIZE,
|
|
|
|
sizeof(struct plt_entries));
|
|
|
|
mod->arch.plt_count = 0;
|
|
|
|
|
|
|
|
pr_debug("%s: plt=%x\n", __func__, mod->arch.plt->sh_size);
|
2014-11-24 15:54:35 +00:00
|
|
|
return 0;
|
|
|
|
}
|