ARM: Thumb-2: Relax relocation requirements for non-function symbols
PATCH 1/1 ARM: Thumb-2: Relax relocation requirements for non-function symbols
The "Thumb bit" of a symbol is only really meaningful for function symbols (STT_FUNC).
However, sometimes a branch is relocated against a non-function symbol; for example, PC-relative branches to anonymous assembler local symbols are typically fixed up against the start-of-section symbol, which is not a function symbol. Some inline assembler generates references of this type, such as fixup code generated by macros in <asm/uaccess.h>.
The existing relocation code for R_ARM_THM_CALL/R_ARM_THM_JUMP24 interprets this case as an error, because the target symbol appears to be an ARM symbol; but this is really not the case, since the target symbol is just a base in these cases. The addend defines the precise offset to the target location, but since the addend is encoded in a non-interworking Thumb branch instruction, there is no explicit Thumb bit in the addend. Because these instructions never interwork, the implied Thumb bit in the addend is 1, and the destination is Thumb by definition.
This patch removes the extraneous Thumb bit check for non-function symbols, enabling modules containing the affected relocation types to be loaded. No modification to the actual relocation code is required, since this code does not take bit[0] of the location->destination offset into account in any case.
Function symbols are always checked for interworking conflicts, as before.
---
[Reposting to give people a chance to comment.]
arch/arm/kernel/module.c | 13 +++++++++++-- 1 files changed, 11 insertions(+), 2 deletions(-)
arch/arm/kernel/module.c +11 -2
@@ -193,8 +193,17 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab, unsigned int symindex, offset -=0x02000000 ; offset += sym->st_value - loc; -/* only Thumb addresses allowed (no interworking) */ -if (!(offset &1 ) || +/* +* For function symbols, only Thumb addresses are +* allowed (no interworking). +* +* For non-function symbols, the destination +* has no specific ARM/Thumb disposition, so +* the branch is resolved under the assumption +* that interworking is not required. +*/ +if ((ELF32_ST_TYPE (sym->st_info) ==STT_FUNC && + !(offset &1 )) || offset <= (s32 )0xff000000 || offset >= (s32 )0x01000000 ) { pr_err("%s: section %u reloc %u sym '%s': relocation %u out of range (%#lx -> %#x)\n",
Signature · 1 line
1.7.4.1
PATCH 1/1 ARM: Thumb-2: Relax relocation requirements for non-function symbols
Quoted 26 lines · Dave Martin
The "Thumb bit" of a symbol is only really meaningful for function symbols (
STT_FUNC).However, sometimes a branch is relocated against a non-function symbol; for example, PC-relative branches to anonymous assembler local symbols are typically fixed up against the start-of-section symbol, which is not a function symbol. ?Some inline assembler generates references of this type, such as fixup code generated by macros in <
asm/uaccess.h>.The existing relocation code for R_ARM_THM_CALL/R_ARM_THM_JUMP24 interprets this case as an error, because the target symbol appears to be an ARM symbol; but this is really not the case, since the target symbol is just a base in these cases. ?The addend defines the precise offset to the target location, but since the addend is encoded in a non-interworking Thumb branch instruction, there is no explicit Thumb bit in the addend. ?Because these instructions never interwork, the implied Thumb bit in the addend is 1, and the destination is Thumb by definition.
This patch removes the extraneous Thumb bit check for non-function symbols, enabling modules containing the affected relocation types to be loaded. ?No modification to the actual relocation code is required, since this code does not take bit[0] of the
location->destinationoffset into account in any case.
Quoted 4 lines
Function symbols are always checked for interworking conflicts, as before.
Signed-off-by Dave Martin <[email protected]>
PATCH 1/1 ARM: Thumb-2: Relax relocation requirements for non-function symbols
Quoted 27 lines · Catalin Marinas
Quoted 26 lines · Dave Martin
The "Thumb bit" of a symbol is only really meaningful for function symbols (
STT_FUNC).However, sometimes a branch is relocated against a non-function symbol; for example, PC-relative branches to anonymous assembler local symbols are typically fixed up against the start-of-section symbol, which is not a function symbol. ?Some inline assembler generates references of this type, such as fixup code generated by macros in <
asm/uaccess.h>.The existing relocation code for R_ARM_THM_CALL/R_ARM_THM_JUMP24 interprets this case as an error, because the target symbol appears to be an ARM symbol; but this is really not the case, since the target symbol is just a base in these cases. ?The addend defines the precise offset to the target location, but since the addend is encoded in a non-interworking Thumb branch instruction, there is no explicit Thumb bit in the addend. ?Because these instructions never interwork, the implied Thumb bit in the addend is 1, and the destination is Thumb by definition.
This patch removes the extraneous Thumb bit check for non-function symbols, enabling modules containing the affected relocation types to be loaded. ?No modification to the actual relocation code is required, since this code does not take bit[0] of the
location->destinationoffset into account in any case.
Quoted 6 lines
Quoted 4 lines
Function symbols are always checked for interworking conflicts, as before.
Signed-off-by Dave Martin <[email protected]>Acked-by Catalin Marinas <[email protected]>
Thanks
---Dave
PATCH 1/1 ARM: Thumb-2: Relax relocation requirements for non-function symbols
In reply to Dave MartinQuoted 20 lines · Dave Martin
The "Thumb bit" of a symbol is only really meaningful for function symbols (
STT_FUNC).However, sometimes a branch is relocated against a non-function symbol; for example, PC-relative branches to anonymous assembler local symbols are typically fixed up against the start-of-section symbol, which is not a function symbol. Some inline assembler generates references of this type, such as fixup code generated by macros in <
asm/uaccess.h>.The existing relocation code for R_ARM_THM_CALL/R_ARM_THM_JUMP24 interprets this case as an error, because the target symbol appears to be an ARM symbol; but this is really not the case, since the target symbol is just a base in these cases. The addend defines the precise offset to the target location, but since the addend is encoded in a non-interworking Thumb branch instruction, there is no explicit Thumb bit in the addend. Because these instructions never interwork, the implied Thumb bit in the addend is 1, and the destination is Thumb by definition.
Quoted 8 lines
This patch removes the extraneous Thumb bit check for non-function symbols, enabling modules containing the affected relocation types to be loaded. No modification to the actual relocation code is required, since this code does not take bit[0] of the
location->destinationoffset into account in any case.Function symbols are always checked for interworking conflicts, as before.
The checks in both Thumb and ARM relocation code to prevent interworking mean that BLX instructions can't be relocated. Does this mean that:
a) We don't care about BLX instructions as they shouldn't normally be produced (except in my kprobe test cases ;-)
b) We should remove the checks in the relocation code preventing interworking.
c) We should have the toolchain create a new interworking relocation type.
d) ?
Signature · 1 line
Tixy
PATCH 1/1 ARM: Thumb-2: Relax relocation requirements for non-function symbols
Quoted 27 lines · Tixy
Quoted 26 lines · Dave Martin
The "Thumb bit" of a symbol is only really meaningful for function symbols (
STT_FUNC).However, sometimes a branch is relocated against a non-function symbol; for example, PC-relative branches to anonymous assembler local symbols are typically fixed up against the start-of-section symbol, which is not a function symbol. Some inline assembler generates references of this type, such as fixup code generated by macros in <
asm/uaccess.h>.The existing relocation code for R_ARM_THM_CALL/R_ARM_THM_JUMP24 interprets this case as an error, because the target symbol appears to be an ARM symbol; but this is really not the case, since the target symbol is just a base in these cases. The addend defines the precise offset to the target location, but since the addend is encoded in a non-interworking Thumb branch instruction, there is no explicit Thumb bit in the addend. Because these instructions never interwork, the implied Thumb bit in the addend is 1, and the destination is Thumb by definition.
This patch removes the extraneous Thumb bit check for non-function symbols, enabling modules containing the affected relocation types to be loaded. No modification to the actual relocation code is required, since this code does not take bit[0] of the
location->destinationoffset into account in any case.
Quoted 8 lines
Quoted 2 lines
Function symbols are always checked for interworking conflicts, as before.
The checks in both Thumb and ARM relocation code to prevent interworking mean that BLX instructions can't be relocated. Does this mean that:
a) We don't care about BLX instructions as they shouldn't normally be produced (except in my kprobe test cases ;-)
The tools generate B and BL for branches whose target is unknown and for which a relocation is needed. These get accompanying relocations which will cause the instructions to get rewritten as BLX (or veneers will be introduced) is interworking is discovered to be necessary at link time.
BX and BLX instructions are not relocatable: basically, these instructions should only exist when the target instruction set is known; i.e. after relocation processing, or for hard internal fixups which don't need any further relocation.
This summarises the possibilities:
Source ISA Target ISA instruction
ARM ARM B or BL
ARM Thumb BX or BLX
ARM undefined B or BL, + relocation
Thumb ARM BX or BLX
Thumb Thumb B or BL
Thumb undefined B or BL, + relocation
(Note that as a consequence of the ARM EABI, a relocation referencing an undefined symbol always has an undefined target ISA. I think EABI has no concept of a non-interworking relocatable branch.)
Since the kernel doesn't pretend to cope with interworking internally, we don't need to handle BX and BLX generation for relocation purposes. There is much assembler code in the kernel which is broken (or at least, not explicitly intended to work) for interworking, so we can't easily support that; nor is there any great benefit in supporting it.
So, we should never turn a B or BL into BX/BLX when applying relocations in kernel modules; and if it looks like we need to (because the target symbol has the wrong ISA) then that's a bug.
The patch attempts to resolve a bogus false positive of that check.
Quoted 2 lines
b) We should remove the checks in the relocation code preventing interworking.
The main usefulness of these checks was to flag up accidental loading of Thumb-2 modules into ARM kernels and vice-versa. We now have information in the module version magic to avoid that, but I think it's still sensible to sanity-check these relocations when loading modules. It doesn't add much code, and people may still occasionally get things wrong.
Quoted 2 lines
c) We should have the toolchain create a new interworking relocation type.
There should be no need, as described above.
Cheers
---Dave