arm64: module-plts: factor out PLT generation code for ftrace

When building the arm64 kernel with both CONFIG_ARM64_MODULE_PLTS and CONFIG_DYNAMIC_FTRACE enabled, the ftrace-mod.o object file is built with the kernel and contains a trampoline that is linked into each module, so that modules can be loaded far away from the kernel and still reach the ftrace entry point in the core kernel with an ordinary relative branch, as is emitted by the compiler instrumentation code dynamic ftrace relies on.

In order to be able to build out of tree modules, this object file needs to be included into the linux-headers or linux-devel packages, which is undesirable, as it makes arm64 a special case (although a precedent does exist for 32-bit PPC).

Given that the trampoline essentially consists of a PLT entry, let's not bother with a source or object file for it, and simply patch it in whenever the trampoline is being populated, using the existing PLT support routines.

Quoted 13 lines · Ard Biesheuvel

When building the arm64 kernel with both CONFIG_ARM64_MODULE_PLTS and CONFIG_DYNAMIC_FTRACE enabled, the ftrace-mod.o object file is built with the kernel and contains a trampoline that is linked into each module, so that modules can be loaded far away from the kernel and still reach the ftrace entry point in the core kernel with an ordinary relative branch, as is emitted by the compiler instrumentation code dynamic ftrace relies on.

In order to be able to build out of tree modules, this object file needs to be included into the linux-headers or linux-devel packages, which is undesirable, as it makes arm64 a special case (although a precedent does exist for 32-bit PPC).

Quoted 4 lines

Given that the trampoline essentially consists of a PLT entry, let's not bother with a source or object file for it, and simply patch it in whenever the trampoline is being populated, using the existing PLT support routines.

I'll pick these two up for 4.15. Do you think they need to go to stable as well?

Quoted 19 lines · Will Deacon

Quoted 17 lines · Ard Biesheuvel

When building the arm64 kernel with both CONFIG_ARM64_MODULE_PLTS and CONFIG_DYNAMIC_FTRACE enabled, the ftrace-mod.o object file is built with the kernel and contains a trampoline that is linked into each module, so that modules can be loaded far away from the kernel and still reach the ftrace entry point in the core kernel with an ordinary relative branch, as is emitted by the compiler instrumentation code dynamic ftrace relies on.

In order to be able to build out of tree modules, this object file needs to be included into the linux-headers or linux-devel packages, which is undesirable, as it makes arm64 a special case (although a precedent does exist for 32-bit PPC).

Given that the trampoline essentially consists of a PLT entry, let's not bother with a source or object file for it, and simply patch it in whenever the trampoline is being populated, using the existing PLT support routines.

Quoted 2 lines

I'll pick these two up for 4.15. Do you think they need to go to stable as well?

It is either that, or the distros need to backport themselves. Not sure whether it matters much tbh.

To allow the ftrace trampoline code to reuse the PLT entry routines, factor it out and move it into asm/module.h.

Signed-off-by Ard Biesheuvel <[email protected]>

---
v3: new patch

 arch/arm64/include/asm/module.h | 44 ++++++++++++++++++++
 arch/arm64/kernel/module-plts.c | 38 +----------------
 2 files changed, 46 insertions(+), 36 deletions(-)

arch/arm64/include/asm/module.h +25 -0

index 19bd97671bb8..11d4aaee82e1 100644
@@ -45,4 +45,48 @@ extern u64 module_alloc_base;
 #define module_alloc_base	((u64)_etext - MODULES_VSIZE)
 #endif
 
+struct plt_entry {
+	/*
+	 * A program that conforms to the AArch64 Procedure Call Standard
+	 * (AAPCS64) must assume that a veneer that alters IP0 (x16) and/or
+	 * IP1 (x17) may be inserted at any branch instruction that is
+	 * exposed to a relocation that supports long branches. Since that
+	 * is exactly what we are dealing with here, we are free to use x16
+	 * as a scratch register in the PLT veneers.
+	 */
+	__le32	mov0;	/* movn	x16, #0x....			*/
+	__le32	mov1;	/* movk	x16, #0x...., lsl #16		*/
+	__le32	mov2;	/* movk	x16, #0x...., lsl #32		*/
+	__le32	br;	/* br	x16				*/
+};
+
+static inline struct plt_entry get_plt_entry(u64 val)
+{
+	/*
+	 * MOVK/MOVN/MOVZ opcode:
+	 * +--------+------------+--------+-----------+-------------+---------+
+	 * | sf[31] | opc[30:29] | 100101 | hw[22:21] | imm16[20:5] | Rd[4:0] |
+	 * +--------+------------+--------+-----------+-------------+---------+
+	 *
+	 * Rd     := 0x10 (x16)
+	 * hw     := 0b00 (no shift), 0b01 (lsl #16), 0b10 (lsl #32)

Quoted 49 lines · Ard Biesheuvel

To allow the ftrace trampoline code to reuse the PLT entry routines, factor it out and move it into asm/module.h.

Signed-off-by Ard Biesheuvel <[email protected]>

---
v3: new patch

 arch/arm64/include/asm/module.h | 44 ++++++++++++++++++++
 arch/arm64/kernel/module-plts.c | 38 +----------------
 2 files changed, 46 insertions(+), 36 deletions(-)

arch/arm64/include/asm/module.h +30 -0

index 19bd97671bb8..11d4aaee82e1 100644
@@ -45,4 +45,48 @@ extern u64 module_alloc_base;
 #define module_alloc_base    ((u64)_etext - MODULES_VSIZE)
 #endif
 
+struct plt_entry {
+     /*
+      * A program that conforms to the AArch64 Procedure Call Standard
+      * (AAPCS64) must assume that a veneer that alters IP0 (x16) and/or
+      * IP1 (x17) may be inserted at any branch instruction that is
+      * exposed to a relocation that supports long branches. Since that
+      * is exactly what we are dealing with here, we are free to use x16
+      * as a scratch register in the PLT veneers.
+      */
+     __le32  mov0;   /* movn x16, #0x....                    */
+     __le32  mov1;   /* movk x16, #0x...., lsl #16           */
+     __le32  mov2;   /* movk x16, #0x...., lsl #32           */
+     __le32  br;     /* br   x16                             */
+};
+
+static inline struct plt_entry get_plt_entry(u64 val)
+{
+     /*
+      * MOVK/MOVN/MOVZ opcode:
+      * +--------+------------+--------+-----------+-------------+---------+
+      * | sf[31] | opc[30:29] | 100101 | hw[22:21] | imm16[20:5] | Rd[4:0] |
+      * +--------+------------+--------+-----------+-------------+---------+
+      *
+      * Rd     := 0x10 (x16)
+      * hw     := 0b00 (no shift), 0b01 (lsl #16), 0b10 (lsl #32)
+      * opc    := 0b11 (MOVK), 0b00 (MOVN), 0b10 (MOVZ)
+      * sf     := 1 (64-bit variant)
+      */
+     return (struct plt_entry){
+             cpu_to_le32(0x92800010 | (((~val      ) & 0xffff)) << 5),

arch/arm64/include/asm/module.h extern u64 module_alloc_base; · line 82

Quoted 5 lines

arch/arm64/include/asm/module.h +5 -0

+             cpu_to_le32(0xf2a00010 | ((( val >> 16) & 0xffff)) << 5),
+             cpu_to_le32(0xf2c00010 | ((( val >> 32) & 0xffff)) << 5),
+             cpu_to_le32(0xd61f0200)
+     };
+}

Not one for this series, but do you think we could use insn.c to generate these?