2019-05-26 23:55:05 -07:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2005-04-16 15:20:36 -07:00
|
|
|
/* Kernel module help for PPC64.
|
|
|
|
Copyright (C) 2001, 2003 Rusty Russell IBM Corporation.
|
|
|
|
|
|
|
|
*/
|
2014-09-16 21:39:35 -07:00
|
|
|
|
|
|
|
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/elf.h>
|
|
|
|
#include <linux/moduleloader.h>
|
|
|
|
#include <linux/err.h>
|
|
|
|
#include <linux/vmalloc.h>
|
2008-11-14 21:47:03 -07:00
|
|
|
#include <linux/ftrace.h>
|
2006-12-08 04:30:41 -07:00
|
|
|
#include <linux/bug.h>
|
2014-04-03 02:00:43 -07:00
|
|
|
#include <linux/uaccess.h>
|
2022-02-23 00:54:23 -07:00
|
|
|
#include <linux/kernel.h>
|
2005-04-16 15:20:36 -07:00
|
|
|
#include <asm/module.h>
|
2006-10-19 18:47:19 -07:00
|
|
|
#include <asm/firmware.h>
|
2008-06-23 18:32:35 -07:00
|
|
|
#include <asm/code-patching.h>
|
2007-11-13 09:24:04 -07:00
|
|
|
#include <linux/sort.h>
|
2013-10-28 07:20:51 -07:00
|
|
|
#include <asm/setup.h>
|
2016-03-02 21:26:56 -07:00
|
|
|
#include <asm/sections.h>
|
2020-05-05 20:40:26 -07:00
|
|
|
#include <asm/inst.h>
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
/* FIXME: We don't do .init separately. To do this, we'd need to have
|
|
|
|
a separate r2 value in the init and core section, and stub between
|
|
|
|
them, too.
|
|
|
|
|
|
|
|
Using a magic allocator which places modules within 32MB solves
|
|
|
|
this, and makes other things simpler. Anton?
|
|
|
|
--RR. */
|
|
|
|
|
2022-11-27 21:15:37 -07:00
|
|
|
bool module_elf_check_arch(Elf_Ehdr *hdr)
|
|
|
|
{
|
|
|
|
unsigned long abi_level = hdr->e_flags & 0x3;
|
|
|
|
|
|
|
|
if (IS_ENABLED(CONFIG_PPC64_ELF_ABI_V2))
|
|
|
|
return abi_level == 2;
|
|
|
|
else
|
|
|
|
return abi_level < 2;
|
|
|
|
}
|
|
|
|
|
2022-05-08 22:36:07 -07:00
|
|
|
#ifdef CONFIG_PPC64_ELF_ABI_V2
|
2014-03-18 17:12:22 -07:00
|
|
|
|
|
|
|
static func_desc_t func_desc(unsigned long addr)
|
|
|
|
{
|
2022-02-15 05:41:00 -07:00
|
|
|
func_desc_t desc = {
|
|
|
|
.addr = addr,
|
|
|
|
};
|
|
|
|
|
|
|
|
return desc;
|
2014-03-18 17:12:22 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/* PowerPC64 specific values for the Elf64_Sym st_other field. */
|
|
|
|
#define STO_PPC64_LOCAL_BIT 5
|
|
|
|
#define STO_PPC64_LOCAL_MASK (7 << STO_PPC64_LOCAL_BIT)
|
|
|
|
#define PPC64_LOCAL_ENTRY_OFFSET(other) \
|
|
|
|
(((1 << (((other) & STO_PPC64_LOCAL_MASK) >> STO_PPC64_LOCAL_BIT)) >> 2) << 2)
|
|
|
|
|
|
|
|
static unsigned int local_entry_offset(const Elf64_Sym *sym)
|
|
|
|
{
|
|
|
|
/* sym->st_other indicates offset to local entry point
|
|
|
|
* (otherwise it will assume r12 is the address of the start
|
|
|
|
* of function and try to derive r2 from it). */
|
|
|
|
return PPC64_LOCAL_ENTRY_OFFSET(sym->st_other);
|
|
|
|
}
|
2014-03-18 02:42:44 -07:00
|
|
|
#else
|
2014-03-18 17:12:22 -07:00
|
|
|
|
|
|
|
static func_desc_t func_desc(unsigned long addr)
|
|
|
|
{
|
2022-02-15 05:40:58 -07:00
|
|
|
return *(struct func_desc *)addr;
|
2014-03-18 17:12:22 -07:00
|
|
|
}
|
|
|
|
static unsigned int local_entry_offset(const Elf64_Sym *sym)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
2017-11-09 16:48:27 -07:00
|
|
|
|
|
|
|
void *dereference_module_function_descriptor(struct module *mod, void *ptr)
|
|
|
|
{
|
|
|
|
if (ptr < (void *)mod->arch.start_opd ||
|
|
|
|
ptr >= (void *)mod->arch.end_opd)
|
|
|
|
return ptr;
|
|
|
|
|
|
|
|
return dereference_function_descriptor(ptr);
|
|
|
|
}
|
2014-03-18 02:42:44 -07:00
|
|
|
#endif
|
|
|
|
|
2022-02-15 05:41:00 -07:00
|
|
|
static unsigned long func_addr(unsigned long addr)
|
|
|
|
{
|
|
|
|
return func_desc(addr).addr;
|
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned long stub_func_addr(func_desc_t func)
|
|
|
|
{
|
|
|
|
return func.addr;
|
|
|
|
}
|
|
|
|
|
powerpc/module: Mark module stubs with a magic value
When a module is loaded, calls out to the kernel go via a stub which is
generated at runtime. One of these stubs is used to call _mcount(),
which is the default target of tracing calls generated by the compiler
with -pg.
If dynamic ftrace is enabled (which it typically is), another stub is
used to call ftrace_caller(), which is the target of tracing calls when
ftrace is actually active.
ftrace then wants to disable the calls to _mcount() at module startup,
and enable/disable the calls to ftrace_caller() when enabling/disabling
tracing - all of these it does by patching the code.
As part of that code patching, the ftrace code wants to confirm that the
branch it is about to modify, is in fact a call to a module stub which
calls _mcount() or ftrace_caller().
Currently it does that by inspecting the instructions and confirming
they are what it expects. Although that works, the code to do it is
pretty intricate because it requires lots of knowledge about the exact
format of the stub.
We can make that process easier by marking the generated stubs with a
magic value, and then looking for that magic value. Altough this is not
as rigorous as the current method, I believe it is sufficient in
practice.
Reviewed-by: Balbir Singh <bsingharora@gmail.com>
Reviewed-by: Torsten Duwe <duwe@suse.de>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-03-02 21:26:55 -07:00
|
|
|
#define STUB_MAGIC 0x73747562 /* stub */
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
/* Like PPC32, we need little trampolines to do > 24-bit jumps (into
|
|
|
|
the kernel itself). But on PPC64, these need to be used for every
|
|
|
|
jump, actually, to reset r2 (TOC+0x8000). */
|
2023-04-07 19:17:51 -07:00
|
|
|
struct ppc64_stub_entry {
|
|
|
|
/*
|
|
|
|
* 28 byte jump instruction sequence (7 instructions) that can
|
|
|
|
* hold ppc64_stub_insns or stub_insns. Must be 8-byte aligned
|
|
|
|
* with PCREL kernels that use prefix instructions in the stub.
|
|
|
|
*/
|
2014-03-18 00:05:28 -07:00
|
|
|
u32 jump[7];
|
powerpc/module: Mark module stubs with a magic value
When a module is loaded, calls out to the kernel go via a stub which is
generated at runtime. One of these stubs is used to call _mcount(),
which is the default target of tracing calls generated by the compiler
with -pg.
If dynamic ftrace is enabled (which it typically is), another stub is
used to call ftrace_caller(), which is the target of tracing calls when
ftrace is actually active.
ftrace then wants to disable the calls to _mcount() at module startup,
and enable/disable the calls to ftrace_caller() when enabling/disabling
tracing - all of these it does by patching the code.
As part of that code patching, the ftrace code wants to confirm that the
branch it is about to modify, is in fact a call to a module stub which
calls _mcount() or ftrace_caller().
Currently it does that by inspecting the instructions and confirming
they are what it expects. Although that works, the code to do it is
pretty intricate because it requires lots of knowledge about the exact
format of the stub.
We can make that process easier by marking the generated stubs with a
magic value, and then looking for that magic value. Altough this is not
as rigorous as the current method, I believe it is sufficient in
practice.
Reviewed-by: Balbir Singh <bsingharora@gmail.com>
Reviewed-by: Torsten Duwe <duwe@suse.de>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-03-02 21:26:55 -07:00
|
|
|
/* Used by ftrace to identify stubs */
|
|
|
|
u32 magic;
|
2005-04-16 15:20:36 -07:00
|
|
|
/* Data for the above code */
|
2014-03-18 17:12:22 -07:00
|
|
|
func_desc_t funcdata;
|
2023-04-07 19:17:51 -07:00
|
|
|
} __aligned(8);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-04-07 19:17:52 -07:00
|
|
|
struct ppc64_got_entry {
|
|
|
|
u64 addr;
|
|
|
|
};
|
|
|
|
|
2014-03-18 02:43:03 -07:00
|
|
|
/*
|
|
|
|
* PPC64 uses 24 bit jumps, but we need to jump into other modules or
|
|
|
|
* the kernel which may be further. So we jump to a stub.
|
|
|
|
*
|
2023-04-07 19:17:52 -07:00
|
|
|
* Target address and TOC are loaded from function descriptor in the
|
|
|
|
* ppc64_stub_entry.
|
|
|
|
*
|
|
|
|
* r12 is used to generate the target address, which is required for the
|
|
|
|
* ELFv2 global entry point calling convention.
|
2014-03-18 02:43:03 -07:00
|
|
|
*
|
2023-04-07 19:17:52 -07:00
|
|
|
* TOC handling:
|
|
|
|
* - PCREL does not have a TOC.
|
|
|
|
* - ELFv2 non-PCREL just has to save r2, the callee is responsible for
|
|
|
|
* setting its own TOC pointer at the global entry address.
|
|
|
|
* - ELFv1 must load the new TOC pointer from the function descriptor.
|
2014-03-18 02:43:03 -07:00
|
|
|
*/
|
2014-04-03 02:00:43 -07:00
|
|
|
static u32 ppc64_stub_insns[] = {
|
2023-04-07 19:17:52 -07:00
|
|
|
#ifdef CONFIG_PPC_KERNEL_PCREL
|
|
|
|
/* pld r12,addr */
|
|
|
|
PPC_PREFIX_8LS | __PPC_PRFX_R(1),
|
|
|
|
PPC_INST_PLD | ___PPC_RT(_R12),
|
|
|
|
#else
|
2021-05-20 03:23:04 -07:00
|
|
|
PPC_RAW_ADDIS(_R11, _R2, 0),
|
|
|
|
PPC_RAW_ADDI(_R11, _R11, 0),
|
2013-09-20 11:42:20 -07:00
|
|
|
/* Save current r2 value in magic place on the stack. */
|
2021-05-20 03:23:04 -07:00
|
|
|
PPC_RAW_STD(_R2, _R1, R2_STACK_OFFSET),
|
|
|
|
PPC_RAW_LD(_R12, _R11, 32),
|
2022-05-08 22:36:07 -07:00
|
|
|
#ifdef CONFIG_PPC64_ELF_ABI_V1
|
2014-03-18 02:43:03 -07:00
|
|
|
/* Set up new r2 from function descriptor */
|
2021-05-20 03:23:04 -07:00
|
|
|
PPC_RAW_LD(_R2, _R11, 40),
|
2023-04-07 19:17:52 -07:00
|
|
|
#endif
|
2014-03-18 02:43:03 -07:00
|
|
|
#endif
|
2021-05-20 03:23:04 -07:00
|
|
|
PPC_RAW_MTCTR(_R12),
|
|
|
|
PPC_RAW_BCTR(),
|
2014-04-03 02:00:43 -07:00
|
|
|
};
|
|
|
|
|
2023-04-07 19:17:52 -07:00
|
|
|
/*
|
|
|
|
* Count how many different r_type relocations (different symbol,
|
|
|
|
* different addend).
|
|
|
|
*/
|
|
|
|
static unsigned int count_relocs(const Elf64_Rela *rela, unsigned int num,
|
|
|
|
unsigned long r_type)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
2007-11-13 09:24:04 -07:00
|
|
|
unsigned int i, r_info, r_addend, _count_relocs;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
/* FIXME: Only count external ones --RR */
|
2007-11-13 09:24:04 -07:00
|
|
|
_count_relocs = 0;
|
|
|
|
r_info = 0;
|
|
|
|
r_addend = 0;
|
|
|
|
for (i = 0; i < num; i++)
|
2023-04-07 19:17:52 -07:00
|
|
|
/* Only count r_type relocs, others don't need stubs */
|
|
|
|
if (ELF64_R_TYPE(rela[i].r_info) == r_type &&
|
2007-11-13 09:24:04 -07:00
|
|
|
(r_info != ELF64_R_SYM(rela[i].r_info) ||
|
|
|
|
r_addend != rela[i].r_addend)) {
|
|
|
|
_count_relocs++;
|
|
|
|
r_info = ELF64_R_SYM(rela[i].r_info);
|
|
|
|
r_addend = rela[i].r_addend;
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
2007-11-13 09:24:04 -07:00
|
|
|
|
|
|
|
return _count_relocs;
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
2007-11-13 09:24:04 -07:00
|
|
|
static int relacmp(const void *_x, const void *_y)
|
|
|
|
{
|
|
|
|
const Elf64_Rela *x, *y;
|
|
|
|
|
|
|
|
y = (Elf64_Rela *)_x;
|
|
|
|
x = (Elf64_Rela *)_y;
|
|
|
|
|
|
|
|
/* Compare the entire r_info (as opposed to ELF64_R_SYM(r_info) only) to
|
|
|
|
* make the comparison cheaper/faster. It won't affect the sorting or
|
|
|
|
* the counting algorithms' performance
|
|
|
|
*/
|
|
|
|
if (x->r_info < y->r_info)
|
|
|
|
return -1;
|
|
|
|
else if (x->r_info > y->r_info)
|
|
|
|
return 1;
|
|
|
|
else if (x->r_addend < y->r_addend)
|
|
|
|
return -1;
|
|
|
|
else if (x->r_addend > y->r_addend)
|
|
|
|
return 1;
|
|
|
|
else
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
/* Get size of potential trampolines required. */
|
|
|
|
static unsigned long get_stubs_size(const Elf64_Ehdr *hdr,
|
|
|
|
const Elf64_Shdr *sechdrs)
|
|
|
|
{
|
2022-02-15 05:40:58 -07:00
|
|
|
/* One extra reloc so it's always 0-addr terminated */
|
2005-04-16 15:20:36 -07:00
|
|
|
unsigned long relocs = 1;
|
|
|
|
unsigned i;
|
|
|
|
|
|
|
|
/* Every relocated section... */
|
|
|
|
for (i = 1; i < hdr->e_shnum; i++) {
|
|
|
|
if (sechdrs[i].sh_type == SHT_RELA) {
|
2014-09-16 21:39:35 -07:00
|
|
|
pr_debug("Found relocations in section %u\n", i);
|
|
|
|
pr_debug("Ptr: %p. Number: %Lu\n",
|
2005-04-16 15:20:36 -07:00
|
|
|
(void *)sechdrs[i].sh_addr,
|
|
|
|
sechdrs[i].sh_size / sizeof(Elf64_Rela));
|
2007-11-13 09:24:04 -07:00
|
|
|
|
|
|
|
/* Sort the relocation information based on a symbol and
|
|
|
|
* addend key. This is a stable O(n*log n) complexity
|
2022-04-30 11:56:54 -07:00
|
|
|
* algorithm but it will reduce the complexity of
|
2007-11-13 09:24:04 -07:00
|
|
|
* count_relocs() to linear complexity O(n)
|
|
|
|
*/
|
|
|
|
sort((void *)sechdrs[i].sh_addr,
|
|
|
|
sechdrs[i].sh_size / sizeof(Elf64_Rela),
|
2019-04-02 13:47:22 -07:00
|
|
|
sizeof(Elf64_Rela), relacmp, NULL);
|
2007-11-13 09:24:04 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
relocs += count_relocs((void *)sechdrs[i].sh_addr,
|
|
|
|
sechdrs[i].sh_size
|
2023-04-07 19:17:52 -07:00
|
|
|
/ sizeof(Elf64_Rela),
|
|
|
|
R_PPC_REL24);
|
|
|
|
#ifdef CONFIG_PPC_KERNEL_PCREL
|
|
|
|
relocs += count_relocs((void *)sechdrs[i].sh_addr,
|
|
|
|
sechdrs[i].sh_size
|
|
|
|
/ sizeof(Elf64_Rela),
|
|
|
|
R_PPC64_REL24_NOTOC);
|
|
|
|
#endif
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-11-14 21:47:03 -07:00
|
|
|
#ifdef CONFIG_DYNAMIC_FTRACE
|
|
|
|
/* make the trampoline to the ftrace_caller */
|
|
|
|
relocs++;
|
2018-04-19 00:04:09 -07:00
|
|
|
#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
|
|
|
|
/* an additional one for ftrace_regs_caller */
|
|
|
|
relocs++;
|
|
|
|
#endif
|
2008-11-14 21:47:03 -07:00
|
|
|
#endif
|
|
|
|
|
2014-09-16 21:39:35 -07:00
|
|
|
pr_debug("Looks like a total of %lu stubs, max\n", relocs);
|
2005-04-16 15:20:36 -07:00
|
|
|
return relocs * sizeof(struct ppc64_stub_entry);
|
|
|
|
}
|
|
|
|
|
2023-04-07 19:17:52 -07:00
|
|
|
#ifdef CONFIG_PPC_KERNEL_PCREL
|
|
|
|
static int count_pcpu_relocs(const Elf64_Shdr *sechdrs,
|
|
|
|
const Elf64_Rela *rela, unsigned int num,
|
|
|
|
unsigned int symindex, unsigned int pcpu)
|
|
|
|
{
|
|
|
|
unsigned int i, r_info, r_addend, _count_relocs;
|
|
|
|
|
|
|
|
_count_relocs = 0;
|
|
|
|
r_info = 0;
|
|
|
|
r_addend = 0;
|
|
|
|
|
|
|
|
for (i = 0; i < num; i++) {
|
|
|
|
Elf64_Sym *sym;
|
|
|
|
|
|
|
|
/* This is the symbol it is referring to */
|
|
|
|
sym = (Elf64_Sym *)sechdrs[symindex].sh_addr
|
|
|
|
+ ELF64_R_SYM(rela[i].r_info);
|
|
|
|
|
|
|
|
if (sym->st_shndx == pcpu &&
|
|
|
|
(r_info != ELF64_R_SYM(rela[i].r_info) ||
|
|
|
|
r_addend != rela[i].r_addend)) {
|
|
|
|
_count_relocs++;
|
|
|
|
r_info = ELF64_R_SYM(rela[i].r_info);
|
|
|
|
r_addend = rela[i].r_addend;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return _count_relocs;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Get size of potential GOT required. */
|
|
|
|
static unsigned long get_got_size(const Elf64_Ehdr *hdr,
|
|
|
|
const Elf64_Shdr *sechdrs,
|
|
|
|
struct module *me)
|
|
|
|
{
|
|
|
|
/* One extra reloc so it's always 0-addr terminated */
|
|
|
|
unsigned long relocs = 1;
|
|
|
|
unsigned int i, symindex = 0;
|
|
|
|
|
|
|
|
for (i = 1; i < hdr->e_shnum; i++) {
|
|
|
|
if (sechdrs[i].sh_type == SHT_SYMTAB) {
|
|
|
|
symindex = i;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
WARN_ON_ONCE(!symindex);
|
|
|
|
|
|
|
|
/* Every relocated section... */
|
|
|
|
for (i = 1; i < hdr->e_shnum; i++) {
|
|
|
|
if (sechdrs[i].sh_type == SHT_RELA) {
|
|
|
|
pr_debug("Found relocations in section %u\n", i);
|
|
|
|
pr_debug("Ptr: %p. Number: %llu\n", (void *)sechdrs[i].sh_addr,
|
|
|
|
sechdrs[i].sh_size / sizeof(Elf64_Rela));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Sort the relocation information based on a symbol and
|
|
|
|
* addend key. This is a stable O(n*log n) complexity
|
|
|
|
* algorithm but it will reduce the complexity of
|
|
|
|
* count_relocs() to linear complexity O(n)
|
|
|
|
*/
|
|
|
|
sort((void *)sechdrs[i].sh_addr,
|
|
|
|
sechdrs[i].sh_size / sizeof(Elf64_Rela),
|
|
|
|
sizeof(Elf64_Rela), relacmp, NULL);
|
|
|
|
|
|
|
|
relocs += count_relocs((void *)sechdrs[i].sh_addr,
|
|
|
|
sechdrs[i].sh_size
|
|
|
|
/ sizeof(Elf64_Rela),
|
|
|
|
R_PPC64_GOT_PCREL34);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Percpu data access typically gets linked with
|
|
|
|
* REL34 relocations, but the percpu section gets
|
|
|
|
* moved at load time and requires that to be
|
|
|
|
* converted to GOT linkage.
|
|
|
|
*/
|
|
|
|
if (IS_ENABLED(CONFIG_SMP) && symindex)
|
|
|
|
relocs += count_pcpu_relocs(sechdrs,
|
|
|
|
(void *)sechdrs[i].sh_addr,
|
|
|
|
sechdrs[i].sh_size
|
|
|
|
/ sizeof(Elf64_Rela),
|
|
|
|
symindex, me->arch.pcpu_section);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
pr_debug("Looks like a total of %lu GOT entries, max\n", relocs);
|
|
|
|
return relocs * sizeof(struct ppc64_got_entry);
|
|
|
|
}
|
|
|
|
#else /* CONFIG_PPC_KERNEL_PCREL */
|
|
|
|
|
2014-03-18 02:41:28 -07:00
|
|
|
/* Still needed for ELFv2, for .TOC. */
|
2005-04-16 15:20:36 -07:00
|
|
|
static void dedotify_versions(struct modversion_info *vers,
|
|
|
|
unsigned long size)
|
|
|
|
{
|
|
|
|
struct modversion_info *end;
|
|
|
|
|
|
|
|
for (end = (void *)vers + size; vers < end; vers++)
|
2014-06-24 01:53:59 -07:00
|
|
|
if (vers->name[0] == '.') {
|
2005-04-16 15:20:36 -07:00
|
|
|
memmove(vers->name, vers->name+1, strlen(vers->name));
|
2014-06-24 01:53:59 -07:00
|
|
|
}
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
2016-01-15 02:52:22 -07:00
|
|
|
/*
|
|
|
|
* Undefined symbols which refer to .funcname, hack to funcname. Make .TOC.
|
|
|
|
* seem to be defined (value set later).
|
|
|
|
*/
|
2005-04-16 15:20:36 -07:00
|
|
|
static void dedotify(Elf64_Sym *syms, unsigned int numsyms, char *strtab)
|
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
for (i = 1; i < numsyms; i++) {
|
|
|
|
if (syms[i].st_shndx == SHN_UNDEF) {
|
|
|
|
char *name = strtab + syms[i].st_name;
|
2016-01-15 02:52:22 -07:00
|
|
|
if (name[0] == '.') {
|
|
|
|
if (strcmp(name+1, "TOC.") == 0)
|
|
|
|
syms[i].st_shndx = SHN_ABS;
|
2016-02-05 11:50:03 -07:00
|
|
|
syms[i].st_name++;
|
2016-01-15 02:52:22 -07:00
|
|
|
}
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-03-18 02:29:26 -07:00
|
|
|
static Elf64_Sym *find_dot_toc(Elf64_Shdr *sechdrs,
|
|
|
|
const char *strtab,
|
|
|
|
unsigned int symindex)
|
|
|
|
{
|
|
|
|
unsigned int i, numsyms;
|
|
|
|
Elf64_Sym *syms;
|
|
|
|
|
|
|
|
syms = (Elf64_Sym *)sechdrs[symindex].sh_addr;
|
|
|
|
numsyms = sechdrs[symindex].sh_size / sizeof(Elf64_Sym);
|
|
|
|
|
|
|
|
for (i = 1; i < numsyms; i++) {
|
2016-01-15 02:52:22 -07:00
|
|
|
if (syms[i].st_shndx == SHN_ABS
|
2014-03-18 17:12:22 -07:00
|
|
|
&& strcmp(strtab + syms[i].st_name, "TOC.") == 0)
|
2014-03-18 02:29:26 -07:00
|
|
|
return &syms[i];
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
2023-04-07 19:17:52 -07:00
|
|
|
#endif /* CONFIG_PPC_KERNEL_PCREL */
|
2014-03-18 02:29:26 -07:00
|
|
|
|
2022-02-01 22:51:23 -07:00
|
|
|
bool module_init_section(const char *name)
|
|
|
|
{
|
|
|
|
/* We don't handle .init for the moment: always return false. */
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
int module_frob_arch_sections(Elf64_Ehdr *hdr,
|
|
|
|
Elf64_Shdr *sechdrs,
|
|
|
|
char *secstrings,
|
|
|
|
struct module *me)
|
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
/* Find .toc and .stubs sections, symtab and strtab */
|
|
|
|
for (i = 1; i < hdr->e_shnum; i++) {
|
|
|
|
if (strcmp(secstrings + sechdrs[i].sh_name, ".stubs") == 0)
|
|
|
|
me->arch.stubs_section = i;
|
2023-04-07 19:17:52 -07:00
|
|
|
#ifdef CONFIG_PPC_KERNEL_PCREL
|
|
|
|
else if (strcmp(secstrings + sechdrs[i].sh_name, ".data..percpu") == 0)
|
|
|
|
me->arch.pcpu_section = i;
|
|
|
|
else if (strcmp(secstrings + sechdrs[i].sh_name, ".mygot") == 0) {
|
|
|
|
me->arch.got_section = i;
|
|
|
|
if (sechdrs[i].sh_addralign < 8)
|
|
|
|
sechdrs[i].sh_addralign = 8;
|
|
|
|
}
|
|
|
|
#else
|
powerpc/modules: Fix alignment of .toc section in kernel modules
powerpc64 gcc can generate code that offsets an address, to access
part of an object in memory. If the address is a -mcmodel=medium toc
pointer relative address then code like the following is possible.
addis r9,r2,var@toc@ha
ld r3,var@toc@l(r9)
ld r4,(var+8)@toc@l(r9)
This works fine so long as var is naturally aligned, *and* r2 is
sufficiently aligned. If not, there is a possibility that the offset
added to access var+8 wraps over a n*64k+32k boundary. Modules don't
have any guarantee that r2 is sufficiently aligned. Moreover, code
generated by older compilers generates a .toc section with 2**0
alignment, which can result in relocation failures at module load time
even without the wrap problem.
Thus, this patch links modules with an aligned .toc section (Makefile
and module.lds changes), and forces alignment for out of tree modules
or those without a .toc section (module_64.c changes).
Signed-off-by: Alan Modra <amodra@gmail.com>
[desnesn: updated patch to apply to powerpc-next kernel v4.15 ]
Signed-off-by: Desnes A. Nunes do Rosario <desnesn@linux.vnet.ibm.com>
[mpe: Fix out-of-tree build, swap -256 for ~0xff, reflow comment]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-12-06 12:12:28 -07:00
|
|
|
else if (strcmp(secstrings + sechdrs[i].sh_name, ".toc") == 0) {
|
2005-04-16 15:20:36 -07:00
|
|
|
me->arch.toc_section = i;
|
powerpc/modules: Fix alignment of .toc section in kernel modules
powerpc64 gcc can generate code that offsets an address, to access
part of an object in memory. If the address is a -mcmodel=medium toc
pointer relative address then code like the following is possible.
addis r9,r2,var@toc@ha
ld r3,var@toc@l(r9)
ld r4,(var+8)@toc@l(r9)
This works fine so long as var is naturally aligned, *and* r2 is
sufficiently aligned. If not, there is a possibility that the offset
added to access var+8 wraps over a n*64k+32k boundary. Modules don't
have any guarantee that r2 is sufficiently aligned. Moreover, code
generated by older compilers generates a .toc section with 2**0
alignment, which can result in relocation failures at module load time
even without the wrap problem.
Thus, this patch links modules with an aligned .toc section (Makefile
and module.lds changes), and forces alignment for out of tree modules
or those without a .toc section (module_64.c changes).
Signed-off-by: Alan Modra <amodra@gmail.com>
[desnesn: updated patch to apply to powerpc-next kernel v4.15 ]
Signed-off-by: Desnes A. Nunes do Rosario <desnesn@linux.vnet.ibm.com>
[mpe: Fix out-of-tree build, swap -256 for ~0xff, reflow comment]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-12-06 12:12:28 -07:00
|
|
|
if (sechdrs[i].sh_addralign < 8)
|
|
|
|
sechdrs[i].sh_addralign = 8;
|
|
|
|
}
|
2005-04-16 15:20:36 -07:00
|
|
|
else if (strcmp(secstrings+sechdrs[i].sh_name,"__versions")==0)
|
|
|
|
dedotify_versions((void *)hdr + sechdrs[i].sh_offset,
|
|
|
|
sechdrs[i].sh_size);
|
|
|
|
|
|
|
|
if (sechdrs[i].sh_type == SHT_SYMTAB)
|
|
|
|
dedotify((void *)hdr + sechdrs[i].sh_offset,
|
|
|
|
sechdrs[i].sh_size / sizeof(Elf64_Sym),
|
|
|
|
(void *)hdr
|
|
|
|
+ sechdrs[sechdrs[i].sh_link].sh_offset);
|
2023-04-07 19:17:52 -07:00
|
|
|
#endif
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
2006-04-24 05:41:51 -07:00
|
|
|
|
|
|
|
if (!me->arch.stubs_section) {
|
2014-09-16 21:39:35 -07:00
|
|
|
pr_err("%s: doesn't contain .stubs.\n", me->name);
|
2005-04-16 15:20:36 -07:00
|
|
|
return -ENOEXEC;
|
|
|
|
}
|
|
|
|
|
2023-04-07 19:17:52 -07:00
|
|
|
#ifdef CONFIG_PPC_KERNEL_PCREL
|
|
|
|
if (!me->arch.got_section) {
|
|
|
|
pr_err("%s: doesn't contain .mygot.\n", me->name);
|
|
|
|
return -ENOEXEC;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Override the got size */
|
|
|
|
sechdrs[me->arch.got_section].sh_size = get_got_size(hdr, sechdrs, me);
|
|
|
|
#else
|
2006-04-24 05:41:51 -07:00
|
|
|
/* If we don't have a .toc, just use .stubs. We need to set r2
|
|
|
|
to some reasonable value in case the module calls out to
|
|
|
|
other functions via a stub, or if a function pointer escapes
|
|
|
|
the module by some means. */
|
|
|
|
if (!me->arch.toc_section)
|
|
|
|
me->arch.toc_section = me->arch.stubs_section;
|
2023-04-07 19:17:52 -07:00
|
|
|
#endif
|
2006-04-24 05:41:51 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
/* Override the stubs size */
|
|
|
|
sechdrs[me->arch.stubs_section].sh_size = get_stubs_size(hdr, sechdrs);
|
2023-04-07 19:17:52 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2023-06-19 02:47:34 -07:00
|
|
|
#if defined(CONFIG_MPROFILE_KERNEL) || defined(CONFIG_ARCH_USING_PATCHABLE_FUNCTION_ENTRY)
|
powerpc/module_64: Use special stub for _mcount() with -mprofile-kernel
Since commit c55d7b5e64265f ("powerpc: Remove STRICT_KERNEL_RWX
incompatibility with RELOCATABLE"), powerpc kernels with
-mprofile-kernel can crash in certain scenarios with a trace like below:
BUG: Unable to handle kernel instruction fetch (NULL pointer?)
Faulting instruction address: 0x00000000
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=256 DEBUG_PAGEALLOC NUMA PowerNV
<snip>
NIP [0000000000000000] 0x0
LR [c0080000102c0048] ext4_iomap_end+0x8/0x30 [ext4]
Call Trace:
iomap_apply+0x20c/0x920 (unreliable)
iomap_bmap+0xfc/0x160
ext4_bmap+0xa4/0x180 [ext4]
bmap+0x4c/0x80
jbd2_journal_init_inode+0x44/0x1a0 [jbd2]
ext4_load_journal+0x440/0x860 [ext4]
ext4_fill_super+0x342c/0x3ab0 [ext4]
mount_bdev+0x25c/0x290
ext4_mount+0x28/0x50 [ext4]
legacy_get_tree+0x4c/0xb0
vfs_get_tree+0x4c/0x130
do_mount+0xa18/0xc50
sys_mount+0x158/0x180
system_call+0x5c/0x68
The NIP points to NULL, or a random location (data even), while the LR
always points to the LEP of a function (with an offset of 8), indicating
that something went wrong with ftrace. However, ftrace is not
necessarily active when such crashes occur.
The kernel OOPS sometimes follows a warning from ftrace indicating that
some module functions could not be patched with a nop. Other times, if a
module is loaded early during boot, instruction patching can fail due to
a separate bug, but the error is not reported due to missing error
reporting.
In all the above cases when instruction patching fails, ftrace will be
disabled but certain kernel module functions will be left with default
calls to _mcount(). This is not a problem with ELFv1. However, with
-mprofile-kernel, the default stub is problematic since it depends on a
valid module TOC in r2. If the kernel (or a different module) calls into
a function that does not use the TOC, the function won't have a prologue
to setup the module TOC. When that function calls into _mcount(), we
will end up in the relocation stub that will use the previous TOC, and
end up trying to jump into a random location. From the above trace:
iomap_apply+0x20c/0x920 [kernel TOC]
|
V
ext4_iomap_end+0x8/0x30 [no GEP == kernel TOC]
|
V
_mcount() stub
[uses kernel TOC -> random entry]
To address this, let's change over to using the special stub that is
used for ftrace_[regs_]caller() for _mcount(). This ensures that we are
not dependent on a valid module TOC in r2 for default _mcount()
handling.
Reported-by: Qian Cai <cai@lca.pw>
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Tested-by: Qian Cai <cai@lca.pw>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/8affd4298d22099bbd82544fab8185700a6222b1.1587488954.git.naveen.n.rao@linux.vnet.ibm.com
2020-04-21 10:35:45 -07:00
|
|
|
|
|
|
|
static u32 stub_insns[] = {
|
2023-04-07 19:17:51 -07:00
|
|
|
#ifdef CONFIG_PPC_KERNEL_PCREL
|
|
|
|
PPC_RAW_LD(_R12, _R13, offsetof(struct paca_struct, kernelbase)),
|
|
|
|
PPC_RAW_NOP(), /* align the prefix insn */
|
|
|
|
/* paddi r12,r12,addr */
|
|
|
|
PPC_PREFIX_MLS | __PPC_PRFX_R(0),
|
|
|
|
PPC_INST_PADDI | ___PPC_RT(_R12) | ___PPC_RA(_R12),
|
|
|
|
PPC_RAW_MTCTR(_R12),
|
|
|
|
PPC_RAW_BCTR(),
|
|
|
|
#else
|
2021-05-20 03:23:04 -07:00
|
|
|
PPC_RAW_LD(_R12, _R13, offsetof(struct paca_struct, kernel_toc)),
|
|
|
|
PPC_RAW_ADDIS(_R12, _R12, 0),
|
|
|
|
PPC_RAW_ADDI(_R12, _R12, 0),
|
|
|
|
PPC_RAW_MTCTR(_R12),
|
|
|
|
PPC_RAW_BCTR(),
|
2023-04-07 19:17:51 -07:00
|
|
|
#endif
|
powerpc/module_64: Use special stub for _mcount() with -mprofile-kernel
Since commit c55d7b5e64265f ("powerpc: Remove STRICT_KERNEL_RWX
incompatibility with RELOCATABLE"), powerpc kernels with
-mprofile-kernel can crash in certain scenarios with a trace like below:
BUG: Unable to handle kernel instruction fetch (NULL pointer?)
Faulting instruction address: 0x00000000
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=256 DEBUG_PAGEALLOC NUMA PowerNV
<snip>
NIP [0000000000000000] 0x0
LR [c0080000102c0048] ext4_iomap_end+0x8/0x30 [ext4]
Call Trace:
iomap_apply+0x20c/0x920 (unreliable)
iomap_bmap+0xfc/0x160
ext4_bmap+0xa4/0x180 [ext4]
bmap+0x4c/0x80
jbd2_journal_init_inode+0x44/0x1a0 [jbd2]
ext4_load_journal+0x440/0x860 [ext4]
ext4_fill_super+0x342c/0x3ab0 [ext4]
mount_bdev+0x25c/0x290
ext4_mount+0x28/0x50 [ext4]
legacy_get_tree+0x4c/0xb0
vfs_get_tree+0x4c/0x130
do_mount+0xa18/0xc50
sys_mount+0x158/0x180
system_call+0x5c/0x68
The NIP points to NULL, or a random location (data even), while the LR
always points to the LEP of a function (with an offset of 8), indicating
that something went wrong with ftrace. However, ftrace is not
necessarily active when such crashes occur.
The kernel OOPS sometimes follows a warning from ftrace indicating that
some module functions could not be patched with a nop. Other times, if a
module is loaded early during boot, instruction patching can fail due to
a separate bug, but the error is not reported due to missing error
reporting.
In all the above cases when instruction patching fails, ftrace will be
disabled but certain kernel module functions will be left with default
calls to _mcount(). This is not a problem with ELFv1. However, with
-mprofile-kernel, the default stub is problematic since it depends on a
valid module TOC in r2. If the kernel (or a different module) calls into
a function that does not use the TOC, the function won't have a prologue
to setup the module TOC. When that function calls into _mcount(), we
will end up in the relocation stub that will use the previous TOC, and
end up trying to jump into a random location. From the above trace:
iomap_apply+0x20c/0x920 [kernel TOC]
|
V
ext4_iomap_end+0x8/0x30 [no GEP == kernel TOC]
|
V
_mcount() stub
[uses kernel TOC -> random entry]
To address this, let's change over to using the special stub that is
used for ftrace_[regs_]caller() for _mcount(). This ensures that we are
not dependent on a valid module TOC in r2 for default _mcount()
handling.
Reported-by: Qian Cai <cai@lca.pw>
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Tested-by: Qian Cai <cai@lca.pw>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/8affd4298d22099bbd82544fab8185700a6222b1.1587488954.git.naveen.n.rao@linux.vnet.ibm.com
2020-04-21 10:35:45 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* For mprofile-kernel we use a special stub for ftrace_caller() because we
|
|
|
|
* can't rely on r2 containing this module's TOC when we enter the stub.
|
|
|
|
*
|
|
|
|
* That can happen if the function calling us didn't need to use the toc. In
|
|
|
|
* that case it won't have setup r2, and the r2 value will be either the
|
|
|
|
* kernel's toc, or possibly another modules toc.
|
|
|
|
*
|
|
|
|
* To deal with that this stub uses the kernel toc, which is always accessible
|
|
|
|
* via the paca (in r13). The target (ftrace_caller()) is responsible for
|
|
|
|
* saving and restoring the toc before returning.
|
|
|
|
*/
|
|
|
|
static inline int create_ftrace_stub(struct ppc64_stub_entry *entry,
|
|
|
|
unsigned long addr,
|
|
|
|
struct module *me)
|
|
|
|
{
|
|
|
|
long reladdr;
|
|
|
|
|
2023-04-07 19:17:51 -07:00
|
|
|
if ((unsigned long)entry->jump % 8 != 0) {
|
|
|
|
pr_err("%s: Address of stub entry is not 8-byte aligned\n", me->name);
|
powerpc/module_64: Use special stub for _mcount() with -mprofile-kernel
Since commit c55d7b5e64265f ("powerpc: Remove STRICT_KERNEL_RWX
incompatibility with RELOCATABLE"), powerpc kernels with
-mprofile-kernel can crash in certain scenarios with a trace like below:
BUG: Unable to handle kernel instruction fetch (NULL pointer?)
Faulting instruction address: 0x00000000
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=256 DEBUG_PAGEALLOC NUMA PowerNV
<snip>
NIP [0000000000000000] 0x0
LR [c0080000102c0048] ext4_iomap_end+0x8/0x30 [ext4]
Call Trace:
iomap_apply+0x20c/0x920 (unreliable)
iomap_bmap+0xfc/0x160
ext4_bmap+0xa4/0x180 [ext4]
bmap+0x4c/0x80
jbd2_journal_init_inode+0x44/0x1a0 [jbd2]
ext4_load_journal+0x440/0x860 [ext4]
ext4_fill_super+0x342c/0x3ab0 [ext4]
mount_bdev+0x25c/0x290
ext4_mount+0x28/0x50 [ext4]
legacy_get_tree+0x4c/0xb0
vfs_get_tree+0x4c/0x130
do_mount+0xa18/0xc50
sys_mount+0x158/0x180
system_call+0x5c/0x68
The NIP points to NULL, or a random location (data even), while the LR
always points to the LEP of a function (with an offset of 8), indicating
that something went wrong with ftrace. However, ftrace is not
necessarily active when such crashes occur.
The kernel OOPS sometimes follows a warning from ftrace indicating that
some module functions could not be patched with a nop. Other times, if a
module is loaded early during boot, instruction patching can fail due to
a separate bug, but the error is not reported due to missing error
reporting.
In all the above cases when instruction patching fails, ftrace will be
disabled but certain kernel module functions will be left with default
calls to _mcount(). This is not a problem with ELFv1. However, with
-mprofile-kernel, the default stub is problematic since it depends on a
valid module TOC in r2. If the kernel (or a different module) calls into
a function that does not use the TOC, the function won't have a prologue
to setup the module TOC. When that function calls into _mcount(), we
will end up in the relocation stub that will use the previous TOC, and
end up trying to jump into a random location. From the above trace:
iomap_apply+0x20c/0x920 [kernel TOC]
|
V
ext4_iomap_end+0x8/0x30 [no GEP == kernel TOC]
|
V
_mcount() stub
[uses kernel TOC -> random entry]
To address this, let's change over to using the special stub that is
used for ftrace_[regs_]caller() for _mcount(). This ensures that we are
not dependent on a valid module TOC in r2 for default _mcount()
handling.
Reported-by: Qian Cai <cai@lca.pw>
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Tested-by: Qian Cai <cai@lca.pw>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/8affd4298d22099bbd82544fab8185700a6222b1.1587488954.git.naveen.n.rao@linux.vnet.ibm.com
2020-04-21 10:35:45 -07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2023-04-07 19:17:51 -07:00
|
|
|
BUILD_BUG_ON(sizeof(stub_insns) > sizeof(entry->jump));
|
|
|
|
memcpy(entry->jump, stub_insns, sizeof(stub_insns));
|
|
|
|
|
|
|
|
if (IS_ENABLED(CONFIG_PPC_KERNEL_PCREL)) {
|
|
|
|
/* Stub uses address relative to kernel base (from the paca) */
|
|
|
|
reladdr = addr - local_paca->kernelbase;
|
|
|
|
if (reladdr > 0x1FFFFFFFFL || reladdr < -0x200000000L) {
|
|
|
|
pr_err("%s: Address of %ps out of range of 34-bit relative address.\n",
|
|
|
|
me->name, (void *)addr);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
entry->jump[2] |= IMM_H18(reladdr);
|
|
|
|
entry->jump[3] |= IMM_L(reladdr);
|
|
|
|
} else {
|
|
|
|
/* Stub uses address relative to kernel toc (from the paca) */
|
|
|
|
reladdr = addr - kernel_toc_addr();
|
|
|
|
if (reladdr > 0x7FFFFFFF || reladdr < -(0x80000000L)) {
|
|
|
|
pr_err("%s: Address of %ps out of range of kernel_toc.\n",
|
|
|
|
me->name, (void *)addr);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
entry->jump[1] |= PPC_HA(reladdr);
|
|
|
|
entry->jump[2] |= PPC_LO(reladdr);
|
|
|
|
}
|
powerpc/module_64: Use special stub for _mcount() with -mprofile-kernel
Since commit c55d7b5e64265f ("powerpc: Remove STRICT_KERNEL_RWX
incompatibility with RELOCATABLE"), powerpc kernels with
-mprofile-kernel can crash in certain scenarios with a trace like below:
BUG: Unable to handle kernel instruction fetch (NULL pointer?)
Faulting instruction address: 0x00000000
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=256 DEBUG_PAGEALLOC NUMA PowerNV
<snip>
NIP [0000000000000000] 0x0
LR [c0080000102c0048] ext4_iomap_end+0x8/0x30 [ext4]
Call Trace:
iomap_apply+0x20c/0x920 (unreliable)
iomap_bmap+0xfc/0x160
ext4_bmap+0xa4/0x180 [ext4]
bmap+0x4c/0x80
jbd2_journal_init_inode+0x44/0x1a0 [jbd2]
ext4_load_journal+0x440/0x860 [ext4]
ext4_fill_super+0x342c/0x3ab0 [ext4]
mount_bdev+0x25c/0x290
ext4_mount+0x28/0x50 [ext4]
legacy_get_tree+0x4c/0xb0
vfs_get_tree+0x4c/0x130
do_mount+0xa18/0xc50
sys_mount+0x158/0x180
system_call+0x5c/0x68
The NIP points to NULL, or a random location (data even), while the LR
always points to the LEP of a function (with an offset of 8), indicating
that something went wrong with ftrace. However, ftrace is not
necessarily active when such crashes occur.
The kernel OOPS sometimes follows a warning from ftrace indicating that
some module functions could not be patched with a nop. Other times, if a
module is loaded early during boot, instruction patching can fail due to
a separate bug, but the error is not reported due to missing error
reporting.
In all the above cases when instruction patching fails, ftrace will be
disabled but certain kernel module functions will be left with default
calls to _mcount(). This is not a problem with ELFv1. However, with
-mprofile-kernel, the default stub is problematic since it depends on a
valid module TOC in r2. If the kernel (or a different module) calls into
a function that does not use the TOC, the function won't have a prologue
to setup the module TOC. When that function calls into _mcount(), we
will end up in the relocation stub that will use the previous TOC, and
end up trying to jump into a random location. From the above trace:
iomap_apply+0x20c/0x920 [kernel TOC]
|
V
ext4_iomap_end+0x8/0x30 [no GEP == kernel TOC]
|
V
_mcount() stub
[uses kernel TOC -> random entry]
To address this, let's change over to using the special stub that is
used for ftrace_[regs_]caller() for _mcount(). This ensures that we are
not dependent on a valid module TOC in r2 for default _mcount()
handling.
Reported-by: Qian Cai <cai@lca.pw>
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Tested-by: Qian Cai <cai@lca.pw>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/8affd4298d22099bbd82544fab8185700a6222b1.1587488954.git.naveen.n.rao@linux.vnet.ibm.com
2020-04-21 10:35:45 -07:00
|
|
|
|
2022-04-30 11:56:54 -07:00
|
|
|
/* Even though we don't use funcdata in the stub, it's needed elsewhere. */
|
powerpc/module_64: Use special stub for _mcount() with -mprofile-kernel
Since commit c55d7b5e64265f ("powerpc: Remove STRICT_KERNEL_RWX
incompatibility with RELOCATABLE"), powerpc kernels with
-mprofile-kernel can crash in certain scenarios with a trace like below:
BUG: Unable to handle kernel instruction fetch (NULL pointer?)
Faulting instruction address: 0x00000000
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=256 DEBUG_PAGEALLOC NUMA PowerNV
<snip>
NIP [0000000000000000] 0x0
LR [c0080000102c0048] ext4_iomap_end+0x8/0x30 [ext4]
Call Trace:
iomap_apply+0x20c/0x920 (unreliable)
iomap_bmap+0xfc/0x160
ext4_bmap+0xa4/0x180 [ext4]
bmap+0x4c/0x80
jbd2_journal_init_inode+0x44/0x1a0 [jbd2]
ext4_load_journal+0x440/0x860 [ext4]
ext4_fill_super+0x342c/0x3ab0 [ext4]
mount_bdev+0x25c/0x290
ext4_mount+0x28/0x50 [ext4]
legacy_get_tree+0x4c/0xb0
vfs_get_tree+0x4c/0x130
do_mount+0xa18/0xc50
sys_mount+0x158/0x180
system_call+0x5c/0x68
The NIP points to NULL, or a random location (data even), while the LR
always points to the LEP of a function (with an offset of 8), indicating
that something went wrong with ftrace. However, ftrace is not
necessarily active when such crashes occur.
The kernel OOPS sometimes follows a warning from ftrace indicating that
some module functions could not be patched with a nop. Other times, if a
module is loaded early during boot, instruction patching can fail due to
a separate bug, but the error is not reported due to missing error
reporting.
In all the above cases when instruction patching fails, ftrace will be
disabled but certain kernel module functions will be left with default
calls to _mcount(). This is not a problem with ELFv1. However, with
-mprofile-kernel, the default stub is problematic since it depends on a
valid module TOC in r2. If the kernel (or a different module) calls into
a function that does not use the TOC, the function won't have a prologue
to setup the module TOC. When that function calls into _mcount(), we
will end up in the relocation stub that will use the previous TOC, and
end up trying to jump into a random location. From the above trace:
iomap_apply+0x20c/0x920 [kernel TOC]
|
V
ext4_iomap_end+0x8/0x30 [no GEP == kernel TOC]
|
V
_mcount() stub
[uses kernel TOC -> random entry]
To address this, let's change over to using the special stub that is
used for ftrace_[regs_]caller() for _mcount(). This ensures that we are
not dependent on a valid module TOC in r2 for default _mcount()
handling.
Reported-by: Qian Cai <cai@lca.pw>
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Tested-by: Qian Cai <cai@lca.pw>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/8affd4298d22099bbd82544fab8185700a6222b1.1587488954.git.naveen.n.rao@linux.vnet.ibm.com
2020-04-21 10:35:45 -07:00
|
|
|
entry->funcdata = func_desc(addr);
|
|
|
|
entry->magic = STUB_MAGIC;
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool is_mprofile_ftrace_call(const char *name)
|
|
|
|
{
|
|
|
|
if (!strcmp("_mcount", name))
|
|
|
|
return true;
|
|
|
|
#ifdef CONFIG_DYNAMIC_FTRACE
|
|
|
|
if (!strcmp("ftrace_caller", name))
|
|
|
|
return true;
|
|
|
|
#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
|
|
|
|
if (!strcmp("ftrace_regs_caller", name))
|
|
|
|
return true;
|
|
|
|
#endif
|
|
|
|
#endif
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
static inline int create_ftrace_stub(struct ppc64_stub_entry *entry,
|
|
|
|
unsigned long addr,
|
|
|
|
struct module *me)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool is_mprofile_ftrace_call(const char *name)
|
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
powerpc/modules: Fix alignment of .toc section in kernel modules
powerpc64 gcc can generate code that offsets an address, to access
part of an object in memory. If the address is a -mcmodel=medium toc
pointer relative address then code like the following is possible.
addis r9,r2,var@toc@ha
ld r3,var@toc@l(r9)
ld r4,(var+8)@toc@l(r9)
This works fine so long as var is naturally aligned, *and* r2 is
sufficiently aligned. If not, there is a possibility that the offset
added to access var+8 wraps over a n*64k+32k boundary. Modules don't
have any guarantee that r2 is sufficiently aligned. Moreover, code
generated by older compilers generates a .toc section with 2**0
alignment, which can result in relocation failures at module load time
even without the wrap problem.
Thus, this patch links modules with an aligned .toc section (Makefile
and module.lds changes), and forces alignment for out of tree modules
or those without a .toc section (module_64.c changes).
Signed-off-by: Alan Modra <amodra@gmail.com>
[desnesn: updated patch to apply to powerpc-next kernel v4.15 ]
Signed-off-by: Desnes A. Nunes do Rosario <desnesn@linux.vnet.ibm.com>
[mpe: Fix out-of-tree build, swap -256 for ~0xff, reflow comment]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-12-06 12:12:28 -07:00
|
|
|
/*
|
|
|
|
* r2 is the TOC pointer: it actually points 0x8000 into the TOC (this gives the
|
|
|
|
* value maximum span in an instruction which uses a signed offset). Round down
|
|
|
|
* to a 256 byte boundary for the odd case where we are setting up r2 without a
|
|
|
|
* .toc section.
|
|
|
|
*/
|
2016-03-02 21:26:54 -07:00
|
|
|
static inline unsigned long my_r2(const Elf64_Shdr *sechdrs, struct module *me)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
2023-04-07 19:17:52 -07:00
|
|
|
#ifndef CONFIG_PPC_KERNEL_PCREL
|
powerpc/modules: Fix alignment of .toc section in kernel modules
powerpc64 gcc can generate code that offsets an address, to access
part of an object in memory. If the address is a -mcmodel=medium toc
pointer relative address then code like the following is possible.
addis r9,r2,var@toc@ha
ld r3,var@toc@l(r9)
ld r4,(var+8)@toc@l(r9)
This works fine so long as var is naturally aligned, *and* r2 is
sufficiently aligned. If not, there is a possibility that the offset
added to access var+8 wraps over a n*64k+32k boundary. Modules don't
have any guarantee that r2 is sufficiently aligned. Moreover, code
generated by older compilers generates a .toc section with 2**0
alignment, which can result in relocation failures at module load time
even without the wrap problem.
Thus, this patch links modules with an aligned .toc section (Makefile
and module.lds changes), and forces alignment for out of tree modules
or those without a .toc section (module_64.c changes).
Signed-off-by: Alan Modra <amodra@gmail.com>
[desnesn: updated patch to apply to powerpc-next kernel v4.15 ]
Signed-off-by: Desnes A. Nunes do Rosario <desnesn@linux.vnet.ibm.com>
[mpe: Fix out-of-tree build, swap -256 for ~0xff, reflow comment]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-12-06 12:12:28 -07:00
|
|
|
return (sechdrs[me->arch.toc_section].sh_addr & ~0xfful) + 0x8000;
|
2023-04-07 19:17:52 -07:00
|
|
|
#else
|
|
|
|
return -1;
|
|
|
|
#endif
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Patch stub to reference function and correct r2 value. */
|
2016-03-02 21:26:54 -07:00
|
|
|
static inline int create_stub(const Elf64_Shdr *sechdrs,
|
2005-04-16 15:20:36 -07:00
|
|
|
struct ppc64_stub_entry *entry,
|
2014-03-18 17:12:22 -07:00
|
|
|
unsigned long addr,
|
powerpc/module_64: Use special stub for _mcount() with -mprofile-kernel
Since commit c55d7b5e64265f ("powerpc: Remove STRICT_KERNEL_RWX
incompatibility with RELOCATABLE"), powerpc kernels with
-mprofile-kernel can crash in certain scenarios with a trace like below:
BUG: Unable to handle kernel instruction fetch (NULL pointer?)
Faulting instruction address: 0x00000000
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=256 DEBUG_PAGEALLOC NUMA PowerNV
<snip>
NIP [0000000000000000] 0x0
LR [c0080000102c0048] ext4_iomap_end+0x8/0x30 [ext4]
Call Trace:
iomap_apply+0x20c/0x920 (unreliable)
iomap_bmap+0xfc/0x160
ext4_bmap+0xa4/0x180 [ext4]
bmap+0x4c/0x80
jbd2_journal_init_inode+0x44/0x1a0 [jbd2]
ext4_load_journal+0x440/0x860 [ext4]
ext4_fill_super+0x342c/0x3ab0 [ext4]
mount_bdev+0x25c/0x290
ext4_mount+0x28/0x50 [ext4]
legacy_get_tree+0x4c/0xb0
vfs_get_tree+0x4c/0x130
do_mount+0xa18/0xc50
sys_mount+0x158/0x180
system_call+0x5c/0x68
The NIP points to NULL, or a random location (data even), while the LR
always points to the LEP of a function (with an offset of 8), indicating
that something went wrong with ftrace. However, ftrace is not
necessarily active when such crashes occur.
The kernel OOPS sometimes follows a warning from ftrace indicating that
some module functions could not be patched with a nop. Other times, if a
module is loaded early during boot, instruction patching can fail due to
a separate bug, but the error is not reported due to missing error
reporting.
In all the above cases when instruction patching fails, ftrace will be
disabled but certain kernel module functions will be left with default
calls to _mcount(). This is not a problem with ELFv1. However, with
-mprofile-kernel, the default stub is problematic since it depends on a
valid module TOC in r2. If the kernel (or a different module) calls into
a function that does not use the TOC, the function won't have a prologue
to setup the module TOC. When that function calls into _mcount(), we
will end up in the relocation stub that will use the previous TOC, and
end up trying to jump into a random location. From the above trace:
iomap_apply+0x20c/0x920 [kernel TOC]
|
V
ext4_iomap_end+0x8/0x30 [no GEP == kernel TOC]
|
V
_mcount() stub
[uses kernel TOC -> random entry]
To address this, let's change over to using the special stub that is
used for ftrace_[regs_]caller() for _mcount(). This ensures that we are
not dependent on a valid module TOC in r2 for default _mcount()
handling.
Reported-by: Qian Cai <cai@lca.pw>
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Tested-by: Qian Cai <cai@lca.pw>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/8affd4298d22099bbd82544fab8185700a6222b1.1587488954.git.naveen.n.rao@linux.vnet.ibm.com
2020-04-21 10:35:45 -07:00
|
|
|
struct module *me,
|
|
|
|
const char *name)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
|
|
|
long reladdr;
|
2021-11-23 01:15:20 -07:00
|
|
|
func_desc_t desc;
|
|
|
|
int i;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
powerpc/module_64: Use special stub for _mcount() with -mprofile-kernel
Since commit c55d7b5e64265f ("powerpc: Remove STRICT_KERNEL_RWX
incompatibility with RELOCATABLE"), powerpc kernels with
-mprofile-kernel can crash in certain scenarios with a trace like below:
BUG: Unable to handle kernel instruction fetch (NULL pointer?)
Faulting instruction address: 0x00000000
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=256 DEBUG_PAGEALLOC NUMA PowerNV
<snip>
NIP [0000000000000000] 0x0
LR [c0080000102c0048] ext4_iomap_end+0x8/0x30 [ext4]
Call Trace:
iomap_apply+0x20c/0x920 (unreliable)
iomap_bmap+0xfc/0x160
ext4_bmap+0xa4/0x180 [ext4]
bmap+0x4c/0x80
jbd2_journal_init_inode+0x44/0x1a0 [jbd2]
ext4_load_journal+0x440/0x860 [ext4]
ext4_fill_super+0x342c/0x3ab0 [ext4]
mount_bdev+0x25c/0x290
ext4_mount+0x28/0x50 [ext4]
legacy_get_tree+0x4c/0xb0
vfs_get_tree+0x4c/0x130
do_mount+0xa18/0xc50
sys_mount+0x158/0x180
system_call+0x5c/0x68
The NIP points to NULL, or a random location (data even), while the LR
always points to the LEP of a function (with an offset of 8), indicating
that something went wrong with ftrace. However, ftrace is not
necessarily active when such crashes occur.
The kernel OOPS sometimes follows a warning from ftrace indicating that
some module functions could not be patched with a nop. Other times, if a
module is loaded early during boot, instruction patching can fail due to
a separate bug, but the error is not reported due to missing error
reporting.
In all the above cases when instruction patching fails, ftrace will be
disabled but certain kernel module functions will be left with default
calls to _mcount(). This is not a problem with ELFv1. However, with
-mprofile-kernel, the default stub is problematic since it depends on a
valid module TOC in r2. If the kernel (or a different module) calls into
a function that does not use the TOC, the function won't have a prologue
to setup the module TOC. When that function calls into _mcount(), we
will end up in the relocation stub that will use the previous TOC, and
end up trying to jump into a random location. From the above trace:
iomap_apply+0x20c/0x920 [kernel TOC]
|
V
ext4_iomap_end+0x8/0x30 [no GEP == kernel TOC]
|
V
_mcount() stub
[uses kernel TOC -> random entry]
To address this, let's change over to using the special stub that is
used for ftrace_[regs_]caller() for _mcount(). This ensures that we are
not dependent on a valid module TOC in r2 for default _mcount()
handling.
Reported-by: Qian Cai <cai@lca.pw>
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Tested-by: Qian Cai <cai@lca.pw>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/8affd4298d22099bbd82544fab8185700a6222b1.1587488954.git.naveen.n.rao@linux.vnet.ibm.com
2020-04-21 10:35:45 -07:00
|
|
|
if (is_mprofile_ftrace_call(name))
|
|
|
|
return create_ftrace_stub(entry, addr, me);
|
|
|
|
|
2023-04-07 19:17:52 -07:00
|
|
|
if ((unsigned long)entry->jump % 8 != 0) {
|
|
|
|
pr_err("%s: Address of stub entry is not 8-byte aligned\n", me->name);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
BUILD_BUG_ON(sizeof(ppc64_stub_insns) > sizeof(entry->jump));
|
2022-02-23 00:54:23 -07:00
|
|
|
for (i = 0; i < ARRAY_SIZE(ppc64_stub_insns); i++) {
|
2021-11-23 01:15:20 -07:00
|
|
|
if (patch_instruction(&entry->jump[i],
|
|
|
|
ppc_inst(ppc64_stub_insns[i])))
|
|
|
|
return 0;
|
|
|
|
}
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-04-07 19:17:52 -07:00
|
|
|
if (IS_ENABLED(CONFIG_PPC_KERNEL_PCREL)) {
|
|
|
|
/* Stub uses address relative to itself! */
|
|
|
|
reladdr = 0 + offsetof(struct ppc64_stub_entry, funcdata);
|
|
|
|
BUILD_BUG_ON(reladdr != 32);
|
|
|
|
if (reladdr > 0x1FFFFFFFFL || reladdr < -0x200000000L) {
|
|
|
|
pr_err("%s: Address of %p out of range of 34-bit relative address.\n",
|
|
|
|
me->name, (void *)reladdr);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
pr_debug("Stub %p get data from reladdr %li\n", entry, reladdr);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-04-07 19:17:52 -07:00
|
|
|
/* May not even need this if we're relative to 0 */
|
|
|
|
if (patch_instruction(&entry->jump[0],
|
|
|
|
ppc_inst_prefix(entry->jump[0] | IMM_H18(reladdr),
|
|
|
|
entry->jump[1] | IMM_L(reladdr))))
|
|
|
|
return 0;
|
2021-11-23 01:15:20 -07:00
|
|
|
|
2023-04-07 19:17:52 -07:00
|
|
|
} else {
|
|
|
|
/* Stub uses address relative to r2. */
|
|
|
|
reladdr = (unsigned long)entry - my_r2(sechdrs, me);
|
|
|
|
if (reladdr > 0x7FFFFFFF || reladdr < -(0x80000000L)) {
|
|
|
|
pr_err("%s: Address %p of stub out of range of %p.\n",
|
|
|
|
me->name, (void *)reladdr, (void *)my_r2);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
pr_debug("Stub %p get data from reladdr %li\n", entry, reladdr);
|
|
|
|
|
|
|
|
if (patch_instruction(&entry->jump[0],
|
|
|
|
ppc_inst(entry->jump[0] | PPC_HA(reladdr))))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (patch_instruction(&entry->jump[1],
|
|
|
|
ppc_inst(entry->jump[1] | PPC_LO(reladdr))))
|
|
|
|
return 0;
|
|
|
|
}
|
2021-11-23 01:15:20 -07:00
|
|
|
|
|
|
|
// func_desc_t is 8 bytes if ABIv2, else 16 bytes
|
|
|
|
desc = func_desc(addr);
|
|
|
|
for (i = 0; i < sizeof(func_desc_t) / sizeof(u32); i++) {
|
2024-05-14 19:44:43 -07:00
|
|
|
if (patch_u32(((u32 *)&entry->funcdata) + i, ((u32 *)&desc)[i]))
|
2021-11-23 01:15:20 -07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2024-05-14 19:44:43 -07:00
|
|
|
if (patch_u32(&entry->magic, STUB_MAGIC))
|
2021-11-23 01:15:20 -07:00
|
|
|
return 0;
|
powerpc/module: Mark module stubs with a magic value
When a module is loaded, calls out to the kernel go via a stub which is
generated at runtime. One of these stubs is used to call _mcount(),
which is the default target of tracing calls generated by the compiler
with -pg.
If dynamic ftrace is enabled (which it typically is), another stub is
used to call ftrace_caller(), which is the target of tracing calls when
ftrace is actually active.
ftrace then wants to disable the calls to _mcount() at module startup,
and enable/disable the calls to ftrace_caller() when enabling/disabling
tracing - all of these it does by patching the code.
As part of that code patching, the ftrace code wants to confirm that the
branch it is about to modify, is in fact a call to a module stub which
calls _mcount() or ftrace_caller().
Currently it does that by inspecting the instructions and confirming
they are what it expects. Although that works, the code to do it is
pretty intricate because it requires lots of knowledge about the exact
format of the stub.
We can make that process easier by marking the generated stubs with a
magic value, and then looking for that magic value. Altough this is not
as rigorous as the current method, I believe it is sufficient in
practice.
Reviewed-by: Balbir Singh <bsingharora@gmail.com>
Reviewed-by: Torsten Duwe <duwe@suse.de>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-03-02 21:26:55 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2014-03-18 17:12:22 -07:00
|
|
|
/* Create stub to jump to function described in this OPD/ptr: we need the
|
2005-04-16 15:20:36 -07:00
|
|
|
stub to set up the TOC ptr (r2) for the function. */
|
2016-03-02 21:26:54 -07:00
|
|
|
static unsigned long stub_for_addr(const Elf64_Shdr *sechdrs,
|
2014-03-18 17:12:22 -07:00
|
|
|
unsigned long addr,
|
powerpc/module_64: Use special stub for _mcount() with -mprofile-kernel
Since commit c55d7b5e64265f ("powerpc: Remove STRICT_KERNEL_RWX
incompatibility with RELOCATABLE"), powerpc kernels with
-mprofile-kernel can crash in certain scenarios with a trace like below:
BUG: Unable to handle kernel instruction fetch (NULL pointer?)
Faulting instruction address: 0x00000000
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=256 DEBUG_PAGEALLOC NUMA PowerNV
<snip>
NIP [0000000000000000] 0x0
LR [c0080000102c0048] ext4_iomap_end+0x8/0x30 [ext4]
Call Trace:
iomap_apply+0x20c/0x920 (unreliable)
iomap_bmap+0xfc/0x160
ext4_bmap+0xa4/0x180 [ext4]
bmap+0x4c/0x80
jbd2_journal_init_inode+0x44/0x1a0 [jbd2]
ext4_load_journal+0x440/0x860 [ext4]
ext4_fill_super+0x342c/0x3ab0 [ext4]
mount_bdev+0x25c/0x290
ext4_mount+0x28/0x50 [ext4]
legacy_get_tree+0x4c/0xb0
vfs_get_tree+0x4c/0x130
do_mount+0xa18/0xc50
sys_mount+0x158/0x180
system_call+0x5c/0x68
The NIP points to NULL, or a random location (data even), while the LR
always points to the LEP of a function (with an offset of 8), indicating
that something went wrong with ftrace. However, ftrace is not
necessarily active when such crashes occur.
The kernel OOPS sometimes follows a warning from ftrace indicating that
some module functions could not be patched with a nop. Other times, if a
module is loaded early during boot, instruction patching can fail due to
a separate bug, but the error is not reported due to missing error
reporting.
In all the above cases when instruction patching fails, ftrace will be
disabled but certain kernel module functions will be left with default
calls to _mcount(). This is not a problem with ELFv1. However, with
-mprofile-kernel, the default stub is problematic since it depends on a
valid module TOC in r2. If the kernel (or a different module) calls into
a function that does not use the TOC, the function won't have a prologue
to setup the module TOC. When that function calls into _mcount(), we
will end up in the relocation stub that will use the previous TOC, and
end up trying to jump into a random location. From the above trace:
iomap_apply+0x20c/0x920 [kernel TOC]
|
V
ext4_iomap_end+0x8/0x30 [no GEP == kernel TOC]
|
V
_mcount() stub
[uses kernel TOC -> random entry]
To address this, let's change over to using the special stub that is
used for ftrace_[regs_]caller() for _mcount(). This ensures that we are
not dependent on a valid module TOC in r2 for default _mcount()
handling.
Reported-by: Qian Cai <cai@lca.pw>
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Tested-by: Qian Cai <cai@lca.pw>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/8affd4298d22099bbd82544fab8185700a6222b1.1587488954.git.naveen.n.rao@linux.vnet.ibm.com
2020-04-21 10:35:45 -07:00
|
|
|
struct module *me,
|
|
|
|
const char *name)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
|
|
|
struct ppc64_stub_entry *stubs;
|
|
|
|
unsigned int i, num_stubs;
|
|
|
|
|
|
|
|
num_stubs = sechdrs[me->arch.stubs_section].sh_size / sizeof(*stubs);
|
|
|
|
|
|
|
|
/* Find this stub, or if that fails, the next avail. entry */
|
|
|
|
stubs = (void *)sechdrs[me->arch.stubs_section].sh_addr;
|
2014-03-18 17:12:22 -07:00
|
|
|
for (i = 0; stub_func_addr(stubs[i].funcdata); i++) {
|
2017-10-10 07:47:32 -07:00
|
|
|
if (WARN_ON(i >= num_stubs))
|
|
|
|
return 0;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-03-18 17:12:22 -07:00
|
|
|
if (stub_func_addr(stubs[i].funcdata) == func_addr(addr))
|
2005-04-16 15:20:36 -07:00
|
|
|
return (unsigned long)&stubs[i];
|
|
|
|
}
|
|
|
|
|
powerpc/module_64: Use special stub for _mcount() with -mprofile-kernel
Since commit c55d7b5e64265f ("powerpc: Remove STRICT_KERNEL_RWX
incompatibility with RELOCATABLE"), powerpc kernels with
-mprofile-kernel can crash in certain scenarios with a trace like below:
BUG: Unable to handle kernel instruction fetch (NULL pointer?)
Faulting instruction address: 0x00000000
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=256 DEBUG_PAGEALLOC NUMA PowerNV
<snip>
NIP [0000000000000000] 0x0
LR [c0080000102c0048] ext4_iomap_end+0x8/0x30 [ext4]
Call Trace:
iomap_apply+0x20c/0x920 (unreliable)
iomap_bmap+0xfc/0x160
ext4_bmap+0xa4/0x180 [ext4]
bmap+0x4c/0x80
jbd2_journal_init_inode+0x44/0x1a0 [jbd2]
ext4_load_journal+0x440/0x860 [ext4]
ext4_fill_super+0x342c/0x3ab0 [ext4]
mount_bdev+0x25c/0x290
ext4_mount+0x28/0x50 [ext4]
legacy_get_tree+0x4c/0xb0
vfs_get_tree+0x4c/0x130
do_mount+0xa18/0xc50
sys_mount+0x158/0x180
system_call+0x5c/0x68
The NIP points to NULL, or a random location (data even), while the LR
always points to the LEP of a function (with an offset of 8), indicating
that something went wrong with ftrace. However, ftrace is not
necessarily active when such crashes occur.
The kernel OOPS sometimes follows a warning from ftrace indicating that
some module functions could not be patched with a nop. Other times, if a
module is loaded early during boot, instruction patching can fail due to
a separate bug, but the error is not reported due to missing error
reporting.
In all the above cases when instruction patching fails, ftrace will be
disabled but certain kernel module functions will be left with default
calls to _mcount(). This is not a problem with ELFv1. However, with
-mprofile-kernel, the default stub is problematic since it depends on a
valid module TOC in r2. If the kernel (or a different module) calls into
a function that does not use the TOC, the function won't have a prologue
to setup the module TOC. When that function calls into _mcount(), we
will end up in the relocation stub that will use the previous TOC, and
end up trying to jump into a random location. From the above trace:
iomap_apply+0x20c/0x920 [kernel TOC]
|
V
ext4_iomap_end+0x8/0x30 [no GEP == kernel TOC]
|
V
_mcount() stub
[uses kernel TOC -> random entry]
To address this, let's change over to using the special stub that is
used for ftrace_[regs_]caller() for _mcount(). This ensures that we are
not dependent on a valid module TOC in r2 for default _mcount()
handling.
Reported-by: Qian Cai <cai@lca.pw>
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Tested-by: Qian Cai <cai@lca.pw>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/8affd4298d22099bbd82544fab8185700a6222b1.1587488954.git.naveen.n.rao@linux.vnet.ibm.com
2020-04-21 10:35:45 -07:00
|
|
|
if (!create_stub(sechdrs, &stubs[i], addr, me, name))
|
2005-04-16 15:20:36 -07:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
return (unsigned long)&stubs[i];
|
|
|
|
}
|
|
|
|
|
2023-04-07 19:17:52 -07:00
|
|
|
#ifdef CONFIG_PPC_KERNEL_PCREL
|
|
|
|
/* Create GOT to load the location described in this ptr */
|
|
|
|
static unsigned long got_for_addr(const Elf64_Shdr *sechdrs,
|
|
|
|
unsigned long addr,
|
|
|
|
struct module *me,
|
|
|
|
const char *name)
|
|
|
|
{
|
|
|
|
struct ppc64_got_entry *got;
|
|
|
|
unsigned int i, num_got;
|
|
|
|
|
|
|
|
if (!IS_ENABLED(CONFIG_PPC_KERNEL_PCREL))
|
|
|
|
return addr;
|
|
|
|
|
|
|
|
num_got = sechdrs[me->arch.got_section].sh_size / sizeof(*got);
|
|
|
|
|
|
|
|
/* Find this stub, or if that fails, the next avail. entry */
|
|
|
|
got = (void *)sechdrs[me->arch.got_section].sh_addr;
|
|
|
|
for (i = 0; got[i].addr; i++) {
|
|
|
|
if (WARN_ON(i >= num_got))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (got[i].addr == addr)
|
|
|
|
return (unsigned long)&got[i];
|
|
|
|
}
|
|
|
|
|
|
|
|
got[i].addr = addr;
|
|
|
|
|
|
|
|
return (unsigned long)&got[i];
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
/* We expect a noop next: if it is, replace it with instruction to
|
|
|
|
restore r2. */
|
2018-04-19 00:04:07 -07:00
|
|
|
static int restore_r2(const char *name, u32 *instruction, struct module *me)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
2017-11-16 10:45:37 -07:00
|
|
|
u32 *prev_insn = instruction - 1;
|
2023-01-24 20:38:05 -07:00
|
|
|
u32 insn_val = *instruction;
|
2017-11-16 10:45:37 -07:00
|
|
|
|
2023-04-07 19:17:52 -07:00
|
|
|
if (IS_ENABLED(CONFIG_PPC_KERNEL_PCREL))
|
|
|
|
return 0;
|
|
|
|
|
2020-04-21 10:35:44 -07:00
|
|
|
if (is_mprofile_ftrace_call(name))
|
2023-01-24 20:38:04 -07:00
|
|
|
return 0;
|
2017-11-16 10:45:37 -07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Make sure the branch isn't a sibling call. Sibling calls aren't
|
|
|
|
* "link" branches and they don't return, so they don't need the r2
|
|
|
|
* restore afterwards.
|
|
|
|
*/
|
2020-05-05 20:40:26 -07:00
|
|
|
if (!instr_is_relative_link_branch(ppc_inst(*prev_insn)))
|
2023-01-24 20:38:04 -07:00
|
|
|
return 0;
|
powerpc/modules: Never restore r2 for a mprofile-kernel style mcount() call
In the module loader we process relocations, and for long jumps we
generate trampolines (aka stubs). At the call site for one of these
trampolines we usually need to generate a load instruction to restore
the TOC pointer into r2.
There is one exception however, which is calls to mcount() using the
mprofile-kernel ABI, they handle the TOC inside the stub, and so for
them we do not generate a TOC load.
The bug is in how the code in restore_r2() decides if it needs to
generate the TOC load. It does so by looking for a nop following the
branch, and if it sees a nop, it replaces it with the load. In general
the compiler has no reason to generate a nop following the mcount()
call and so that check works OK.
However if we combine a jump label at the start of a function, with an
early return, such that GCC applies the shrink-wrapping optimisation, we
can then end up with an mcount call followed immediately by a nop.
However the nop is not there for a TOC load, it is for the jump label.
That confuses restore_r2() into replacing the jump label nop with a TOC
load, which in turn confuses ftrace into replacing the mcount call with
a b +8 (fixed in the previous commit). The end result is we jump over
the jump label, which if it was supposed to return means we incorrectly
run the body of the function.
We have seen this in practice with some yet-to-be-merged patches that
use jump labels more extensively.
The fix is relatively simple, in restore_r2() we check for an
mprofile-kernel style mcount() call first, before looking for the
presence of a nop.
Fixes: 153086644fd1 ("powerpc/ftrace: Add support for -mprofile-kernel ftrace ABI")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-07-18 21:48:31 -07:00
|
|
|
|
2023-01-24 20:38:05 -07:00
|
|
|
/*
|
|
|
|
* For livepatch, the restore r2 instruction might have already been
|
|
|
|
* written previously, if the referenced symbol is in a previously
|
|
|
|
* unloaded module which is now being loaded again. In that case, skip
|
|
|
|
* the warning and the instruction write.
|
|
|
|
*/
|
|
|
|
if (insn_val == PPC_INST_LD_TOC)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (insn_val != PPC_RAW_NOP()) {
|
2017-11-14 02:29:10 -07:00
|
|
|
pr_err("%s: Expected nop after call, got %08x at %pS\n",
|
2023-01-24 20:38:05 -07:00
|
|
|
me->name, insn_val, instruction);
|
2023-01-24 20:38:04 -07:00
|
|
|
return -ENOEXEC;
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
2021-11-23 01:15:20 -07:00
|
|
|
|
2014-03-18 02:42:44 -07:00
|
|
|
/* ld r2,R2_STACK_OFFSET(r1) */
|
2023-01-24 20:38:04 -07:00
|
|
|
return patch_instruction(instruction, ppc_inst(PPC_INST_LD_TOC));
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
int apply_relocate_add(Elf64_Shdr *sechdrs,
|
|
|
|
const char *strtab,
|
|
|
|
unsigned int symindex,
|
|
|
|
unsigned int relsec,
|
|
|
|
struct module *me)
|
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
Elf64_Rela *rela = (void *)sechdrs[relsec].sh_addr;
|
|
|
|
Elf64_Sym *sym;
|
|
|
|
unsigned long *location;
|
|
|
|
unsigned long value;
|
|
|
|
|
2014-09-16 21:39:35 -07:00
|
|
|
pr_debug("Applying ADD relocate section %u to %u\n", relsec,
|
2005-04-16 15:20:36 -07:00
|
|
|
sechdrs[relsec].sh_info);
|
2014-03-18 02:29:26 -07:00
|
|
|
|
2023-04-07 19:17:52 -07:00
|
|
|
#ifndef CONFIG_PPC_KERNEL_PCREL
|
2014-03-18 02:29:26 -07:00
|
|
|
/* First time we're called, we can fix up .TOC. */
|
|
|
|
if (!me->arch.toc_fixed) {
|
|
|
|
sym = find_dot_toc(sechdrs, strtab, symindex);
|
|
|
|
/* It's theoretically possible that a module doesn't want a
|
|
|
|
* .TOC. so don't fail it just for that. */
|
|
|
|
if (sym)
|
|
|
|
sym->st_value = my_r2(sechdrs, me);
|
|
|
|
me->arch.toc_fixed = true;
|
|
|
|
}
|
2023-04-07 19:17:52 -07:00
|
|
|
#endif
|
2005-04-16 15:20:36 -07:00
|
|
|
for (i = 0; i < sechdrs[relsec].sh_size / sizeof(*rela); i++) {
|
|
|
|
/* This is where to make the change */
|
|
|
|
location = (void *)sechdrs[sechdrs[relsec].sh_info].sh_addr
|
|
|
|
+ rela[i].r_offset;
|
|
|
|
/* This is the symbol it is referring to */
|
|
|
|
sym = (Elf64_Sym *)sechdrs[symindex].sh_addr
|
|
|
|
+ ELF64_R_SYM(rela[i].r_info);
|
|
|
|
|
2014-09-16 21:39:35 -07:00
|
|
|
pr_debug("RELOC at %p: %li-type as %s (0x%lx) + %li\n",
|
2005-04-16 15:20:36 -07:00
|
|
|
location, (long)ELF64_R_TYPE(rela[i].r_info),
|
|
|
|
strtab + sym->st_name, (unsigned long)sym->st_value,
|
|
|
|
(long)rela[i].r_addend);
|
|
|
|
|
|
|
|
/* `Everything is relative'. */
|
|
|
|
value = sym->st_value + rela[i].r_addend;
|
|
|
|
|
|
|
|
switch (ELF64_R_TYPE(rela[i].r_info)) {
|
|
|
|
case R_PPC64_ADDR32:
|
|
|
|
/* Simply set it */
|
|
|
|
*(u32 *)location = value;
|
|
|
|
break;
|
2007-11-13 09:24:04 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
case R_PPC64_ADDR64:
|
|
|
|
/* Simply set it */
|
|
|
|
*(unsigned long *)location = value;
|
|
|
|
break;
|
|
|
|
|
2023-04-07 19:17:52 -07:00
|
|
|
#ifndef CONFIG_PPC_KERNEL_PCREL
|
2005-04-16 15:20:36 -07:00
|
|
|
case R_PPC64_TOC:
|
|
|
|
*(unsigned long *)location = my_r2(sechdrs, me);
|
|
|
|
break;
|
|
|
|
|
2005-10-11 09:28:24 -07:00
|
|
|
case R_PPC64_TOC16:
|
2006-04-24 05:41:51 -07:00
|
|
|
/* Subtract TOC pointer */
|
2005-10-11 09:28:24 -07:00
|
|
|
value -= my_r2(sechdrs, me);
|
|
|
|
if (value + 0x8000 > 0xffff) {
|
2014-09-16 21:39:35 -07:00
|
|
|
pr_err("%s: bad TOC16 relocation (0x%lx)\n",
|
2005-10-11 09:28:24 -07:00
|
|
|
me->name, value);
|
|
|
|
return -ENOEXEC;
|
|
|
|
}
|
|
|
|
*((uint16_t *) location)
|
|
|
|
= (*((uint16_t *) location) & ~0xffff)
|
|
|
|
| (value & 0xffff);
|
|
|
|
break;
|
|
|
|
|
2012-11-26 10:41:08 -07:00
|
|
|
case R_PPC64_TOC16_LO:
|
|
|
|
/* Subtract TOC pointer */
|
|
|
|
value -= my_r2(sechdrs, me);
|
|
|
|
*((uint16_t *) location)
|
|
|
|
= (*((uint16_t *) location) & ~0xffff)
|
|
|
|
| (value & 0xffff);
|
|
|
|
break;
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
case R_PPC64_TOC16_DS:
|
2006-04-24 05:41:51 -07:00
|
|
|
/* Subtract TOC pointer */
|
2005-04-16 15:20:36 -07:00
|
|
|
value -= my_r2(sechdrs, me);
|
|
|
|
if ((value & 3) != 0 || value + 0x8000 > 0xffff) {
|
2014-09-16 21:39:35 -07:00
|
|
|
pr_err("%s: bad TOC16_DS relocation (0x%lx)\n",
|
2005-04-16 15:20:36 -07:00
|
|
|
me->name, value);
|
|
|
|
return -ENOEXEC;
|
|
|
|
}
|
|
|
|
*((uint16_t *) location)
|
|
|
|
= (*((uint16_t *) location) & ~0xfffc)
|
|
|
|
| (value & 0xfffc);
|
|
|
|
break;
|
|
|
|
|
2012-11-26 10:41:08 -07:00
|
|
|
case R_PPC64_TOC16_LO_DS:
|
|
|
|
/* Subtract TOC pointer */
|
|
|
|
value -= my_r2(sechdrs, me);
|
|
|
|
if ((value & 3) != 0) {
|
2014-09-16 21:39:35 -07:00
|
|
|
pr_err("%s: bad TOC16_LO_DS relocation (0x%lx)\n",
|
2012-11-26 10:41:08 -07:00
|
|
|
me->name, value);
|
|
|
|
return -ENOEXEC;
|
|
|
|
}
|
|
|
|
*((uint16_t *) location)
|
|
|
|
= (*((uint16_t *) location) & ~0xfffc)
|
|
|
|
| (value & 0xfffc);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case R_PPC64_TOC16_HA:
|
|
|
|
/* Subtract TOC pointer */
|
|
|
|
value -= my_r2(sechdrs, me);
|
|
|
|
value = ((value + 0x8000) >> 16);
|
|
|
|
*((uint16_t *) location)
|
|
|
|
= (*((uint16_t *) location) & ~0xffff)
|
|
|
|
| (value & 0xffff);
|
|
|
|
break;
|
2023-04-07 19:17:52 -07:00
|
|
|
#endif
|
2012-11-26 10:41:08 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
case R_PPC_REL24:
|
2023-04-07 19:17:52 -07:00
|
|
|
#ifdef CONFIG_PPC_KERNEL_PCREL
|
|
|
|
/* PCREL still generates REL24 for mcount */
|
|
|
|
case R_PPC64_REL24_NOTOC:
|
|
|
|
#endif
|
2005-04-16 15:20:36 -07:00
|
|
|
/* FIXME: Handle weak symbols here --RR */
|
2017-11-14 02:29:08 -07:00
|
|
|
if (sym->st_shndx == SHN_UNDEF ||
|
|
|
|
sym->st_shndx == SHN_LIVEPATCH) {
|
2005-04-16 15:20:36 -07:00
|
|
|
/* External: go via stub */
|
powerpc/module_64: Use special stub for _mcount() with -mprofile-kernel
Since commit c55d7b5e64265f ("powerpc: Remove STRICT_KERNEL_RWX
incompatibility with RELOCATABLE"), powerpc kernels with
-mprofile-kernel can crash in certain scenarios with a trace like below:
BUG: Unable to handle kernel instruction fetch (NULL pointer?)
Faulting instruction address: 0x00000000
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=256 DEBUG_PAGEALLOC NUMA PowerNV
<snip>
NIP [0000000000000000] 0x0
LR [c0080000102c0048] ext4_iomap_end+0x8/0x30 [ext4]
Call Trace:
iomap_apply+0x20c/0x920 (unreliable)
iomap_bmap+0xfc/0x160
ext4_bmap+0xa4/0x180 [ext4]
bmap+0x4c/0x80
jbd2_journal_init_inode+0x44/0x1a0 [jbd2]
ext4_load_journal+0x440/0x860 [ext4]
ext4_fill_super+0x342c/0x3ab0 [ext4]
mount_bdev+0x25c/0x290
ext4_mount+0x28/0x50 [ext4]
legacy_get_tree+0x4c/0xb0
vfs_get_tree+0x4c/0x130
do_mount+0xa18/0xc50
sys_mount+0x158/0x180
system_call+0x5c/0x68
The NIP points to NULL, or a random location (data even), while the LR
always points to the LEP of a function (with an offset of 8), indicating
that something went wrong with ftrace. However, ftrace is not
necessarily active when such crashes occur.
The kernel OOPS sometimes follows a warning from ftrace indicating that
some module functions could not be patched with a nop. Other times, if a
module is loaded early during boot, instruction patching can fail due to
a separate bug, but the error is not reported due to missing error
reporting.
In all the above cases when instruction patching fails, ftrace will be
disabled but certain kernel module functions will be left with default
calls to _mcount(). This is not a problem with ELFv1. However, with
-mprofile-kernel, the default stub is problematic since it depends on a
valid module TOC in r2. If the kernel (or a different module) calls into
a function that does not use the TOC, the function won't have a prologue
to setup the module TOC. When that function calls into _mcount(), we
will end up in the relocation stub that will use the previous TOC, and
end up trying to jump into a random location. From the above trace:
iomap_apply+0x20c/0x920 [kernel TOC]
|
V
ext4_iomap_end+0x8/0x30 [no GEP == kernel TOC]
|
V
_mcount() stub
[uses kernel TOC -> random entry]
To address this, let's change over to using the special stub that is
used for ftrace_[regs_]caller() for _mcount(). This ensures that we are
not dependent on a valid module TOC in r2 for default _mcount()
handling.
Reported-by: Qian Cai <cai@lca.pw>
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Tested-by: Qian Cai <cai@lca.pw>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/8affd4298d22099bbd82544fab8185700a6222b1.1587488954.git.naveen.n.rao@linux.vnet.ibm.com
2020-04-21 10:35:45 -07:00
|
|
|
value = stub_for_addr(sechdrs, value, me,
|
|
|
|
strtab + sym->st_name);
|
2005-04-16 15:20:36 -07:00
|
|
|
if (!value)
|
|
|
|
return -ENOENT;
|
2023-01-24 20:38:04 -07:00
|
|
|
if (restore_r2(strtab + sym->st_name,
|
|
|
|
(u32 *)location + 1, me))
|
2005-04-16 15:20:36 -07:00
|
|
|
return -ENOEXEC;
|
2014-03-18 17:12:22 -07:00
|
|
|
} else
|
|
|
|
value += local_entry_offset(sym);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
/* Convert value to relative */
|
|
|
|
value -= (unsigned long)location;
|
|
|
|
if (value + 0x2000000 > 0x3ffffff || (value & 3) != 0){
|
2014-09-16 21:39:35 -07:00
|
|
|
pr_err("%s: REL24 %li out of range!\n",
|
2005-04-16 15:20:36 -07:00
|
|
|
me->name, (long int)value);
|
|
|
|
return -ENOEXEC;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Only replace bits 2 through 26 */
|
2022-05-08 22:36:21 -07:00
|
|
|
value = (*(uint32_t *)location & ~PPC_LI_MASK) | PPC_LI(value);
|
2021-11-23 01:15:20 -07:00
|
|
|
|
|
|
|
if (patch_instruction((u32 *)location, ppc_inst(value)))
|
|
|
|
return -EFAULT;
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
break;
|
|
|
|
|
2006-10-19 18:47:19 -07:00
|
|
|
case R_PPC64_REL64:
|
|
|
|
/* 64 bits relative (used by features fixups) */
|
|
|
|
*location = value - (unsigned long)location;
|
|
|
|
break;
|
|
|
|
|
2016-10-25 20:51:12 -07:00
|
|
|
case R_PPC64_REL32:
|
|
|
|
/* 32 bits relative (used by relative exception tables) */
|
2018-08-29 04:56:56 -07:00
|
|
|
/* Convert value to relative */
|
|
|
|
value -= (unsigned long)location;
|
|
|
|
if (value + 0x80000000 > 0xffffffff) {
|
|
|
|
pr_err("%s: REL32 %li out of range!\n",
|
|
|
|
me->name, (long int)value);
|
|
|
|
return -ENOEXEC;
|
|
|
|
}
|
|
|
|
*(u32 *)location = value;
|
2016-10-25 20:51:12 -07:00
|
|
|
break;
|
|
|
|
|
2023-04-07 19:17:52 -07:00
|
|
|
#ifdef CONFIG_PPC_KERNEL_PCREL
|
|
|
|
case R_PPC64_PCREL34: {
|
|
|
|
unsigned long absvalue = value;
|
|
|
|
|
|
|
|
/* Convert value to relative */
|
|
|
|
value -= (unsigned long)location;
|
|
|
|
|
|
|
|
if (value + 0x200000000 > 0x3ffffffff) {
|
|
|
|
if (sym->st_shndx != me->arch.pcpu_section) {
|
|
|
|
pr_err("%s: REL34 %li out of range!\n",
|
|
|
|
me->name, (long)value);
|
|
|
|
return -ENOEXEC;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* per-cpu section is special cased because
|
|
|
|
* it is moved during loading, so has to be
|
|
|
|
* converted to use GOT.
|
|
|
|
*/
|
|
|
|
value = got_for_addr(sechdrs, absvalue, me,
|
|
|
|
strtab + sym->st_name);
|
|
|
|
if (!value)
|
|
|
|
return -ENOENT;
|
|
|
|
value -= (unsigned long)location;
|
|
|
|
|
|
|
|
/* Turn pla into pld */
|
|
|
|
if (patch_instruction((u32 *)location,
|
|
|
|
ppc_inst_prefix((*(u32 *)location & ~0x02000000),
|
|
|
|
(*((u32 *)location + 1) & ~0xf8000000) | 0xe4000000)))
|
|
|
|
return -EFAULT;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (patch_instruction((u32 *)location,
|
|
|
|
ppc_inst_prefix((*(u32 *)location & ~0x3ffff) | IMM_H18(value),
|
|
|
|
(*((u32 *)location + 1) & ~0xffff) | IMM_L(value))))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
#else
|
2014-03-18 00:06:28 -07:00
|
|
|
case R_PPC64_TOCSAVE:
|
|
|
|
/*
|
|
|
|
* Marker reloc indicates we don't have to save r2.
|
|
|
|
* That would only save us one instruction, so ignore
|
|
|
|
* it.
|
|
|
|
*/
|
|
|
|
break;
|
2023-04-07 19:17:52 -07:00
|
|
|
#endif
|
2014-03-18 00:06:28 -07:00
|
|
|
|
powerpc/module: Handle R_PPC64_ENTRY relocations
GCC 6 will include changes to generated code with -mcmodel=large,
which is used to build kernel modules on powerpc64le. This was
necessary because the large model is supposed to allow arbitrary
sizes and locations of the code and data sections, but the ELFv2
global entry point prolog still made the unconditional assumption
that the TOC associated with any particular function can be found
within 2 GB of the function entry point:
func:
addis r2,r12,(.TOC.-func)@ha
addi r2,r2,(.TOC.-func)@l
.localentry func, .-func
To remove this assumption, GCC will now generate instead this global
entry point prolog sequence when using -mcmodel=large:
.quad .TOC.-func
func:
.reloc ., R_PPC64_ENTRY
ld r2, -8(r12)
add r2, r2, r12
.localentry func, .-func
The new .reloc triggers an optimization in the linker that will
replace this new prolog with the original code (see above) if the
linker determines that the distance between .TOC. and func is in
range after all.
Since this new relocation is now present in module object files,
the kernel module loader is required to handle them too. This
patch adds support for the new relocation and implements the
same optimization done by the GNU linker.
Cc: stable@vger.kernel.org
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-01-12 05:14:23 -07:00
|
|
|
case R_PPC64_ENTRY:
|
2023-04-07 19:17:52 -07:00
|
|
|
if (IS_ENABLED(CONFIG_PPC_KERNEL_PCREL))
|
|
|
|
break;
|
|
|
|
|
powerpc/module: Handle R_PPC64_ENTRY relocations
GCC 6 will include changes to generated code with -mcmodel=large,
which is used to build kernel modules on powerpc64le. This was
necessary because the large model is supposed to allow arbitrary
sizes and locations of the code and data sections, but the ELFv2
global entry point prolog still made the unconditional assumption
that the TOC associated with any particular function can be found
within 2 GB of the function entry point:
func:
addis r2,r12,(.TOC.-func)@ha
addi r2,r2,(.TOC.-func)@l
.localentry func, .-func
To remove this assumption, GCC will now generate instead this global
entry point prolog sequence when using -mcmodel=large:
.quad .TOC.-func
func:
.reloc ., R_PPC64_ENTRY
ld r2, -8(r12)
add r2, r2, r12
.localentry func, .-func
The new .reloc triggers an optimization in the linker that will
replace this new prolog with the original code (see above) if the
linker determines that the distance between .TOC. and func is in
range after all.
Since this new relocation is now present in module object files,
the kernel module loader is required to handle them too. This
patch adds support for the new relocation and implements the
same optimization done by the GNU linker.
Cc: stable@vger.kernel.org
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-01-12 05:14:23 -07:00
|
|
|
/*
|
|
|
|
* Optimize ELFv2 large code model entry point if
|
|
|
|
* the TOC is within 2GB range of current location.
|
|
|
|
*/
|
|
|
|
value = my_r2(sechdrs, me) - (unsigned long)location;
|
|
|
|
if (value + 0x80008000 > 0xffffffff)
|
|
|
|
break;
|
|
|
|
/*
|
|
|
|
* Check for the large code model prolog sequence:
|
|
|
|
* ld r2, ...(r12)
|
|
|
|
* add r2, r2, r12
|
|
|
|
*/
|
2021-05-20 03:23:04 -07:00
|
|
|
if ((((uint32_t *)location)[0] & ~0xfffc) != PPC_RAW_LD(_R2, _R12, 0))
|
powerpc/module: Handle R_PPC64_ENTRY relocations
GCC 6 will include changes to generated code with -mcmodel=large,
which is used to build kernel modules on powerpc64le. This was
necessary because the large model is supposed to allow arbitrary
sizes and locations of the code and data sections, but the ELFv2
global entry point prolog still made the unconditional assumption
that the TOC associated with any particular function can be found
within 2 GB of the function entry point:
func:
addis r2,r12,(.TOC.-func)@ha
addi r2,r2,(.TOC.-func)@l
.localentry func, .-func
To remove this assumption, GCC will now generate instead this global
entry point prolog sequence when using -mcmodel=large:
.quad .TOC.-func
func:
.reloc ., R_PPC64_ENTRY
ld r2, -8(r12)
add r2, r2, r12
.localentry func, .-func
The new .reloc triggers an optimization in the linker that will
replace this new prolog with the original code (see above) if the
linker determines that the distance between .TOC. and func is in
range after all.
Since this new relocation is now present in module object files,
the kernel module loader is required to handle them too. This
patch adds support for the new relocation and implements the
same optimization done by the GNU linker.
Cc: stable@vger.kernel.org
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-01-12 05:14:23 -07:00
|
|
|
break;
|
2021-05-20 03:23:04 -07:00
|
|
|
if (((uint32_t *)location)[1] != PPC_RAW_ADD(_R2, _R2, _R12))
|
powerpc/module: Handle R_PPC64_ENTRY relocations
GCC 6 will include changes to generated code with -mcmodel=large,
which is used to build kernel modules on powerpc64le. This was
necessary because the large model is supposed to allow arbitrary
sizes and locations of the code and data sections, but the ELFv2
global entry point prolog still made the unconditional assumption
that the TOC associated with any particular function can be found
within 2 GB of the function entry point:
func:
addis r2,r12,(.TOC.-func)@ha
addi r2,r2,(.TOC.-func)@l
.localentry func, .-func
To remove this assumption, GCC will now generate instead this global
entry point prolog sequence when using -mcmodel=large:
.quad .TOC.-func
func:
.reloc ., R_PPC64_ENTRY
ld r2, -8(r12)
add r2, r2, r12
.localentry func, .-func
The new .reloc triggers an optimization in the linker that will
replace this new prolog with the original code (see above) if the
linker determines that the distance between .TOC. and func is in
range after all.
Since this new relocation is now present in module object files,
the kernel module loader is required to handle them too. This
patch adds support for the new relocation and implements the
same optimization done by the GNU linker.
Cc: stable@vger.kernel.org
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-01-12 05:14:23 -07:00
|
|
|
break;
|
|
|
|
/*
|
|
|
|
* If found, replace it with:
|
|
|
|
* addis r2, r12, (.TOC.-func)@ha
|
2019-07-05 07:18:53 -07:00
|
|
|
* addi r2, r2, (.TOC.-func)@l
|
powerpc/module: Handle R_PPC64_ENTRY relocations
GCC 6 will include changes to generated code with -mcmodel=large,
which is used to build kernel modules on powerpc64le. This was
necessary because the large model is supposed to allow arbitrary
sizes and locations of the code and data sections, but the ELFv2
global entry point prolog still made the unconditional assumption
that the TOC associated with any particular function can be found
within 2 GB of the function entry point:
func:
addis r2,r12,(.TOC.-func)@ha
addi r2,r2,(.TOC.-func)@l
.localentry func, .-func
To remove this assumption, GCC will now generate instead this global
entry point prolog sequence when using -mcmodel=large:
.quad .TOC.-func
func:
.reloc ., R_PPC64_ENTRY
ld r2, -8(r12)
add r2, r2, r12
.localentry func, .-func
The new .reloc triggers an optimization in the linker that will
replace this new prolog with the original code (see above) if the
linker determines that the distance between .TOC. and func is in
range after all.
Since this new relocation is now present in module object files,
the kernel module loader is required to handle them too. This
patch adds support for the new relocation and implements the
same optimization done by the GNU linker.
Cc: stable@vger.kernel.org
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-01-12 05:14:23 -07:00
|
|
|
*/
|
2021-05-20 03:23:04 -07:00
|
|
|
((uint32_t *)location)[0] = PPC_RAW_ADDIS(_R2, _R12, PPC_HA(value));
|
|
|
|
((uint32_t *)location)[1] = PPC_RAW_ADDI(_R2, _R2, PPC_LO(value));
|
powerpc/module: Handle R_PPC64_ENTRY relocations
GCC 6 will include changes to generated code with -mcmodel=large,
which is used to build kernel modules on powerpc64le. This was
necessary because the large model is supposed to allow arbitrary
sizes and locations of the code and data sections, but the ELFv2
global entry point prolog still made the unconditional assumption
that the TOC associated with any particular function can be found
within 2 GB of the function entry point:
func:
addis r2,r12,(.TOC.-func)@ha
addi r2,r2,(.TOC.-func)@l
.localentry func, .-func
To remove this assumption, GCC will now generate instead this global
entry point prolog sequence when using -mcmodel=large:
.quad .TOC.-func
func:
.reloc ., R_PPC64_ENTRY
ld r2, -8(r12)
add r2, r2, r12
.localentry func, .-func
The new .reloc triggers an optimization in the linker that will
replace this new prolog with the original code (see above) if the
linker determines that the distance between .TOC. and func is in
range after all.
Since this new relocation is now present in module object files,
the kernel module loader is required to handle them too. This
patch adds support for the new relocation and implements the
same optimization done by the GNU linker.
Cc: stable@vger.kernel.org
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-01-12 05:14:23 -07:00
|
|
|
break;
|
|
|
|
|
2014-03-18 02:29:27 -07:00
|
|
|
case R_PPC64_REL16_HA:
|
|
|
|
/* Subtract location pointer */
|
|
|
|
value -= (unsigned long)location;
|
|
|
|
value = ((value + 0x8000) >> 16);
|
|
|
|
*((uint16_t *) location)
|
|
|
|
= (*((uint16_t *) location) & ~0xffff)
|
|
|
|
| (value & 0xffff);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case R_PPC64_REL16_LO:
|
|
|
|
/* Subtract location pointer */
|
|
|
|
value -= (unsigned long)location;
|
|
|
|
*((uint16_t *) location)
|
|
|
|
= (*((uint16_t *) location) & ~0xffff)
|
|
|
|
| (value & 0xffff);
|
|
|
|
break;
|
|
|
|
|
2023-04-07 19:17:52 -07:00
|
|
|
#ifdef CONFIG_PPC_KERNEL_PCREL
|
|
|
|
case R_PPC64_GOT_PCREL34:
|
|
|
|
value = got_for_addr(sechdrs, value, me,
|
|
|
|
strtab + sym->st_name);
|
|
|
|
if (!value)
|
|
|
|
return -ENOENT;
|
|
|
|
value -= (unsigned long)location;
|
|
|
|
((uint32_t *)location)[0] = (((uint32_t *)location)[0] & ~0x3ffff) |
|
|
|
|
((value >> 16) & 0x3ffff);
|
|
|
|
((uint32_t *)location)[1] = (((uint32_t *)location)[1] & ~0xffff) |
|
|
|
|
(value & 0xffff);
|
|
|
|
break;
|
|
|
|
#endif
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
default:
|
2014-09-16 21:39:35 -07:00
|
|
|
pr_err("%s: Unknown ADD relocation: %lu\n",
|
2005-04-16 15:20:36 -07:00
|
|
|
me->name,
|
|
|
|
(unsigned long)ELF64_R_TYPE(rela[i].r_info));
|
|
|
|
return -ENOEXEC;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-03-02 21:26:54 -07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-11-14 21:47:03 -07:00
|
|
|
#ifdef CONFIG_DYNAMIC_FTRACE
|
2020-04-21 10:35:43 -07:00
|
|
|
int module_trampoline_target(struct module *mod, unsigned long addr,
|
|
|
|
unsigned long *target)
|
|
|
|
{
|
|
|
|
struct ppc64_stub_entry *stub;
|
|
|
|
func_desc_t funcdata;
|
|
|
|
u32 magic;
|
|
|
|
|
|
|
|
if (!within_module_core(addr, mod)) {
|
|
|
|
pr_err("%s: stub %lx not in module %s\n", __func__, addr, mod->name);
|
|
|
|
return -EFAULT;
|
|
|
|
}
|
|
|
|
|
|
|
|
stub = (struct ppc64_stub_entry *)addr;
|
|
|
|
|
2020-06-17 00:37:53 -07:00
|
|
|
if (copy_from_kernel_nofault(&magic, &stub->magic,
|
|
|
|
sizeof(magic))) {
|
2020-04-21 10:35:43 -07:00
|
|
|
pr_err("%s: fault reading magic for stub %lx for %s\n", __func__, addr, mod->name);
|
|
|
|
return -EFAULT;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (magic != STUB_MAGIC) {
|
|
|
|
pr_err("%s: bad magic for stub %lx for %s\n", __func__, addr, mod->name);
|
|
|
|
return -EFAULT;
|
|
|
|
}
|
|
|
|
|
2020-06-17 00:37:53 -07:00
|
|
|
if (copy_from_kernel_nofault(&funcdata, &stub->funcdata,
|
|
|
|
sizeof(funcdata))) {
|
2020-04-21 10:35:43 -07:00
|
|
|
pr_err("%s: fault reading funcdata for stub %lx for %s\n", __func__, addr, mod->name);
|
|
|
|
return -EFAULT;
|
|
|
|
}
|
|
|
|
|
|
|
|
*target = stub_func_addr(funcdata);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2016-03-02 21:26:56 -07:00
|
|
|
|
2016-03-02 21:26:54 -07:00
|
|
|
int module_finalize_ftrace(struct module *mod, const Elf_Shdr *sechdrs)
|
|
|
|
{
|
powerpc/module_64: Use special stub for _mcount() with -mprofile-kernel
Since commit c55d7b5e64265f ("powerpc: Remove STRICT_KERNEL_RWX
incompatibility with RELOCATABLE"), powerpc kernels with
-mprofile-kernel can crash in certain scenarios with a trace like below:
BUG: Unable to handle kernel instruction fetch (NULL pointer?)
Faulting instruction address: 0x00000000
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=256 DEBUG_PAGEALLOC NUMA PowerNV
<snip>
NIP [0000000000000000] 0x0
LR [c0080000102c0048] ext4_iomap_end+0x8/0x30 [ext4]
Call Trace:
iomap_apply+0x20c/0x920 (unreliable)
iomap_bmap+0xfc/0x160
ext4_bmap+0xa4/0x180 [ext4]
bmap+0x4c/0x80
jbd2_journal_init_inode+0x44/0x1a0 [jbd2]
ext4_load_journal+0x440/0x860 [ext4]
ext4_fill_super+0x342c/0x3ab0 [ext4]
mount_bdev+0x25c/0x290
ext4_mount+0x28/0x50 [ext4]
legacy_get_tree+0x4c/0xb0
vfs_get_tree+0x4c/0x130
do_mount+0xa18/0xc50
sys_mount+0x158/0x180
system_call+0x5c/0x68
The NIP points to NULL, or a random location (data even), while the LR
always points to the LEP of a function (with an offset of 8), indicating
that something went wrong with ftrace. However, ftrace is not
necessarily active when such crashes occur.
The kernel OOPS sometimes follows a warning from ftrace indicating that
some module functions could not be patched with a nop. Other times, if a
module is loaded early during boot, instruction patching can fail due to
a separate bug, but the error is not reported due to missing error
reporting.
In all the above cases when instruction patching fails, ftrace will be
disabled but certain kernel module functions will be left with default
calls to _mcount(). This is not a problem with ELFv1. However, with
-mprofile-kernel, the default stub is problematic since it depends on a
valid module TOC in r2. If the kernel (or a different module) calls into
a function that does not use the TOC, the function won't have a prologue
to setup the module TOC. When that function calls into _mcount(), we
will end up in the relocation stub that will use the previous TOC, and
end up trying to jump into a random location. From the above trace:
iomap_apply+0x20c/0x920 [kernel TOC]
|
V
ext4_iomap_end+0x8/0x30 [no GEP == kernel TOC]
|
V
_mcount() stub
[uses kernel TOC -> random entry]
To address this, let's change over to using the special stub that is
used for ftrace_[regs_]caller() for _mcount(). This ensures that we are
not dependent on a valid module TOC in r2 for default _mcount()
handling.
Reported-by: Qian Cai <cai@lca.pw>
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Tested-by: Qian Cai <cai@lca.pw>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/8affd4298d22099bbd82544fab8185700a6222b1.1587488954.git.naveen.n.rao@linux.vnet.ibm.com
2020-04-21 10:35:45 -07:00
|
|
|
mod->arch.tramp = stub_for_addr(sechdrs,
|
|
|
|
(unsigned long)ftrace_caller,
|
|
|
|
mod,
|
|
|
|
"ftrace_caller");
|
2018-04-19 00:04:09 -07:00
|
|
|
#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
|
powerpc/module_64: Use special stub for _mcount() with -mprofile-kernel
Since commit c55d7b5e64265f ("powerpc: Remove STRICT_KERNEL_RWX
incompatibility with RELOCATABLE"), powerpc kernels with
-mprofile-kernel can crash in certain scenarios with a trace like below:
BUG: Unable to handle kernel instruction fetch (NULL pointer?)
Faulting instruction address: 0x00000000
Oops: Kernel access of bad area, sig: 11 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=256 DEBUG_PAGEALLOC NUMA PowerNV
<snip>
NIP [0000000000000000] 0x0
LR [c0080000102c0048] ext4_iomap_end+0x8/0x30 [ext4]
Call Trace:
iomap_apply+0x20c/0x920 (unreliable)
iomap_bmap+0xfc/0x160
ext4_bmap+0xa4/0x180 [ext4]
bmap+0x4c/0x80
jbd2_journal_init_inode+0x44/0x1a0 [jbd2]
ext4_load_journal+0x440/0x860 [ext4]
ext4_fill_super+0x342c/0x3ab0 [ext4]
mount_bdev+0x25c/0x290
ext4_mount+0x28/0x50 [ext4]
legacy_get_tree+0x4c/0xb0
vfs_get_tree+0x4c/0x130
do_mount+0xa18/0xc50
sys_mount+0x158/0x180
system_call+0x5c/0x68
The NIP points to NULL, or a random location (data even), while the LR
always points to the LEP of a function (with an offset of 8), indicating
that something went wrong with ftrace. However, ftrace is not
necessarily active when such crashes occur.
The kernel OOPS sometimes follows a warning from ftrace indicating that
some module functions could not be patched with a nop. Other times, if a
module is loaded early during boot, instruction patching can fail due to
a separate bug, but the error is not reported due to missing error
reporting.
In all the above cases when instruction patching fails, ftrace will be
disabled but certain kernel module functions will be left with default
calls to _mcount(). This is not a problem with ELFv1. However, with
-mprofile-kernel, the default stub is problematic since it depends on a
valid module TOC in r2. If the kernel (or a different module) calls into
a function that does not use the TOC, the function won't have a prologue
to setup the module TOC. When that function calls into _mcount(), we
will end up in the relocation stub that will use the previous TOC, and
end up trying to jump into a random location. From the above trace:
iomap_apply+0x20c/0x920 [kernel TOC]
|
V
ext4_iomap_end+0x8/0x30 [no GEP == kernel TOC]
|
V
_mcount() stub
[uses kernel TOC -> random entry]
To address this, let's change over to using the special stub that is
used for ftrace_[regs_]caller() for _mcount(). This ensures that we are
not dependent on a valid module TOC in r2 for default _mcount()
handling.
Reported-by: Qian Cai <cai@lca.pw>
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Tested-by: Qian Cai <cai@lca.pw>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/8affd4298d22099bbd82544fab8185700a6222b1.1587488954.git.naveen.n.rao@linux.vnet.ibm.com
2020-04-21 10:35:45 -07:00
|
|
|
mod->arch.tramp_regs = stub_for_addr(sechdrs,
|
|
|
|
(unsigned long)ftrace_regs_caller,
|
|
|
|
mod,
|
|
|
|
"ftrace_regs_caller");
|
2018-04-19 00:04:09 -07:00
|
|
|
if (!mod->arch.tramp_regs)
|
|
|
|
return -ENOENT;
|
|
|
|
#endif
|
2016-03-02 21:26:54 -07:00
|
|
|
|
|
|
|
if (!mod->arch.tramp)
|
|
|
|
return -ENOENT;
|
2008-11-14 21:47:03 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
return 0;
|
|
|
|
}
|
2016-03-02 21:26:54 -07:00
|
|
|
#endif
|