* [RFC PATCH 00/17] objtool: add base support for arm64 @ 2021-01-20 17:37 ` Julien Thierry 0 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: catalin.marinas, will, ardb, masahiroy, keescook, michal.lkml, jpoimboe, peterz, mark.rutland, broonie, linux-efi, linux-hardening, Julien Thierry Hi, This series enables objtool to start doing stack validation on arm64 kernel builds. It relies on the previous series I sent, refactoring the arm64 decoder [1]. First, the aarch64 instruction decoder needed to be made available to code under tools/. This is done in a similar manner to x86 instruction decoded. One limitation I encountered there is that most of aarch64 instruction decoder is __kprobe annotated. To bypass that it remove the kprobe include and had to add an empty __kprobe definition, but I'd welcome a proper solution to that. Then instruction semantics are progressively added so objtool can track the stack state through the execution flow. There are a few things that needed consideration: - Generation of constants within executable sections, these either caused objtool to fail decoding or to wrongly decode constants as jumps or other instructions affecting execution flow and causing confusion. To solve this, tracking locations referenced by instructions using literals was needed. - Jump tables from switch statements in aarch64 don't have enough information to link branches with the branch instruction leading to them. For this, we use a gcc plugin to add some information to establish those missing links in a format that is already supported by objtool With this, there are still some errors when building with objtool. A number of cleanups/annotations are needed on the arm64, as well as handling SYM_DATA objects in objtool. Those changes can be found on top of this branch here: git clone https://github.com/julien-thierry/linux.git -b objtoolxarm64-latest But it would be nice to have some feedback on this before I start submitting everyting. [1] https://lkml.org/lkml/2021/1/20/791 Thanks, Julien --> Julien Thierry (15): tools: Add some generic functions and headers tools: arm64: Make aarch64 instruction decoder available to tools tools: bug: Remove duplicate definition objtool: arm64: Add base definition for arm64 backend objtool: arm64: Decode add/sub instructions objtool: arm64: Decode jump and call related instructions objtool: arm64: Decode other system instructions objtool: arm64: Decode load/store instructions objtool: arm64: Decode LDR instructions objtool: arm64: Accept padding in code sections efi: libstub: Ignore relocations for .discard sections objtool: arm64: Implement functions to add switch tables alternatives objtool: arm64: Cache section with switch table information objtool: arm64: Handle supported relocations in alternatives objtool: arm64: Ignore replacement section for alternative callback Raphael Gault (2): gcc-plugins: objtool: Add plugin to detect switch table on arm64 objtool: arm64: Enable stack validation for arm64 arch/arm64/Kconfig | 2 + drivers/firmware/efi/libstub/Makefile | 2 +- scripts/Makefile.gcc-plugins | 2 + scripts/gcc-plugins/Kconfig | 4 + .../arm64_switch_table_detection_plugin.c | 85 + tools/arch/arm64/include/asm/aarch64-insn.h | 551 +++++++ tools/arch/arm64/lib/aarch64-insn.c | 1425 +++++++++++++++++ tools/include/asm-generic/bitops/__ffs.h | 11 + tools/include/linux/bug.h | 6 +- tools/include/linux/kernel.h | 21 + tools/include/linux/printk.h | 40 + tools/objtool/Makefile | 5 + tools/objtool/arch/arm64/Build | 8 + tools/objtool/arch/arm64/decode.c | 471 ++++++ .../arch/arm64/include/arch/cfi_regs.h | 14 + tools/objtool/arch/arm64/include/arch/elf.h | 6 + .../arch/arm64/include/arch/endianness.h | 9 + .../objtool/arch/arm64/include/arch/special.h | 23 + tools/objtool/arch/arm64/special.c | 134 ++ tools/objtool/arch/x86/decode.c | 5 + tools/objtool/check.c | 6 + tools/objtool/include/objtool/arch.h | 3 + tools/objtool/sync-check.sh | 5 + 23 files changed, 2832 insertions(+), 6 deletions(-) create mode 100644 scripts/gcc-plugins/arm64_switch_table_detection_plugin.c create mode 100644 tools/arch/arm64/include/asm/aarch64-insn.h create mode 100644 tools/arch/arm64/lib/aarch64-insn.c create mode 100644 tools/include/linux/printk.h create mode 100644 tools/objtool/arch/arm64/Build create mode 100644 tools/objtool/arch/arm64/decode.c create mode 100644 tools/objtool/arch/arm64/include/arch/cfi_regs.h create mode 100644 tools/objtool/arch/arm64/include/arch/elf.h create mode 100644 tools/objtool/arch/arm64/include/arch/endianness.h create mode 100644 tools/objtool/arch/arm64/include/arch/special.h create mode 100644 tools/objtool/arch/arm64/special.c -- 2.25.4 ^ permalink raw reply [flat|nested] 106+ messages in thread
* [RFC PATCH 00/17] objtool: add base support for arm64 @ 2021-01-20 17:37 ` Julien Thierry 0 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: mark.rutland, linux-efi, michal.lkml, keescook, peterz, catalin.marinas, masahiroy, broonie, linux-hardening, jpoimboe, will, ardb, Julien Thierry Hi, This series enables objtool to start doing stack validation on arm64 kernel builds. It relies on the previous series I sent, refactoring the arm64 decoder [1]. First, the aarch64 instruction decoder needed to be made available to code under tools/. This is done in a similar manner to x86 instruction decoded. One limitation I encountered there is that most of aarch64 instruction decoder is __kprobe annotated. To bypass that it remove the kprobe include and had to add an empty __kprobe definition, but I'd welcome a proper solution to that. Then instruction semantics are progressively added so objtool can track the stack state through the execution flow. There are a few things that needed consideration: - Generation of constants within executable sections, these either caused objtool to fail decoding or to wrongly decode constants as jumps or other instructions affecting execution flow and causing confusion. To solve this, tracking locations referenced by instructions using literals was needed. - Jump tables from switch statements in aarch64 don't have enough information to link branches with the branch instruction leading to them. For this, we use a gcc plugin to add some information to establish those missing links in a format that is already supported by objtool With this, there are still some errors when building with objtool. A number of cleanups/annotations are needed on the arm64, as well as handling SYM_DATA objects in objtool. Those changes can be found on top of this branch here: git clone https://github.com/julien-thierry/linux.git -b objtoolxarm64-latest But it would be nice to have some feedback on this before I start submitting everyting. [1] https://lkml.org/lkml/2021/1/20/791 Thanks, Julien --> Julien Thierry (15): tools: Add some generic functions and headers tools: arm64: Make aarch64 instruction decoder available to tools tools: bug: Remove duplicate definition objtool: arm64: Add base definition for arm64 backend objtool: arm64: Decode add/sub instructions objtool: arm64: Decode jump and call related instructions objtool: arm64: Decode other system instructions objtool: arm64: Decode load/store instructions objtool: arm64: Decode LDR instructions objtool: arm64: Accept padding in code sections efi: libstub: Ignore relocations for .discard sections objtool: arm64: Implement functions to add switch tables alternatives objtool: arm64: Cache section with switch table information objtool: arm64: Handle supported relocations in alternatives objtool: arm64: Ignore replacement section for alternative callback Raphael Gault (2): gcc-plugins: objtool: Add plugin to detect switch table on arm64 objtool: arm64: Enable stack validation for arm64 arch/arm64/Kconfig | 2 + drivers/firmware/efi/libstub/Makefile | 2 +- scripts/Makefile.gcc-plugins | 2 + scripts/gcc-plugins/Kconfig | 4 + .../arm64_switch_table_detection_plugin.c | 85 + tools/arch/arm64/include/asm/aarch64-insn.h | 551 +++++++ tools/arch/arm64/lib/aarch64-insn.c | 1425 +++++++++++++++++ tools/include/asm-generic/bitops/__ffs.h | 11 + tools/include/linux/bug.h | 6 +- tools/include/linux/kernel.h | 21 + tools/include/linux/printk.h | 40 + tools/objtool/Makefile | 5 + tools/objtool/arch/arm64/Build | 8 + tools/objtool/arch/arm64/decode.c | 471 ++++++ .../arch/arm64/include/arch/cfi_regs.h | 14 + tools/objtool/arch/arm64/include/arch/elf.h | 6 + .../arch/arm64/include/arch/endianness.h | 9 + .../objtool/arch/arm64/include/arch/special.h | 23 + tools/objtool/arch/arm64/special.c | 134 ++ tools/objtool/arch/x86/decode.c | 5 + tools/objtool/check.c | 6 + tools/objtool/include/objtool/arch.h | 3 + tools/objtool/sync-check.sh | 5 + 23 files changed, 2832 insertions(+), 6 deletions(-) create mode 100644 scripts/gcc-plugins/arm64_switch_table_detection_plugin.c create mode 100644 tools/arch/arm64/include/asm/aarch64-insn.h create mode 100644 tools/arch/arm64/lib/aarch64-insn.c create mode 100644 tools/include/linux/printk.h create mode 100644 tools/objtool/arch/arm64/Build create mode 100644 tools/objtool/arch/arm64/decode.c create mode 100644 tools/objtool/arch/arm64/include/arch/cfi_regs.h create mode 100644 tools/objtool/arch/arm64/include/arch/elf.h create mode 100644 tools/objtool/arch/arm64/include/arch/endianness.h create mode 100644 tools/objtool/arch/arm64/include/arch/special.h create mode 100644 tools/objtool/arch/arm64/special.c -- 2.25.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* [RFC PATCH 01/17] tools: Add some generic functions and headers 2021-01-20 17:37 ` Julien Thierry @ 2021-01-20 17:37 ` Julien Thierry -1 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: catalin.marinas, will, ardb, masahiroy, keescook, michal.lkml, jpoimboe, peterz, mark.rutland, broonie, linux-efi, linux-hardening, Julien Thierry These will be needed to be able to use arm64 instruction decoder in userland tools. Signed-off-by: Julien Thierry <jthierry@redhat.com> --- tools/include/asm-generic/bitops/__ffs.h | 11 +++++++ tools/include/linux/kernel.h | 21 +++++++++++++ tools/include/linux/printk.h | 40 ++++++++++++++++++++++++ 3 files changed, 72 insertions(+) create mode 100644 tools/include/linux/printk.h diff --git a/tools/include/asm-generic/bitops/__ffs.h b/tools/include/asm-generic/bitops/__ffs.h index 9d1310519497..963f8a22212f 100644 --- a/tools/include/asm-generic/bitops/__ffs.h +++ b/tools/include/asm-generic/bitops/__ffs.h @@ -42,4 +42,15 @@ static __always_inline unsigned long __ffs(unsigned long word) return num; } +static inline unsigned long __ffs64(u64 word) +{ +#if BITS_PER_LONG == 32 + if (((u32)word) == 0UL) + return __ffs((u32)(word >> 32)) + 32; +#elif BITS_PER_LONG != 64 +#error BITS_PER_LONG not 32 or 64 +#endif + return __ffs((unsigned long)word); +} + #endif /* _TOOLS_LINUX_ASM_GENERIC_BITOPS___FFS_H_ */ diff --git a/tools/include/linux/kernel.h b/tools/include/linux/kernel.h index a7e54a08fb54..e748982ed5c1 100644 --- a/tools/include/linux/kernel.h +++ b/tools/include/linux/kernel.h @@ -114,6 +114,27 @@ int scnprintf_pad(char * buf, size_t size, const char * fmt, ...); #define round_up(x, y) ((((x)-1) | __round_mask(x, y))+1) #define round_down(x, y) ((x) & ~__round_mask(x, y)) +/** + * upper_32_bits - return bits 32-63 of a number + * @n: the number we're accessing + * + * A basic shift-right of a 64- or 32-bit quantity. Use this to suppress + * the "right shift count >= width of type" warning when that quantity is + * 32-bits. + */ +#define upper_32_bits(n) ((u32)(((n) >> 16) >> 16)) + +/** + * lower_32_bits - return bits 0-31 of a number + * @n: the number we're accessing + */ +#define lower_32_bits(n) ((u32)(n)) + +/* Inspired from ALIGN_*_KERNEL */ +#define __ALIGN_MASK(x, mask) (((x) + (mask)) & ~(mask)) +#define __ALIGN(x, a) __ALIGN_MASK(x, (typeof(x))(a) - 1) +#define ALIGN_DOWN(x, a) __ALIGN((x) - ((a) - 1), (a)) + #define current_gfp_context(k) 0 #define synchronize_rcu() diff --git a/tools/include/linux/printk.h b/tools/include/linux/printk.h new file mode 100644 index 000000000000..515ebdc47e6e --- /dev/null +++ b/tools/include/linux/printk.h @@ -0,0 +1,40 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _TOOLS_LINUX_KERNEL_PRINTK_H_ +#define _TOOLS_LINUX_KERNEL_PRINTK_H_ + +#include <stdarg.h> +#include <stdio.h> +#include <stdlib.h> + +#define printk(fmt, ...) fprintf(stdout, fmt, ##__VA_ARGS__) +#define pr_info printk +#define pr_notice printk +#define pr_cont printk + +#define pr_warn(fmt, ...) fprintf(stderr, fmt, ##__VA_ARGS__) +#define pr_err pr_warn +#define pr_alert pr_warn +#define pr_emerg pr_warn +#define pr_crit pr_warn + +/* + * Dummy printk for disabled debugging statements to use whilst maintaining + * gcc's format checking. + */ +#define no_printk(fmt, ...) \ +({ \ + if (0) \ + printk(fmt, ##__VA_ARGS__); \ + 0; \ +}) + +/* pr_devel() should produce zero code unless DEBUG is defined */ +#ifdef DEBUG +#define pr_devel(fmt, ...) printk +#else +#define pr_devel(fmt, ...) no_printk +#endif + +#define pr_debug pr_devel + +#endif /* _TOOLS_LINUX_KERNEL_PRINTK_H_ */ -- 2.25.4 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 01/17] tools: Add some generic functions and headers @ 2021-01-20 17:37 ` Julien Thierry 0 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: mark.rutland, linux-efi, michal.lkml, keescook, peterz, catalin.marinas, masahiroy, broonie, linux-hardening, jpoimboe, will, ardb, Julien Thierry These will be needed to be able to use arm64 instruction decoder in userland tools. Signed-off-by: Julien Thierry <jthierry@redhat.com> --- tools/include/asm-generic/bitops/__ffs.h | 11 +++++++ tools/include/linux/kernel.h | 21 +++++++++++++ tools/include/linux/printk.h | 40 ++++++++++++++++++++++++ 3 files changed, 72 insertions(+) create mode 100644 tools/include/linux/printk.h diff --git a/tools/include/asm-generic/bitops/__ffs.h b/tools/include/asm-generic/bitops/__ffs.h index 9d1310519497..963f8a22212f 100644 --- a/tools/include/asm-generic/bitops/__ffs.h +++ b/tools/include/asm-generic/bitops/__ffs.h @@ -42,4 +42,15 @@ static __always_inline unsigned long __ffs(unsigned long word) return num; } +static inline unsigned long __ffs64(u64 word) +{ +#if BITS_PER_LONG == 32 + if (((u32)word) == 0UL) + return __ffs((u32)(word >> 32)) + 32; +#elif BITS_PER_LONG != 64 +#error BITS_PER_LONG not 32 or 64 +#endif + return __ffs((unsigned long)word); +} + #endif /* _TOOLS_LINUX_ASM_GENERIC_BITOPS___FFS_H_ */ diff --git a/tools/include/linux/kernel.h b/tools/include/linux/kernel.h index a7e54a08fb54..e748982ed5c1 100644 --- a/tools/include/linux/kernel.h +++ b/tools/include/linux/kernel.h @@ -114,6 +114,27 @@ int scnprintf_pad(char * buf, size_t size, const char * fmt, ...); #define round_up(x, y) ((((x)-1) | __round_mask(x, y))+1) #define round_down(x, y) ((x) & ~__round_mask(x, y)) +/** + * upper_32_bits - return bits 32-63 of a number + * @n: the number we're accessing + * + * A basic shift-right of a 64- or 32-bit quantity. Use this to suppress + * the "right shift count >= width of type" warning when that quantity is + * 32-bits. + */ +#define upper_32_bits(n) ((u32)(((n) >> 16) >> 16)) + +/** + * lower_32_bits - return bits 0-31 of a number + * @n: the number we're accessing + */ +#define lower_32_bits(n) ((u32)(n)) + +/* Inspired from ALIGN_*_KERNEL */ +#define __ALIGN_MASK(x, mask) (((x) + (mask)) & ~(mask)) +#define __ALIGN(x, a) __ALIGN_MASK(x, (typeof(x))(a) - 1) +#define ALIGN_DOWN(x, a) __ALIGN((x) - ((a) - 1), (a)) + #define current_gfp_context(k) 0 #define synchronize_rcu() diff --git a/tools/include/linux/printk.h b/tools/include/linux/printk.h new file mode 100644 index 000000000000..515ebdc47e6e --- /dev/null +++ b/tools/include/linux/printk.h @@ -0,0 +1,40 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _TOOLS_LINUX_KERNEL_PRINTK_H_ +#define _TOOLS_LINUX_KERNEL_PRINTK_H_ + +#include <stdarg.h> +#include <stdio.h> +#include <stdlib.h> + +#define printk(fmt, ...) fprintf(stdout, fmt, ##__VA_ARGS__) +#define pr_info printk +#define pr_notice printk +#define pr_cont printk + +#define pr_warn(fmt, ...) fprintf(stderr, fmt, ##__VA_ARGS__) +#define pr_err pr_warn +#define pr_alert pr_warn +#define pr_emerg pr_warn +#define pr_crit pr_warn + +/* + * Dummy printk for disabled debugging statements to use whilst maintaining + * gcc's format checking. + */ +#define no_printk(fmt, ...) \ +({ \ + if (0) \ + printk(fmt, ##__VA_ARGS__); \ + 0; \ +}) + +/* pr_devel() should produce zero code unless DEBUG is defined */ +#ifdef DEBUG +#define pr_devel(fmt, ...) printk +#else +#define pr_devel(fmt, ...) no_printk +#endif + +#define pr_debug pr_devel + +#endif /* _TOOLS_LINUX_KERNEL_PRINTK_H_ */ -- 2.25.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 02/17] tools: arm64: Make aarch64 instruction decoder available to tools 2021-01-20 17:37 ` Julien Thierry @ 2021-01-20 17:37 ` Julien Thierry -1 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: catalin.marinas, will, ardb, masahiroy, keescook, michal.lkml, jpoimboe, peterz, mark.rutland, broonie, linux-efi, linux-hardening, Julien Thierry Add aarch64 encoder/decoder implementation under tools/ as well as the necessary arm64 headers. Signed-off-by: Julien Thierry <jthierry@redhat.com> --- tools/arch/arm64/include/asm/aarch64-insn.h | 551 +++++++ tools/arch/arm64/lib/aarch64-insn.c | 1425 +++++++++++++++++++ 2 files changed, 1976 insertions(+) create mode 100644 tools/arch/arm64/include/asm/aarch64-insn.h create mode 100644 tools/arch/arm64/lib/aarch64-insn.c diff --git a/tools/arch/arm64/include/asm/aarch64-insn.h b/tools/arch/arm64/include/asm/aarch64-insn.h new file mode 100644 index 000000000000..b202d6e2e47e --- /dev/null +++ b/tools/arch/arm64/include/asm/aarch64-insn.h @@ -0,0 +1,551 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +#ifndef __ASM_AARCH64_INSN_H +#define __ASM_AARCH64_INSN_H + +#include <linux/build_bug.h> +#include <linux/types.h> + + +/* A64 instructions are always 32 bits. */ +#define AARCH64_INSN_SIZE 4 + +/* + * BRK instruction encoding + * The #imm16 value should be placed at bits[20:5] within BRK ins + */ +#define AARCH64_BREAK_MON 0xd4200000 + +/* + * BRK instruction for provoking a fault on purpose + * Unlike kgdb, #imm16 value with unallocated handler is used for faulting. + */ +#define AARCH64_BREAK_FAULT (AARCH64_BREAK_MON | (FAULT_BRK_IMM << 5)) + +#ifndef __ASSEMBLY__ +/* + * ARM Architecture Reference Manual for ARMv8 Profile-A, Issue A.a + * Section C3.1 "A64 instruction index by encoding": + * AArch64 main encoding table + * Bit position + * 28 27 26 25 Encoding Group + * 0 0 - - Unallocated + * 1 0 0 - Data processing, immediate + * 1 0 1 - Branch, exception generation and system instructions + * - 1 - 0 Loads and stores + * - 1 0 1 Data processing - register + * 0 1 1 1 Data processing - SIMD and floating point + * 1 1 1 1 Data processing - SIMD and floating point + * "-" means "don't care" + */ +enum aarch64_insn_encoding_class { + AARCH64_INSN_CLS_UNKNOWN, /* UNALLOCATED */ + AARCH64_INSN_CLS_SVE, /* SVE instructions */ + AARCH64_INSN_CLS_DP_IMM, /* Data processing - immediate */ + AARCH64_INSN_CLS_DP_REG, /* Data processing - register */ + AARCH64_INSN_CLS_DP_FPSIMD, /* Data processing - SIMD and FP */ + AARCH64_INSN_CLS_LDST, /* Loads and stores */ + AARCH64_INSN_CLS_BR_SYS, /* Branch, exception generation and + * system instructions */ +}; + +enum aarch64_insn_hint_cr_op { + AARCH64_INSN_HINT_NOP = 0x0 << 5, + AARCH64_INSN_HINT_YIELD = 0x1 << 5, + AARCH64_INSN_HINT_WFE = 0x2 << 5, + AARCH64_INSN_HINT_WFI = 0x3 << 5, + AARCH64_INSN_HINT_SEV = 0x4 << 5, + AARCH64_INSN_HINT_SEVL = 0x5 << 5, + + AARCH64_INSN_HINT_XPACLRI = 0x07 << 5, + AARCH64_INSN_HINT_PACIA_1716 = 0x08 << 5, + AARCH64_INSN_HINT_PACIB_1716 = 0x0A << 5, + AARCH64_INSN_HINT_AUTIA_1716 = 0x0C << 5, + AARCH64_INSN_HINT_AUTIB_1716 = 0x0E << 5, + AARCH64_INSN_HINT_PACIAZ = 0x18 << 5, + AARCH64_INSN_HINT_PACIASP = 0x19 << 5, + AARCH64_INSN_HINT_PACIBZ = 0x1A << 5, + AARCH64_INSN_HINT_PACIBSP = 0x1B << 5, + AARCH64_INSN_HINT_AUTIAZ = 0x1C << 5, + AARCH64_INSN_HINT_AUTIASP = 0x1D << 5, + AARCH64_INSN_HINT_AUTIBZ = 0x1E << 5, + AARCH64_INSN_HINT_AUTIBSP = 0x1F << 5, + + AARCH64_INSN_HINT_ESB = 0x10 << 5, + AARCH64_INSN_HINT_PSB = 0x11 << 5, + AARCH64_INSN_HINT_TSB = 0x12 << 5, + AARCH64_INSN_HINT_CSDB = 0x14 << 5, + + AARCH64_INSN_HINT_BTI = 0x20 << 5, + AARCH64_INSN_HINT_BTIC = 0x22 << 5, + AARCH64_INSN_HINT_BTIJ = 0x24 << 5, + AARCH64_INSN_HINT_BTIJC = 0x26 << 5, +}; + +enum aarch64_insn_imm_type { + AARCH64_INSN_IMM_ADR, + AARCH64_INSN_IMM_26, + AARCH64_INSN_IMM_19, + AARCH64_INSN_IMM_16, + AARCH64_INSN_IMM_14, + AARCH64_INSN_IMM_12, + AARCH64_INSN_IMM_9, + AARCH64_INSN_IMM_7, + AARCH64_INSN_IMM_6, + AARCH64_INSN_IMM_S, + AARCH64_INSN_IMM_R, + AARCH64_INSN_IMM_N, + AARCH64_INSN_IMM_MAX +}; + +enum aarch64_insn_register_type { + AARCH64_INSN_REGTYPE_RT, + AARCH64_INSN_REGTYPE_RN, + AARCH64_INSN_REGTYPE_RT2, + AARCH64_INSN_REGTYPE_RM, + AARCH64_INSN_REGTYPE_RD, + AARCH64_INSN_REGTYPE_RA, + AARCH64_INSN_REGTYPE_RS, +}; + +enum aarch64_insn_register { + AARCH64_INSN_REG_0 = 0, + AARCH64_INSN_REG_1 = 1, + AARCH64_INSN_REG_2 = 2, + AARCH64_INSN_REG_3 = 3, + AARCH64_INSN_REG_4 = 4, + AARCH64_INSN_REG_5 = 5, + AARCH64_INSN_REG_6 = 6, + AARCH64_INSN_REG_7 = 7, + AARCH64_INSN_REG_8 = 8, + AARCH64_INSN_REG_9 = 9, + AARCH64_INSN_REG_10 = 10, + AARCH64_INSN_REG_11 = 11, + AARCH64_INSN_REG_12 = 12, + AARCH64_INSN_REG_13 = 13, + AARCH64_INSN_REG_14 = 14, + AARCH64_INSN_REG_15 = 15, + AARCH64_INSN_REG_16 = 16, + AARCH64_INSN_REG_17 = 17, + AARCH64_INSN_REG_18 = 18, + AARCH64_INSN_REG_19 = 19, + AARCH64_INSN_REG_20 = 20, + AARCH64_INSN_REG_21 = 21, + AARCH64_INSN_REG_22 = 22, + AARCH64_INSN_REG_23 = 23, + AARCH64_INSN_REG_24 = 24, + AARCH64_INSN_REG_25 = 25, + AARCH64_INSN_REG_26 = 26, + AARCH64_INSN_REG_27 = 27, + AARCH64_INSN_REG_28 = 28, + AARCH64_INSN_REG_29 = 29, + AARCH64_INSN_REG_FP = 29, /* Frame pointer */ + AARCH64_INSN_REG_30 = 30, + AARCH64_INSN_REG_LR = 30, /* Link register */ + AARCH64_INSN_REG_ZR = 31, /* Zero: as source register */ + AARCH64_INSN_REG_SP = 31 /* Stack pointer: as load/store base reg */ +}; + +enum aarch64_insn_special_register { + AARCH64_INSN_SPCLREG_SPSR_EL1 = 0xC200, + AARCH64_INSN_SPCLREG_ELR_EL1 = 0xC201, + AARCH64_INSN_SPCLREG_SP_EL0 = 0xC208, + AARCH64_INSN_SPCLREG_SPSEL = 0xC210, + AARCH64_INSN_SPCLREG_CURRENTEL = 0xC212, + AARCH64_INSN_SPCLREG_DAIF = 0xDA11, + AARCH64_INSN_SPCLREG_NZCV = 0xDA10, + AARCH64_INSN_SPCLREG_FPCR = 0xDA20, + AARCH64_INSN_SPCLREG_DSPSR_EL0 = 0xDA28, + AARCH64_INSN_SPCLREG_DLR_EL0 = 0xDA29, + AARCH64_INSN_SPCLREG_SPSR_EL2 = 0xE200, + AARCH64_INSN_SPCLREG_ELR_EL2 = 0xE201, + AARCH64_INSN_SPCLREG_SP_EL1 = 0xE208, + AARCH64_INSN_SPCLREG_SPSR_INQ = 0xE218, + AARCH64_INSN_SPCLREG_SPSR_ABT = 0xE219, + AARCH64_INSN_SPCLREG_SPSR_UND = 0xE21A, + AARCH64_INSN_SPCLREG_SPSR_FIQ = 0xE21B, + AARCH64_INSN_SPCLREG_SPSR_EL3 = 0xF200, + AARCH64_INSN_SPCLREG_ELR_EL3 = 0xF201, + AARCH64_INSN_SPCLREG_SP_EL2 = 0xF210 +}; + +enum aarch64_insn_variant { + AARCH64_INSN_VARIANT_32BIT, + AARCH64_INSN_VARIANT_64BIT +}; + +enum aarch64_insn_condition { + AARCH64_INSN_COND_EQ = 0x0, /* == */ + AARCH64_INSN_COND_NE = 0x1, /* != */ + AARCH64_INSN_COND_CS = 0x2, /* unsigned >= */ + AARCH64_INSN_COND_CC = 0x3, /* unsigned < */ + AARCH64_INSN_COND_MI = 0x4, /* < 0 */ + AARCH64_INSN_COND_PL = 0x5, /* >= 0 */ + AARCH64_INSN_COND_VS = 0x6, /* overflow */ + AARCH64_INSN_COND_VC = 0x7, /* no overflow */ + AARCH64_INSN_COND_HI = 0x8, /* unsigned > */ + AARCH64_INSN_COND_LS = 0x9, /* unsigned <= */ + AARCH64_INSN_COND_GE = 0xa, /* signed >= */ + AARCH64_INSN_COND_LT = 0xb, /* signed < */ + AARCH64_INSN_COND_GT = 0xc, /* signed > */ + AARCH64_INSN_COND_LE = 0xd, /* signed <= */ + AARCH64_INSN_COND_AL = 0xe, /* always */ +}; + +enum aarch64_insn_branch_type { + AARCH64_INSN_BRANCH_NOLINK, + AARCH64_INSN_BRANCH_LINK, + AARCH64_INSN_BRANCH_RETURN, + AARCH64_INSN_BRANCH_COMP_ZERO, + AARCH64_INSN_BRANCH_COMP_NONZERO, +}; + +enum aarch64_insn_size_type { + AARCH64_INSN_SIZE_8, + AARCH64_INSN_SIZE_16, + AARCH64_INSN_SIZE_32, + AARCH64_INSN_SIZE_64, +}; + +enum aarch64_insn_ldst_type { + AARCH64_INSN_LDST_LOAD_REG_OFFSET, + AARCH64_INSN_LDST_STORE_REG_OFFSET, + AARCH64_INSN_LDST_LOAD_PAIR_PRE_INDEX, + AARCH64_INSN_LDST_STORE_PAIR_PRE_INDEX, + AARCH64_INSN_LDST_LOAD_PAIR_POST_INDEX, + AARCH64_INSN_LDST_STORE_PAIR_POST_INDEX, + AARCH64_INSN_LDST_LOAD_EX, + AARCH64_INSN_LDST_STORE_EX, +}; + +enum aarch64_insn_adsb_type { + AARCH64_INSN_ADSB_ADD, + AARCH64_INSN_ADSB_SUB, + AARCH64_INSN_ADSB_ADD_SETFLAGS, + AARCH64_INSN_ADSB_SUB_SETFLAGS +}; + +enum aarch64_insn_movewide_type { + AARCH64_INSN_MOVEWIDE_ZERO, + AARCH64_INSN_MOVEWIDE_KEEP, + AARCH64_INSN_MOVEWIDE_INVERSE +}; + +enum aarch64_insn_bitfield_type { + AARCH64_INSN_BITFIELD_MOVE, + AARCH64_INSN_BITFIELD_MOVE_UNSIGNED, + AARCH64_INSN_BITFIELD_MOVE_SIGNED +}; + +enum aarch64_insn_data1_type { + AARCH64_INSN_DATA1_REVERSE_16, + AARCH64_INSN_DATA1_REVERSE_32, + AARCH64_INSN_DATA1_REVERSE_64, +}; + +enum aarch64_insn_data2_type { + AARCH64_INSN_DATA2_UDIV, + AARCH64_INSN_DATA2_SDIV, + AARCH64_INSN_DATA2_LSLV, + AARCH64_INSN_DATA2_LSRV, + AARCH64_INSN_DATA2_ASRV, + AARCH64_INSN_DATA2_RORV, +}; + +enum aarch64_insn_data3_type { + AARCH64_INSN_DATA3_MADD, + AARCH64_INSN_DATA3_MSUB, +}; + +enum aarch64_insn_logic_type { + AARCH64_INSN_LOGIC_AND, + AARCH64_INSN_LOGIC_BIC, + AARCH64_INSN_LOGIC_ORR, + AARCH64_INSN_LOGIC_ORN, + AARCH64_INSN_LOGIC_EOR, + AARCH64_INSN_LOGIC_EON, + AARCH64_INSN_LOGIC_AND_SETFLAGS, + AARCH64_INSN_LOGIC_BIC_SETFLAGS +}; + +enum aarch64_insn_prfm_type { + AARCH64_INSN_PRFM_TYPE_PLD, + AARCH64_INSN_PRFM_TYPE_PLI, + AARCH64_INSN_PRFM_TYPE_PST, +}; + +enum aarch64_insn_prfm_target { + AARCH64_INSN_PRFM_TARGET_L1, + AARCH64_INSN_PRFM_TARGET_L2, + AARCH64_INSN_PRFM_TARGET_L3, +}; + +enum aarch64_insn_prfm_policy { + AARCH64_INSN_PRFM_POLICY_KEEP, + AARCH64_INSN_PRFM_POLICY_STRM, +}; + +enum aarch64_insn_adr_type { + AARCH64_INSN_ADR_TYPE_ADRP, + AARCH64_INSN_ADR_TYPE_ADR, +}; + +#define __AARCH64_INSN_FUNCS(abbr, mask, val) \ +static __always_inline bool aarch64_insn_is_##abbr(u32 code) \ +{ \ + BUILD_BUG_ON(~(mask) & (val)); \ + return (code & (mask)) == (val); \ +} \ +static __always_inline u32 aarch64_insn_get_##abbr##_value(void) \ +{ \ + return (val); \ +} + +__AARCH64_INSN_FUNCS(adr, 0x9F000000, 0x10000000) +__AARCH64_INSN_FUNCS(adrp, 0x9F000000, 0x90000000) +__AARCH64_INSN_FUNCS(prfm, 0x3FC00000, 0x39800000) +__AARCH64_INSN_FUNCS(prfm_lit, 0xFF000000, 0xD8000000) +__AARCH64_INSN_FUNCS(store_imm, 0x3FC00000, 0x39000000) +__AARCH64_INSN_FUNCS(load_imm, 0x3FC00000, 0x39400000) +__AARCH64_INSN_FUNCS(store_pre, 0x3FE00C00, 0x38000C00) +__AARCH64_INSN_FUNCS(load_pre, 0x3FE00C00, 0x38400C00) +__AARCH64_INSN_FUNCS(store_post, 0x3FE00C00, 0x38000400) +__AARCH64_INSN_FUNCS(load_post, 0x3FE00C00, 0x38400400) +__AARCH64_INSN_FUNCS(str_reg, 0x3FE0EC00, 0x38206800) +__AARCH64_INSN_FUNCS(ldadd, 0x3F20FC00, 0x38200000) +__AARCH64_INSN_FUNCS(ldr_reg, 0x3FE0EC00, 0x38606800) +__AARCH64_INSN_FUNCS(ldr_lit, 0xBF000000, 0x18000000) +__AARCH64_INSN_FUNCS(ldrsw_lit, 0xFF000000, 0x98000000) +__AARCH64_INSN_FUNCS(exclusive, 0x3F800000, 0x08000000) +__AARCH64_INSN_FUNCS(load_ex, 0x3F400000, 0x08400000) +__AARCH64_INSN_FUNCS(store_ex, 0x3F400000, 0x08000000) +__AARCH64_INSN_FUNCS(stp, 0x7FC00000, 0x29000000) +__AARCH64_INSN_FUNCS(ldp, 0x7FC00000, 0x29400000) +__AARCH64_INSN_FUNCS(stp_post, 0x7FC00000, 0x28800000) +__AARCH64_INSN_FUNCS(ldp_post, 0x7FC00000, 0x28C00000) +__AARCH64_INSN_FUNCS(stp_pre, 0x7FC00000, 0x29800000) +__AARCH64_INSN_FUNCS(ldp_pre, 0x7FC00000, 0x29C00000) +__AARCH64_INSN_FUNCS(add_imm, 0x7F000000, 0x11000000) +__AARCH64_INSN_FUNCS(adds_imm, 0x7F000000, 0x31000000) +__AARCH64_INSN_FUNCS(sub_imm, 0x7F000000, 0x51000000) +__AARCH64_INSN_FUNCS(subs_imm, 0x7F000000, 0x71000000) +__AARCH64_INSN_FUNCS(movn, 0x7F800000, 0x12800000) +__AARCH64_INSN_FUNCS(sbfm, 0x7F800000, 0x13000000) +__AARCH64_INSN_FUNCS(bfm, 0x7F800000, 0x33000000) +__AARCH64_INSN_FUNCS(movz, 0x7F800000, 0x52800000) +__AARCH64_INSN_FUNCS(ubfm, 0x7F800000, 0x53000000) +__AARCH64_INSN_FUNCS(movk, 0x7F800000, 0x72800000) +__AARCH64_INSN_FUNCS(add, 0x7F200000, 0x0B000000) +__AARCH64_INSN_FUNCS(adds, 0x7F200000, 0x2B000000) +__AARCH64_INSN_FUNCS(sub, 0x7F200000, 0x4B000000) +__AARCH64_INSN_FUNCS(subs, 0x7F200000, 0x6B000000) +__AARCH64_INSN_FUNCS(madd, 0x7FE08000, 0x1B000000) +__AARCH64_INSN_FUNCS(msub, 0x7FE08000, 0x1B008000) +__AARCH64_INSN_FUNCS(udiv, 0x7FE0FC00, 0x1AC00800) +__AARCH64_INSN_FUNCS(sdiv, 0x7FE0FC00, 0x1AC00C00) +__AARCH64_INSN_FUNCS(lslv, 0x7FE0FC00, 0x1AC02000) +__AARCH64_INSN_FUNCS(lsrv, 0x7FE0FC00, 0x1AC02400) +__AARCH64_INSN_FUNCS(asrv, 0x7FE0FC00, 0x1AC02800) +__AARCH64_INSN_FUNCS(rorv, 0x7FE0FC00, 0x1AC02C00) +__AARCH64_INSN_FUNCS(rev16, 0x7FFFFC00, 0x5AC00400) +__AARCH64_INSN_FUNCS(rev32, 0x7FFFFC00, 0x5AC00800) +__AARCH64_INSN_FUNCS(rev64, 0x7FFFFC00, 0x5AC00C00) +__AARCH64_INSN_FUNCS(and, 0x7F200000, 0x0A000000) +__AARCH64_INSN_FUNCS(bic, 0x7F200000, 0x0A200000) +__AARCH64_INSN_FUNCS(orr, 0x7F200000, 0x2A000000) +__AARCH64_INSN_FUNCS(mov_reg, 0x7FE0FFE0, 0x2A0003E0) +__AARCH64_INSN_FUNCS(orn, 0x7F200000, 0x2A200000) +__AARCH64_INSN_FUNCS(eor, 0x7F200000, 0x4A000000) +__AARCH64_INSN_FUNCS(eon, 0x7F200000, 0x4A200000) +__AARCH64_INSN_FUNCS(ands, 0x7F200000, 0x6A000000) +__AARCH64_INSN_FUNCS(bics, 0x7F200000, 0x6A200000) +__AARCH64_INSN_FUNCS(and_imm, 0x7F800000, 0x12000000) +__AARCH64_INSN_FUNCS(orr_imm, 0x7F800000, 0x32000000) +__AARCH64_INSN_FUNCS(eor_imm, 0x7F800000, 0x52000000) +__AARCH64_INSN_FUNCS(ands_imm, 0x7F800000, 0x72000000) +__AARCH64_INSN_FUNCS(extr, 0x7FA00000, 0x13800000) +__AARCH64_INSN_FUNCS(b, 0xFC000000, 0x14000000) +__AARCH64_INSN_FUNCS(bl, 0xFC000000, 0x94000000) +__AARCH64_INSN_FUNCS(cbz, 0x7F000000, 0x34000000) +__AARCH64_INSN_FUNCS(cbnz, 0x7F000000, 0x35000000) +__AARCH64_INSN_FUNCS(tbz, 0x7F000000, 0x36000000) +__AARCH64_INSN_FUNCS(tbnz, 0x7F000000, 0x37000000) +__AARCH64_INSN_FUNCS(bcond, 0xFF000010, 0x54000000) +__AARCH64_INSN_FUNCS(svc, 0xFFE0001F, 0xD4000001) +__AARCH64_INSN_FUNCS(hvc, 0xFFE0001F, 0xD4000002) +__AARCH64_INSN_FUNCS(smc, 0xFFE0001F, 0xD4000003) +__AARCH64_INSN_FUNCS(brk, 0xFFE0001F, 0xD4200000) +__AARCH64_INSN_FUNCS(exception, 0xFF000000, 0xD4000000) +__AARCH64_INSN_FUNCS(hint, 0xFFFFF01F, 0xD503201F) +__AARCH64_INSN_FUNCS(br, 0xFFFFFC1F, 0xD61F0000) +__AARCH64_INSN_FUNCS(br_auth, 0xFEFFF800, 0xD61F0800) +__AARCH64_INSN_FUNCS(blr, 0xFFFFFC1F, 0xD63F0000) +__AARCH64_INSN_FUNCS(blr_auth, 0xFEFFF800, 0xD63F0800) +__AARCH64_INSN_FUNCS(ret, 0xFFFFFC1F, 0xD65F0000) +__AARCH64_INSN_FUNCS(ret_auth, 0xFFFFFBFF, 0xD65F0BFF) +__AARCH64_INSN_FUNCS(eret, 0xFFFFFFFF, 0xD69F03E0) +__AARCH64_INSN_FUNCS(eret_auth, 0xFFFFFBFF, 0xD69F0BFF) +__AARCH64_INSN_FUNCS(mrs, 0xFFF00000, 0xD5300000) +__AARCH64_INSN_FUNCS(msr_imm, 0xFFF8F01F, 0xD500401F) +__AARCH64_INSN_FUNCS(msr_reg, 0xFFF00000, 0xD5100000) +__AARCH64_INSN_FUNCS(dmb, 0xFFFFF0FF, 0xD50330BF) +__AARCH64_INSN_FUNCS(dsb, 0xFFFFF0FF, 0xD503309F) +__AARCH64_INSN_FUNCS(isb, 0xFFFFF0FF, 0xD50330DF) + +#undef __AARCH64_INSN_FUNCS + +bool aarch64_insn_is_steppable_hint(u32 insn); +bool aarch64_insn_is_branch_imm(u32 insn); + +static inline bool aarch64_insn_is_adr_adrp(u32 insn) +{ + return aarch64_insn_is_adr(insn) || aarch64_insn_is_adrp(insn); +} + +static inline bool aarch64_insn_is_barrier(u32 insn) +{ + return aarch64_insn_is_dmb(insn) || aarch64_insn_is_dsb(insn) || + aarch64_insn_is_isb(insn); +} + +static inline bool aarch64_insn_is_store_single(u32 insn) +{ + return aarch64_insn_is_store_imm(insn) || + aarch64_insn_is_store_pre(insn) || + aarch64_insn_is_store_post(insn); +} + +static inline bool aarch64_insn_is_store_pair(u32 insn) +{ + return aarch64_insn_is_stp(insn) || + aarch64_insn_is_stp_pre(insn) || + aarch64_insn_is_stp_post(insn); +} + +static inline bool aarch64_insn_is_load_single(u32 insn) +{ + return aarch64_insn_is_load_imm(insn) || + aarch64_insn_is_load_pre(insn) || + aarch64_insn_is_load_post(insn); +} + +static inline bool aarch64_insn_is_load_pair(u32 insn) +{ + return aarch64_insn_is_ldp(insn) || + aarch64_insn_is_ldp_pre(insn) || + aarch64_insn_is_ldp_post(insn); +} + +enum aarch64_insn_encoding_class aarch64_get_insn_class(u32 insn); +bool aarch64_insn_uses_literal(u32 insn); +bool aarch64_insn_is_branch(u32 insn); +u64 aarch64_insn_decode_immediate(enum aarch64_insn_imm_type type, u32 insn); +u32 aarch64_insn_encode_immediate(enum aarch64_insn_imm_type type, + u32 insn, u64 imm); +u32 aarch64_insn_decode_register(enum aarch64_insn_register_type type, + u32 insn); +u32 aarch64_insn_gen_branch_imm(unsigned long pc, unsigned long addr, + enum aarch64_insn_branch_type type); +u32 aarch64_insn_gen_comp_branch_imm(unsigned long pc, unsigned long addr, + enum aarch64_insn_register reg, + enum aarch64_insn_variant variant, + enum aarch64_insn_branch_type type); +u32 aarch64_insn_gen_cond_branch_imm(unsigned long pc, unsigned long addr, + enum aarch64_insn_condition cond); +u32 aarch64_insn_gen_hint(enum aarch64_insn_hint_cr_op op); +u32 aarch64_insn_gen_nop(void); +u32 aarch64_insn_gen_branch_reg(enum aarch64_insn_register reg, + enum aarch64_insn_branch_type type); +u32 aarch64_insn_gen_load_store_reg(enum aarch64_insn_register reg, + enum aarch64_insn_register base, + enum aarch64_insn_register offset, + enum aarch64_insn_size_type size, + enum aarch64_insn_ldst_type type); +u32 aarch64_insn_gen_load_store_pair(enum aarch64_insn_register reg1, + enum aarch64_insn_register reg2, + enum aarch64_insn_register base, + int offset, + enum aarch64_insn_variant variant, + enum aarch64_insn_ldst_type type); +u32 aarch64_insn_gen_load_store_ex(enum aarch64_insn_register reg, + enum aarch64_insn_register base, + enum aarch64_insn_register state, + enum aarch64_insn_size_type size, + enum aarch64_insn_ldst_type type); +u32 aarch64_insn_gen_ldadd(enum aarch64_insn_register result, + enum aarch64_insn_register address, + enum aarch64_insn_register value, + enum aarch64_insn_size_type size); +u32 aarch64_insn_gen_stadd(enum aarch64_insn_register address, + enum aarch64_insn_register value, + enum aarch64_insn_size_type size); +u32 aarch64_insn_gen_add_sub_imm(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + int imm, enum aarch64_insn_variant variant, + enum aarch64_insn_adsb_type type); +u32 aarch64_insn_gen_adr(unsigned long pc, unsigned long addr, + enum aarch64_insn_register reg, + enum aarch64_insn_adr_type type); +u32 aarch64_insn_gen_bitfield(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + int immr, int imms, + enum aarch64_insn_variant variant, + enum aarch64_insn_bitfield_type type); +u32 aarch64_insn_gen_movewide(enum aarch64_insn_register dst, + int imm, int shift, + enum aarch64_insn_variant variant, + enum aarch64_insn_movewide_type type); +u32 aarch64_insn_gen_add_sub_shifted_reg(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + enum aarch64_insn_register reg, + int shift, + enum aarch64_insn_variant variant, + enum aarch64_insn_adsb_type type); +u32 aarch64_insn_gen_data1(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + enum aarch64_insn_variant variant, + enum aarch64_insn_data1_type type); +u32 aarch64_insn_gen_data2(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + enum aarch64_insn_register reg, + enum aarch64_insn_variant variant, + enum aarch64_insn_data2_type type); +u32 aarch64_insn_gen_data3(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + enum aarch64_insn_register reg1, + enum aarch64_insn_register reg2, + enum aarch64_insn_variant variant, + enum aarch64_insn_data3_type type); +u32 aarch64_insn_gen_logical_shifted_reg(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + enum aarch64_insn_register reg, + int shift, + enum aarch64_insn_variant variant, + enum aarch64_insn_logic_type type); +u32 aarch64_insn_gen_move_reg(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + enum aarch64_insn_variant variant); +u32 aarch64_insn_gen_logical_immediate(enum aarch64_insn_logic_type type, + enum aarch64_insn_variant variant, + enum aarch64_insn_register Rn, + enum aarch64_insn_register Rd, + u64 imm); +u32 aarch64_insn_gen_extr(enum aarch64_insn_variant variant, + enum aarch64_insn_register Rm, + enum aarch64_insn_register Rn, + enum aarch64_insn_register Rd, + u8 lsb); +u32 aarch64_insn_gen_prefetch(enum aarch64_insn_register base, + enum aarch64_insn_prfm_type type, + enum aarch64_insn_prfm_target target, + enum aarch64_insn_prfm_policy policy); +s32 aarch64_get_branch_offset(u32 insn); +u32 aarch64_set_branch_offset(u32 insn, s32 offset); + +s32 aarch64_insn_adrp_get_offset(u32 insn); +u32 aarch64_insn_adrp_set_offset(u32 insn, s32 offset); + +u32 aarch64_insn_extract_system_reg(u32 insn); + + +#endif /* !__ASSEMBLY__ */ +#endif /* __ASM_AARCH64_INSN_H */ diff --git a/tools/arch/arm64/lib/aarch64-insn.c b/tools/arch/arm64/lib/aarch64-insn.c new file mode 100644 index 000000000000..18e0b66a8284 --- /dev/null +++ b/tools/arch/arm64/lib/aarch64-insn.c @@ -0,0 +1,1425 @@ +// SPDX-License-Identifier: GPL-2.0-only + +#include <linux/bitops.h> +#include <linux/bug.h> +#include <linux/printk.h> +#include <linux/sizes.h> +#include <linux/types.h> + +#include <asm/aarch64-insn.h> +#include <asm/errno.h> + +#define AARCH64_INSN_SF_BIT BIT(31) +#define AARCH64_INSN_N_BIT BIT(22) +#define AARCH64_INSN_LSL_12 BIT(22) + +static const int aarch64_insn_encoding_class[] = { + AARCH64_INSN_CLS_UNKNOWN, + AARCH64_INSN_CLS_UNKNOWN, + AARCH64_INSN_CLS_SVE, + AARCH64_INSN_CLS_UNKNOWN, + AARCH64_INSN_CLS_LDST, + AARCH64_INSN_CLS_DP_REG, + AARCH64_INSN_CLS_LDST, + AARCH64_INSN_CLS_DP_FPSIMD, + AARCH64_INSN_CLS_DP_IMM, + AARCH64_INSN_CLS_DP_IMM, + AARCH64_INSN_CLS_BR_SYS, + AARCH64_INSN_CLS_BR_SYS, + AARCH64_INSN_CLS_LDST, + AARCH64_INSN_CLS_DP_REG, + AARCH64_INSN_CLS_LDST, + AARCH64_INSN_CLS_DP_FPSIMD, +}; + +enum aarch64_insn_encoding_class __kprobes aarch64_get_insn_class(u32 insn) +{ + return aarch64_insn_encoding_class[(insn >> 25) & 0xf]; +} + +bool __kprobes aarch64_insn_is_steppable_hint(u32 insn) +{ + if (!aarch64_insn_is_hint(insn)) + return false; + + switch (insn & 0xFE0) { + case AARCH64_INSN_HINT_XPACLRI: + case AARCH64_INSN_HINT_PACIA_1716: + case AARCH64_INSN_HINT_PACIB_1716: + case AARCH64_INSN_HINT_PACIAZ: + case AARCH64_INSN_HINT_PACIASP: + case AARCH64_INSN_HINT_PACIBZ: + case AARCH64_INSN_HINT_PACIBSP: + case AARCH64_INSN_HINT_BTI: + case AARCH64_INSN_HINT_BTIC: + case AARCH64_INSN_HINT_BTIJ: + case AARCH64_INSN_HINT_BTIJC: + case AARCH64_INSN_HINT_NOP: + return true; + default: + return false; + } +} + +bool aarch64_insn_is_branch_imm(u32 insn) +{ + return (aarch64_insn_is_b(insn) || aarch64_insn_is_bl(insn) || + aarch64_insn_is_tbz(insn) || aarch64_insn_is_tbnz(insn) || + aarch64_insn_is_cbz(insn) || aarch64_insn_is_cbnz(insn) || + aarch64_insn_is_bcond(insn)); +} + +bool __kprobes aarch64_insn_uses_literal(u32 insn) +{ + /* ldr/ldrsw (literal), prfm */ + + return aarch64_insn_is_ldr_lit(insn) || + aarch64_insn_is_ldrsw_lit(insn) || + aarch64_insn_is_adr_adrp(insn) || + aarch64_insn_is_prfm_lit(insn); +} + +bool __kprobes aarch64_insn_is_branch(u32 insn) +{ + /* b, bl, cb*, tb*, ret*, b.cond, br*, blr* */ + + return aarch64_insn_is_b(insn) || + aarch64_insn_is_bl(insn) || + aarch64_insn_is_cbz(insn) || + aarch64_insn_is_cbnz(insn) || + aarch64_insn_is_tbz(insn) || + aarch64_insn_is_tbnz(insn) || + aarch64_insn_is_ret(insn) || + aarch64_insn_is_ret_auth(insn) || + aarch64_insn_is_br(insn) || + aarch64_insn_is_br_auth(insn) || + aarch64_insn_is_blr(insn) || + aarch64_insn_is_blr_auth(insn) || + aarch64_insn_is_bcond(insn); +} + +static int __kprobes aarch64_get_imm_shift_mask(enum aarch64_insn_imm_type type, + u32 *maskp, int *shiftp) +{ + u32 mask; + int shift; + + switch (type) { + case AARCH64_INSN_IMM_26: + mask = BIT(26) - 1; + shift = 0; + break; + case AARCH64_INSN_IMM_19: + mask = BIT(19) - 1; + shift = 5; + break; + case AARCH64_INSN_IMM_16: + mask = BIT(16) - 1; + shift = 5; + break; + case AARCH64_INSN_IMM_14: + mask = BIT(14) - 1; + shift = 5; + break; + case AARCH64_INSN_IMM_12: + mask = BIT(12) - 1; + shift = 10; + break; + case AARCH64_INSN_IMM_9: + mask = BIT(9) - 1; + shift = 12; + break; + case AARCH64_INSN_IMM_7: + mask = BIT(7) - 1; + shift = 15; + break; + case AARCH64_INSN_IMM_6: + case AARCH64_INSN_IMM_S: + mask = BIT(6) - 1; + shift = 10; + break; + case AARCH64_INSN_IMM_R: + mask = BIT(6) - 1; + shift = 16; + break; + case AARCH64_INSN_IMM_N: + mask = 1; + shift = 22; + break; + default: + return -EINVAL; + } + + *maskp = mask; + *shiftp = shift; + + return 0; +} + +#define ADR_IMM_HILOSPLIT 2 +#define ADR_IMM_SIZE SZ_2M +#define ADR_IMM_LOMASK ((1 << ADR_IMM_HILOSPLIT) - 1) +#define ADR_IMM_HIMASK ((ADR_IMM_SIZE >> ADR_IMM_HILOSPLIT) - 1) +#define ADR_IMM_LOSHIFT 29 +#define ADR_IMM_HISHIFT 5 + +u64 aarch64_insn_decode_immediate(enum aarch64_insn_imm_type type, u32 insn) +{ + u32 immlo, immhi, mask; + int shift; + + switch (type) { + case AARCH64_INSN_IMM_ADR: + shift = 0; + immlo = (insn >> ADR_IMM_LOSHIFT) & ADR_IMM_LOMASK; + immhi = (insn >> ADR_IMM_HISHIFT) & ADR_IMM_HIMASK; + insn = (immhi << ADR_IMM_HILOSPLIT) | immlo; + mask = ADR_IMM_SIZE - 1; + break; + default: + if (aarch64_get_imm_shift_mask(type, &mask, &shift) < 0) { + pr_err("aarch64_insn_decode_immediate: unknown immediate encoding %d\n", + type); + return 0; + } + } + + return (insn >> shift) & mask; +} + +u32 __kprobes aarch64_insn_encode_immediate(enum aarch64_insn_imm_type type, + u32 insn, u64 imm) +{ + u32 immlo, immhi, mask; + int shift; + + if (insn == AARCH64_BREAK_FAULT) + return AARCH64_BREAK_FAULT; + + switch (type) { + case AARCH64_INSN_IMM_ADR: + shift = 0; + immlo = (imm & ADR_IMM_LOMASK) << ADR_IMM_LOSHIFT; + imm >>= ADR_IMM_HILOSPLIT; + immhi = (imm & ADR_IMM_HIMASK) << ADR_IMM_HISHIFT; + imm = immlo | immhi; + mask = ((ADR_IMM_LOMASK << ADR_IMM_LOSHIFT) | + (ADR_IMM_HIMASK << ADR_IMM_HISHIFT)); + break; + default: + if (aarch64_get_imm_shift_mask(type, &mask, &shift) < 0) { + pr_err("aarch64_insn_encode_immediate: unknown immediate encoding %d\n", + type); + return AARCH64_BREAK_FAULT; + } + } + + /* Update the immediate field. */ + insn &= ~(mask << shift); + insn |= (imm & mask) << shift; + + return insn; +} + +u32 aarch64_insn_decode_register(enum aarch64_insn_register_type type, + u32 insn) +{ + int shift; + + switch (type) { + case AARCH64_INSN_REGTYPE_RT: + case AARCH64_INSN_REGTYPE_RD: + shift = 0; + break; + case AARCH64_INSN_REGTYPE_RN: + shift = 5; + break; + case AARCH64_INSN_REGTYPE_RT2: + case AARCH64_INSN_REGTYPE_RA: + shift = 10; + break; + case AARCH64_INSN_REGTYPE_RM: + shift = 16; + break; + default: + pr_err("%s: unknown register type encoding %d\n", __func__, + type); + return 0; + } + + return (insn >> shift) & GENMASK(4, 0); +} + +static u32 aarch64_insn_encode_register(enum aarch64_insn_register_type type, + u32 insn, + enum aarch64_insn_register reg) +{ + int shift; + + if (insn == AARCH64_BREAK_FAULT) + return AARCH64_BREAK_FAULT; + + if (reg < AARCH64_INSN_REG_0 || reg > AARCH64_INSN_REG_SP) { + pr_err("%s: unknown register encoding %d\n", __func__, reg); + return AARCH64_BREAK_FAULT; + } + + switch (type) { + case AARCH64_INSN_REGTYPE_RT: + case AARCH64_INSN_REGTYPE_RD: + shift = 0; + break; + case AARCH64_INSN_REGTYPE_RN: + shift = 5; + break; + case AARCH64_INSN_REGTYPE_RT2: + case AARCH64_INSN_REGTYPE_RA: + shift = 10; + break; + case AARCH64_INSN_REGTYPE_RM: + case AARCH64_INSN_REGTYPE_RS: + shift = 16; + break; + default: + pr_err("%s: unknown register type encoding %d\n", __func__, + type); + return AARCH64_BREAK_FAULT; + } + + insn &= ~(GENMASK(4, 0) << shift); + insn |= reg << shift; + + return insn; +} + +static u32 aarch64_insn_encode_ldst_size(enum aarch64_insn_size_type type, + u32 insn) +{ + u32 size; + + switch (type) { + case AARCH64_INSN_SIZE_8: + size = 0; + break; + case AARCH64_INSN_SIZE_16: + size = 1; + break; + case AARCH64_INSN_SIZE_32: + size = 2; + break; + case AARCH64_INSN_SIZE_64: + size = 3; + break; + default: + pr_err("%s: unknown size encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + insn &= ~GENMASK(31, 30); + insn |= size << 30; + + return insn; +} + +static inline long branch_imm_common(unsigned long pc, unsigned long addr, + long range) +{ + long offset; + + if ((pc & 0x3) || (addr & 0x3)) { + pr_err("%s: A64 instructions must be word aligned\n", __func__); + return range; + } + + offset = ((long)addr - (long)pc); + + if (offset < -range || offset >= range) { + pr_err("%s: offset out of range\n", __func__); + return range; + } + + return offset; +} + +u32 __kprobes aarch64_insn_gen_branch_imm(unsigned long pc, unsigned long addr, + enum aarch64_insn_branch_type type) +{ + u32 insn; + long offset; + + /* + * B/BL support [-128M, 128M) offset + * ARM64 virtual address arrangement guarantees all kernel and module + * texts are within +/-128M. + */ + offset = branch_imm_common(pc, addr, SZ_128M); + if (offset >= SZ_128M) + return AARCH64_BREAK_FAULT; + + switch (type) { + case AARCH64_INSN_BRANCH_LINK: + insn = aarch64_insn_get_bl_value(); + break; + case AARCH64_INSN_BRANCH_NOLINK: + insn = aarch64_insn_get_b_value(); + break; + default: + pr_err("%s: unknown branch encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_26, insn, + offset >> 2); +} + +u32 aarch64_insn_gen_comp_branch_imm(unsigned long pc, unsigned long addr, + enum aarch64_insn_register reg, + enum aarch64_insn_variant variant, + enum aarch64_insn_branch_type type) +{ + u32 insn; + long offset; + + offset = branch_imm_common(pc, addr, SZ_1M); + if (offset >= SZ_1M) + return AARCH64_BREAK_FAULT; + + switch (type) { + case AARCH64_INSN_BRANCH_COMP_ZERO: + insn = aarch64_insn_get_cbz_value(); + break; + case AARCH64_INSN_BRANCH_COMP_NONZERO: + insn = aarch64_insn_get_cbnz_value(); + break; + default: + pr_err("%s: unknown branch encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + switch (variant) { + case AARCH64_INSN_VARIANT_32BIT: + break; + case AARCH64_INSN_VARIANT_64BIT: + insn |= AARCH64_INSN_SF_BIT; + break; + default: + pr_err("%s: unknown variant encoding %d\n", __func__, variant); + return AARCH64_BREAK_FAULT; + } + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RT, insn, reg); + + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_19, insn, + offset >> 2); +} + +u32 aarch64_insn_gen_cond_branch_imm(unsigned long pc, unsigned long addr, + enum aarch64_insn_condition cond) +{ + u32 insn; + long offset; + + offset = branch_imm_common(pc, addr, SZ_1M); + + insn = aarch64_insn_get_bcond_value(); + + if (cond < AARCH64_INSN_COND_EQ || cond > AARCH64_INSN_COND_AL) { + pr_err("%s: unknown condition encoding %d\n", __func__, cond); + return AARCH64_BREAK_FAULT; + } + insn |= cond; + + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_19, insn, + offset >> 2); +} + +u32 __kprobes aarch64_insn_gen_hint(enum aarch64_insn_hint_cr_op op) +{ + return aarch64_insn_get_hint_value() | op; +} + +u32 __kprobes aarch64_insn_gen_nop(void) +{ + return aarch64_insn_gen_hint(AARCH64_INSN_HINT_NOP); +} + +u32 aarch64_insn_gen_branch_reg(enum aarch64_insn_register reg, + enum aarch64_insn_branch_type type) +{ + u32 insn; + + switch (type) { + case AARCH64_INSN_BRANCH_NOLINK: + insn = aarch64_insn_get_br_value(); + break; + case AARCH64_INSN_BRANCH_LINK: + insn = aarch64_insn_get_blr_value(); + break; + case AARCH64_INSN_BRANCH_RETURN: + insn = aarch64_insn_get_ret_value(); + break; + default: + pr_err("%s: unknown branch encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + return aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, reg); +} + +u32 aarch64_insn_gen_load_store_reg(enum aarch64_insn_register reg, + enum aarch64_insn_register base, + enum aarch64_insn_register offset, + enum aarch64_insn_size_type size, + enum aarch64_insn_ldst_type type) +{ + u32 insn; + + switch (type) { + case AARCH64_INSN_LDST_LOAD_REG_OFFSET: + insn = aarch64_insn_get_ldr_reg_value(); + break; + case AARCH64_INSN_LDST_STORE_REG_OFFSET: + insn = aarch64_insn_get_str_reg_value(); + break; + default: + pr_err("%s: unknown load/store encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + insn = aarch64_insn_encode_ldst_size(size, insn); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RT, insn, reg); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, + base); + + return aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RM, insn, + offset); +} + +u32 aarch64_insn_gen_load_store_pair(enum aarch64_insn_register reg1, + enum aarch64_insn_register reg2, + enum aarch64_insn_register base, + int offset, + enum aarch64_insn_variant variant, + enum aarch64_insn_ldst_type type) +{ + u32 insn; + int shift; + + switch (type) { + case AARCH64_INSN_LDST_LOAD_PAIR_PRE_INDEX: + insn = aarch64_insn_get_ldp_pre_value(); + break; + case AARCH64_INSN_LDST_STORE_PAIR_PRE_INDEX: + insn = aarch64_insn_get_stp_pre_value(); + break; + case AARCH64_INSN_LDST_LOAD_PAIR_POST_INDEX: + insn = aarch64_insn_get_ldp_post_value(); + break; + case AARCH64_INSN_LDST_STORE_PAIR_POST_INDEX: + insn = aarch64_insn_get_stp_post_value(); + break; + default: + pr_err("%s: unknown load/store encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + switch (variant) { + case AARCH64_INSN_VARIANT_32BIT: + if ((offset & 0x3) || (offset < -256) || (offset > 252)) { + pr_err("%s: offset must be multiples of 4 in the range of [-256, 252] %d\n", + __func__, offset); + return AARCH64_BREAK_FAULT; + } + shift = 2; + break; + case AARCH64_INSN_VARIANT_64BIT: + if ((offset & 0x7) || (offset < -512) || (offset > 504)) { + pr_err("%s: offset must be multiples of 8 in the range of [-512, 504] %d\n", + __func__, offset); + return AARCH64_BREAK_FAULT; + } + shift = 3; + insn |= AARCH64_INSN_SF_BIT; + break; + default: + pr_err("%s: unknown variant encoding %d\n", __func__, variant); + return AARCH64_BREAK_FAULT; + } + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RT, insn, + reg1); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RT2, insn, + reg2); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, + base); + + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_7, insn, + offset >> shift); +} + +u32 aarch64_insn_gen_load_store_ex(enum aarch64_insn_register reg, + enum aarch64_insn_register base, + enum aarch64_insn_register state, + enum aarch64_insn_size_type size, + enum aarch64_insn_ldst_type type) +{ + u32 insn; + + switch (type) { + case AARCH64_INSN_LDST_LOAD_EX: + insn = aarch64_insn_get_load_ex_value(); + break; + case AARCH64_INSN_LDST_STORE_EX: + insn = aarch64_insn_get_store_ex_value(); + break; + default: + pr_err("%s: unknown load/store exclusive encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + insn = aarch64_insn_encode_ldst_size(size, insn); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RT, insn, + reg); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, + base); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RT2, insn, + AARCH64_INSN_REG_ZR); + + return aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RS, insn, + state); +} + +u32 aarch64_insn_gen_ldadd(enum aarch64_insn_register result, + enum aarch64_insn_register address, + enum aarch64_insn_register value, + enum aarch64_insn_size_type size) +{ + u32 insn = aarch64_insn_get_ldadd_value(); + + switch (size) { + case AARCH64_INSN_SIZE_32: + case AARCH64_INSN_SIZE_64: + break; + default: + pr_err("%s: unimplemented size encoding %d\n", __func__, size); + return AARCH64_BREAK_FAULT; + } + + insn = aarch64_insn_encode_ldst_size(size, insn); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RT, insn, + result); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, + address); + + return aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RS, insn, + value); +} + +u32 aarch64_insn_gen_stadd(enum aarch64_insn_register address, + enum aarch64_insn_register value, + enum aarch64_insn_size_type size) +{ + /* + * STADD is simply encoded as an alias for LDADD with XZR as + * the destination register. + */ + return aarch64_insn_gen_ldadd(AARCH64_INSN_REG_ZR, address, + value, size); +} + +static u32 aarch64_insn_encode_prfm_imm(enum aarch64_insn_prfm_type type, + enum aarch64_insn_prfm_target target, + enum aarch64_insn_prfm_policy policy, + u32 insn) +{ + u32 imm_type = 0, imm_target = 0, imm_policy = 0; + + switch (type) { + case AARCH64_INSN_PRFM_TYPE_PLD: + break; + case AARCH64_INSN_PRFM_TYPE_PLI: + imm_type = BIT(0); + break; + case AARCH64_INSN_PRFM_TYPE_PST: + imm_type = BIT(1); + break; + default: + pr_err("%s: unknown prfm type encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + switch (target) { + case AARCH64_INSN_PRFM_TARGET_L1: + break; + case AARCH64_INSN_PRFM_TARGET_L2: + imm_target = BIT(0); + break; + case AARCH64_INSN_PRFM_TARGET_L3: + imm_target = BIT(1); + break; + default: + pr_err("%s: unknown prfm target encoding %d\n", __func__, target); + return AARCH64_BREAK_FAULT; + } + + switch (policy) { + case AARCH64_INSN_PRFM_POLICY_KEEP: + break; + case AARCH64_INSN_PRFM_POLICY_STRM: + imm_policy = BIT(0); + break; + default: + pr_err("%s: unknown prfm policy encoding %d\n", __func__, policy); + return AARCH64_BREAK_FAULT; + } + + /* In this case, imm5 is encoded into Rt field. */ + insn &= ~GENMASK(4, 0); + insn |= imm_policy | (imm_target << 1) | (imm_type << 3); + + return insn; +} + +u32 aarch64_insn_gen_prefetch(enum aarch64_insn_register base, + enum aarch64_insn_prfm_type type, + enum aarch64_insn_prfm_target target, + enum aarch64_insn_prfm_policy policy) +{ + u32 insn = aarch64_insn_get_prfm_value(); + + insn = aarch64_insn_encode_ldst_size(AARCH64_INSN_SIZE_64, insn); + + insn = aarch64_insn_encode_prfm_imm(type, target, policy, insn); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, + base); + + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_12, insn, 0); +} + +u32 aarch64_insn_gen_add_sub_imm(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + int imm, enum aarch64_insn_variant variant, + enum aarch64_insn_adsb_type type) +{ + u32 insn; + + switch (type) { + case AARCH64_INSN_ADSB_ADD: + insn = aarch64_insn_get_add_imm_value(); + break; + case AARCH64_INSN_ADSB_SUB: + insn = aarch64_insn_get_sub_imm_value(); + break; + case AARCH64_INSN_ADSB_ADD_SETFLAGS: + insn = aarch64_insn_get_adds_imm_value(); + break; + case AARCH64_INSN_ADSB_SUB_SETFLAGS: + insn = aarch64_insn_get_subs_imm_value(); + break; + default: + pr_err("%s: unknown add/sub encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + switch (variant) { + case AARCH64_INSN_VARIANT_32BIT: + break; + case AARCH64_INSN_VARIANT_64BIT: + insn |= AARCH64_INSN_SF_BIT; + break; + default: + pr_err("%s: unknown variant encoding %d\n", __func__, variant); + return AARCH64_BREAK_FAULT; + } + + /* We can't encode more than a 24bit value (12bit + 12bit shift) */ + if (imm & ~(BIT(24) - 1)) + goto out; + + /* If we have something in the top 12 bits... */ + if (imm & ~(SZ_4K - 1)) { + /* ... and in the low 12 bits -> error */ + if (imm & (SZ_4K - 1)) + goto out; + + imm >>= 12; + insn |= AARCH64_INSN_LSL_12; + } + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RD, insn, dst); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, src); + + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_12, insn, imm); + +out: + pr_err("%s: invalid immediate encoding %d\n", __func__, imm); + return AARCH64_BREAK_FAULT; +} + +u32 aarch64_insn_gen_bitfield(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + int immr, int imms, + enum aarch64_insn_variant variant, + enum aarch64_insn_bitfield_type type) +{ + u32 insn; + u32 mask; + + switch (type) { + case AARCH64_INSN_BITFIELD_MOVE: + insn = aarch64_insn_get_bfm_value(); + break; + case AARCH64_INSN_BITFIELD_MOVE_UNSIGNED: + insn = aarch64_insn_get_ubfm_value(); + break; + case AARCH64_INSN_BITFIELD_MOVE_SIGNED: + insn = aarch64_insn_get_sbfm_value(); + break; + default: + pr_err("%s: unknown bitfield encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + switch (variant) { + case AARCH64_INSN_VARIANT_32BIT: + mask = GENMASK(4, 0); + break; + case AARCH64_INSN_VARIANT_64BIT: + insn |= AARCH64_INSN_SF_BIT | AARCH64_INSN_N_BIT; + mask = GENMASK(5, 0); + break; + default: + pr_err("%s: unknown variant encoding %d\n", __func__, variant); + return AARCH64_BREAK_FAULT; + } + + if (immr & ~mask) { + pr_err("%s: invalid immr encoding %d\n", __func__, immr); + return AARCH64_BREAK_FAULT; + } + if (imms & ~mask) { + pr_err("%s: invalid imms encoding %d\n", __func__, imms); + return AARCH64_BREAK_FAULT; + } + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RD, insn, dst); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, src); + + insn = aarch64_insn_encode_immediate(AARCH64_INSN_IMM_R, insn, immr); + + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_S, insn, imms); +} + +u32 aarch64_insn_gen_movewide(enum aarch64_insn_register dst, + int imm, int shift, + enum aarch64_insn_variant variant, + enum aarch64_insn_movewide_type type) +{ + u32 insn; + + switch (type) { + case AARCH64_INSN_MOVEWIDE_ZERO: + insn = aarch64_insn_get_movz_value(); + break; + case AARCH64_INSN_MOVEWIDE_KEEP: + insn = aarch64_insn_get_movk_value(); + break; + case AARCH64_INSN_MOVEWIDE_INVERSE: + insn = aarch64_insn_get_movn_value(); + break; + default: + pr_err("%s: unknown movewide encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + if (imm & ~(SZ_64K - 1)) { + pr_err("%s: invalid immediate encoding %d\n", __func__, imm); + return AARCH64_BREAK_FAULT; + } + + switch (variant) { + case AARCH64_INSN_VARIANT_32BIT: + if (shift != 0 && shift != 16) { + pr_err("%s: invalid shift encoding %d\n", __func__, + shift); + return AARCH64_BREAK_FAULT; + } + break; + case AARCH64_INSN_VARIANT_64BIT: + insn |= AARCH64_INSN_SF_BIT; + if (shift != 0 && shift != 16 && shift != 32 && shift != 48) { + pr_err("%s: invalid shift encoding %d\n", __func__, + shift); + return AARCH64_BREAK_FAULT; + } + break; + default: + pr_err("%s: unknown variant encoding %d\n", __func__, variant); + return AARCH64_BREAK_FAULT; + } + + insn |= (shift >> 4) << 21; + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RD, insn, dst); + + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_16, insn, imm); +} + +u32 aarch64_insn_gen_add_sub_shifted_reg(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + enum aarch64_insn_register reg, + int shift, + enum aarch64_insn_variant variant, + enum aarch64_insn_adsb_type type) +{ + u32 insn; + + switch (type) { + case AARCH64_INSN_ADSB_ADD: + insn = aarch64_insn_get_add_value(); + break; + case AARCH64_INSN_ADSB_SUB: + insn = aarch64_insn_get_sub_value(); + break; + case AARCH64_INSN_ADSB_ADD_SETFLAGS: + insn = aarch64_insn_get_adds_value(); + break; + case AARCH64_INSN_ADSB_SUB_SETFLAGS: + insn = aarch64_insn_get_subs_value(); + break; + default: + pr_err("%s: unknown add/sub encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + switch (variant) { + case AARCH64_INSN_VARIANT_32BIT: + if (shift & ~(SZ_32 - 1)) { + pr_err("%s: invalid shift encoding %d\n", __func__, + shift); + return AARCH64_BREAK_FAULT; + } + break; + case AARCH64_INSN_VARIANT_64BIT: + insn |= AARCH64_INSN_SF_BIT; + if (shift & ~(SZ_64 - 1)) { + pr_err("%s: invalid shift encoding %d\n", __func__, + shift); + return AARCH64_BREAK_FAULT; + } + break; + default: + pr_err("%s: unknown variant encoding %d\n", __func__, variant); + return AARCH64_BREAK_FAULT; + } + + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RD, insn, dst); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, src); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RM, insn, reg); + + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_6, insn, shift); +} + +u32 aarch64_insn_gen_data1(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + enum aarch64_insn_variant variant, + enum aarch64_insn_data1_type type) +{ + u32 insn; + + switch (type) { + case AARCH64_INSN_DATA1_REVERSE_16: + insn = aarch64_insn_get_rev16_value(); + break; + case AARCH64_INSN_DATA1_REVERSE_32: + insn = aarch64_insn_get_rev32_value(); + break; + case AARCH64_INSN_DATA1_REVERSE_64: + if (variant != AARCH64_INSN_VARIANT_64BIT) { + pr_err("%s: invalid variant for reverse64 %d\n", + __func__, variant); + return AARCH64_BREAK_FAULT; + } + insn = aarch64_insn_get_rev64_value(); + break; + default: + pr_err("%s: unknown data1 encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + switch (variant) { + case AARCH64_INSN_VARIANT_32BIT: + break; + case AARCH64_INSN_VARIANT_64BIT: + insn |= AARCH64_INSN_SF_BIT; + break; + default: + pr_err("%s: unknown variant encoding %d\n", __func__, variant); + return AARCH64_BREAK_FAULT; + } + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RD, insn, dst); + + return aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, src); +} + +u32 aarch64_insn_gen_data2(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + enum aarch64_insn_register reg, + enum aarch64_insn_variant variant, + enum aarch64_insn_data2_type type) +{ + u32 insn; + + switch (type) { + case AARCH64_INSN_DATA2_UDIV: + insn = aarch64_insn_get_udiv_value(); + break; + case AARCH64_INSN_DATA2_SDIV: + insn = aarch64_insn_get_sdiv_value(); + break; + case AARCH64_INSN_DATA2_LSLV: + insn = aarch64_insn_get_lslv_value(); + break; + case AARCH64_INSN_DATA2_LSRV: + insn = aarch64_insn_get_lsrv_value(); + break; + case AARCH64_INSN_DATA2_ASRV: + insn = aarch64_insn_get_asrv_value(); + break; + case AARCH64_INSN_DATA2_RORV: + insn = aarch64_insn_get_rorv_value(); + break; + default: + pr_err("%s: unknown data2 encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + switch (variant) { + case AARCH64_INSN_VARIANT_32BIT: + break; + case AARCH64_INSN_VARIANT_64BIT: + insn |= AARCH64_INSN_SF_BIT; + break; + default: + pr_err("%s: unknown variant encoding %d\n", __func__, variant); + return AARCH64_BREAK_FAULT; + } + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RD, insn, dst); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, src); + + return aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RM, insn, reg); +} + +u32 aarch64_insn_gen_data3(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + enum aarch64_insn_register reg1, + enum aarch64_insn_register reg2, + enum aarch64_insn_variant variant, + enum aarch64_insn_data3_type type) +{ + u32 insn; + + switch (type) { + case AARCH64_INSN_DATA3_MADD: + insn = aarch64_insn_get_madd_value(); + break; + case AARCH64_INSN_DATA3_MSUB: + insn = aarch64_insn_get_msub_value(); + break; + default: + pr_err("%s: unknown data3 encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + switch (variant) { + case AARCH64_INSN_VARIANT_32BIT: + break; + case AARCH64_INSN_VARIANT_64BIT: + insn |= AARCH64_INSN_SF_BIT; + break; + default: + pr_err("%s: unknown variant encoding %d\n", __func__, variant); + return AARCH64_BREAK_FAULT; + } + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RD, insn, dst); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RA, insn, src); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, + reg1); + + return aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RM, insn, + reg2); +} + +u32 aarch64_insn_gen_logical_shifted_reg(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + enum aarch64_insn_register reg, + int shift, + enum aarch64_insn_variant variant, + enum aarch64_insn_logic_type type) +{ + u32 insn; + + switch (type) { + case AARCH64_INSN_LOGIC_AND: + insn = aarch64_insn_get_and_value(); + break; + case AARCH64_INSN_LOGIC_BIC: + insn = aarch64_insn_get_bic_value(); + break; + case AARCH64_INSN_LOGIC_ORR: + insn = aarch64_insn_get_orr_value(); + break; + case AARCH64_INSN_LOGIC_ORN: + insn = aarch64_insn_get_orn_value(); + break; + case AARCH64_INSN_LOGIC_EOR: + insn = aarch64_insn_get_eor_value(); + break; + case AARCH64_INSN_LOGIC_EON: + insn = aarch64_insn_get_eon_value(); + break; + case AARCH64_INSN_LOGIC_AND_SETFLAGS: + insn = aarch64_insn_get_ands_value(); + break; + case AARCH64_INSN_LOGIC_BIC_SETFLAGS: + insn = aarch64_insn_get_bics_value(); + break; + default: + pr_err("%s: unknown logical encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + switch (variant) { + case AARCH64_INSN_VARIANT_32BIT: + if (shift & ~(SZ_32 - 1)) { + pr_err("%s: invalid shift encoding %d\n", __func__, + shift); + return AARCH64_BREAK_FAULT; + } + break; + case AARCH64_INSN_VARIANT_64BIT: + insn |= AARCH64_INSN_SF_BIT; + if (shift & ~(SZ_64 - 1)) { + pr_err("%s: invalid shift encoding %d\n", __func__, + shift); + return AARCH64_BREAK_FAULT; + } + break; + default: + pr_err("%s: unknown variant encoding %d\n", __func__, variant); + return AARCH64_BREAK_FAULT; + } + + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RD, insn, dst); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, src); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RM, insn, reg); + + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_6, insn, shift); +} + +/* + * MOV (register) is architecturally an alias of ORR (shifted register) where + * MOV <*d>, <*m> is equivalent to ORR <*d>, <*ZR>, <*m> + */ +u32 aarch64_insn_gen_move_reg(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + enum aarch64_insn_variant variant) +{ + return aarch64_insn_gen_logical_shifted_reg(dst, AARCH64_INSN_REG_ZR, + src, 0, variant, + AARCH64_INSN_LOGIC_ORR); +} + +u32 aarch64_insn_gen_adr(unsigned long pc, unsigned long addr, + enum aarch64_insn_register reg, + enum aarch64_insn_adr_type type) +{ + u32 insn; + s32 offset; + + switch (type) { + case AARCH64_INSN_ADR_TYPE_ADR: + insn = aarch64_insn_get_adr_value(); + offset = addr - pc; + break; + case AARCH64_INSN_ADR_TYPE_ADRP: + insn = aarch64_insn_get_adrp_value(); + offset = (addr - ALIGN_DOWN(pc, SZ_4K)) >> 12; + break; + default: + pr_err("%s: unknown adr encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + if (offset < -SZ_1M || offset >= SZ_1M) + return AARCH64_BREAK_FAULT; + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RD, insn, reg); + + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_ADR, insn, offset); +} + +/* + * Decode the imm field of a branch, and return the byte offset as a + * signed value (so it can be used when computing a new branch + * target). + */ +s32 aarch64_get_branch_offset(u32 insn) +{ + s32 imm; + + if (aarch64_insn_is_b(insn) || aarch64_insn_is_bl(insn)) { + imm = aarch64_insn_decode_immediate(AARCH64_INSN_IMM_26, insn); + return (imm << 6) >> 4; + } + + if (aarch64_insn_is_cbz(insn) || aarch64_insn_is_cbnz(insn) || + aarch64_insn_is_bcond(insn)) { + imm = aarch64_insn_decode_immediate(AARCH64_INSN_IMM_19, insn); + return (imm << 13) >> 11; + } + + if (aarch64_insn_is_tbz(insn) || aarch64_insn_is_tbnz(insn)) { + imm = aarch64_insn_decode_immediate(AARCH64_INSN_IMM_14, insn); + return (imm << 18) >> 16; + } + + /* Unhandled instruction */ + BUG(); +} + +/* + * Encode the displacement of a branch in the imm field and return the + * updated instruction. + */ +u32 aarch64_set_branch_offset(u32 insn, s32 offset) +{ + if (aarch64_insn_is_b(insn) || aarch64_insn_is_bl(insn)) + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_26, insn, + offset >> 2); + + if (aarch64_insn_is_cbz(insn) || aarch64_insn_is_cbnz(insn) || + aarch64_insn_is_bcond(insn)) + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_19, insn, + offset >> 2); + + if (aarch64_insn_is_tbz(insn) || aarch64_insn_is_tbnz(insn)) + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_14, insn, + offset >> 2); + + /* Unhandled instruction */ + BUG(); +} + +s32 aarch64_insn_adrp_get_offset(u32 insn) +{ + BUG_ON(!aarch64_insn_is_adrp(insn)); + return aarch64_insn_decode_immediate(AARCH64_INSN_IMM_ADR, insn) << 12; +} + +u32 aarch64_insn_adrp_set_offset(u32 insn, s32 offset) +{ + BUG_ON(!aarch64_insn_is_adrp(insn)); + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_ADR, insn, + offset >> 12); +} + +/* + * Extract the Op/CR data from a msr/mrs instruction. + */ +u32 aarch64_insn_extract_system_reg(u32 insn) +{ + return (insn & 0x1FFFE0) >> 5; +} + +static bool range_of_ones(u64 val) +{ + /* Doesn't handle full ones or full zeroes */ + u64 sval = val >> __ffs64(val); + + /* One of Sean Eron Anderson's bithack tricks */ + return ((sval + 1) & (sval)) == 0; +} + +static u32 aarch64_encode_immediate(u64 imm, + enum aarch64_insn_variant variant, + u32 insn) +{ + unsigned int immr, imms, n, ones, ror, esz, tmp; + u64 mask; + + switch (variant) { + case AARCH64_INSN_VARIANT_32BIT: + esz = 32; + break; + case AARCH64_INSN_VARIANT_64BIT: + insn |= AARCH64_INSN_SF_BIT; + esz = 64; + break; + default: + pr_err("%s: unknown variant encoding %d\n", __func__, variant); + return AARCH64_BREAK_FAULT; + } + + mask = GENMASK(esz - 1, 0); + + /* Can't encode full zeroes, full ones, or value wider than the mask */ + if (!imm || imm == mask || imm & ~mask) + return AARCH64_BREAK_FAULT; + + /* + * Inverse of Replicate(). Try to spot a repeating pattern + * with a pow2 stride. + */ + for (tmp = esz / 2; tmp >= 2; tmp /= 2) { + u64 emask = BIT(tmp) - 1; + + if ((imm & emask) != ((imm >> tmp) & emask)) + break; + + esz = tmp; + mask = emask; + } + + /* N is only set if we're encoding a 64bit value */ + n = esz == 64; + + /* Trim imm to the element size */ + imm &= mask; + + /* That's how many ones we need to encode */ + ones = hweight64(imm); + + /* + * imms is set to (ones - 1), prefixed with a string of ones + * and a zero if they fit. Cap it to 6 bits. + */ + imms = ones - 1; + imms |= 0xf << ffs(esz); + imms &= BIT(6) - 1; + + /* Compute the rotation */ + if (range_of_ones(imm)) { + /* + * Pattern: 0..01..10..0 + * + * Compute how many rotate we need to align it right + */ + ror = __ffs64(imm); + } else { + /* + * Pattern: 0..01..10..01..1 + * + * Fill the unused top bits with ones, and check if + * the result is a valid immediate (all ones with a + * contiguous ranges of zeroes). + */ + imm |= ~mask; + if (!range_of_ones(~imm)) + return AARCH64_BREAK_FAULT; + + /* + * Compute the rotation to get a continuous set of + * ones, with the first bit set at position 0 + */ + ror = fls(~imm); + } + + /* + * immr is the number of bits we need to rotate back to the + * original set of ones. Note that this is relative to the + * element size... + */ + immr = (esz - ror) % esz; + + insn = aarch64_insn_encode_immediate(AARCH64_INSN_IMM_N, insn, n); + insn = aarch64_insn_encode_immediate(AARCH64_INSN_IMM_R, insn, immr); + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_S, insn, imms); +} + +u32 aarch64_insn_gen_logical_immediate(enum aarch64_insn_logic_type type, + enum aarch64_insn_variant variant, + enum aarch64_insn_register Rn, + enum aarch64_insn_register Rd, + u64 imm) +{ + u32 insn; + + switch (type) { + case AARCH64_INSN_LOGIC_AND: + insn = aarch64_insn_get_and_imm_value(); + break; + case AARCH64_INSN_LOGIC_ORR: + insn = aarch64_insn_get_orr_imm_value(); + break; + case AARCH64_INSN_LOGIC_EOR: + insn = aarch64_insn_get_eor_imm_value(); + break; + case AARCH64_INSN_LOGIC_AND_SETFLAGS: + insn = aarch64_insn_get_ands_imm_value(); + break; + default: + pr_err("%s: unknown logical encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RD, insn, Rd); + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, Rn); + return aarch64_encode_immediate(imm, variant, insn); +} + +u32 aarch64_insn_gen_extr(enum aarch64_insn_variant variant, + enum aarch64_insn_register Rm, + enum aarch64_insn_register Rn, + enum aarch64_insn_register Rd, + u8 lsb) +{ + u32 insn; + + insn = aarch64_insn_get_extr_value(); + + switch (variant) { + case AARCH64_INSN_VARIANT_32BIT: + if (lsb > 31) + return AARCH64_BREAK_FAULT; + break; + case AARCH64_INSN_VARIANT_64BIT: + if (lsb > 63) + return AARCH64_BREAK_FAULT; + insn |= AARCH64_INSN_SF_BIT; + insn = aarch64_insn_encode_immediate(AARCH64_INSN_IMM_N, insn, 1); + break; + default: + pr_err("%s: unknown variant encoding %d\n", __func__, variant); + return AARCH64_BREAK_FAULT; + } + + insn = aarch64_insn_encode_immediate(AARCH64_INSN_IMM_S, insn, lsb); + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RD, insn, Rd); + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, Rn); + return aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RM, insn, Rm); +} -- 2.25.4 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 02/17] tools: arm64: Make aarch64 instruction decoder available to tools @ 2021-01-20 17:37 ` Julien Thierry 0 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: mark.rutland, linux-efi, michal.lkml, keescook, peterz, catalin.marinas, masahiroy, broonie, linux-hardening, jpoimboe, will, ardb, Julien Thierry Add aarch64 encoder/decoder implementation under tools/ as well as the necessary arm64 headers. Signed-off-by: Julien Thierry <jthierry@redhat.com> --- tools/arch/arm64/include/asm/aarch64-insn.h | 551 +++++++ tools/arch/arm64/lib/aarch64-insn.c | 1425 +++++++++++++++++++ 2 files changed, 1976 insertions(+) create mode 100644 tools/arch/arm64/include/asm/aarch64-insn.h create mode 100644 tools/arch/arm64/lib/aarch64-insn.c diff --git a/tools/arch/arm64/include/asm/aarch64-insn.h b/tools/arch/arm64/include/asm/aarch64-insn.h new file mode 100644 index 000000000000..b202d6e2e47e --- /dev/null +++ b/tools/arch/arm64/include/asm/aarch64-insn.h @@ -0,0 +1,551 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +#ifndef __ASM_AARCH64_INSN_H +#define __ASM_AARCH64_INSN_H + +#include <linux/build_bug.h> +#include <linux/types.h> + + +/* A64 instructions are always 32 bits. */ +#define AARCH64_INSN_SIZE 4 + +/* + * BRK instruction encoding + * The #imm16 value should be placed at bits[20:5] within BRK ins + */ +#define AARCH64_BREAK_MON 0xd4200000 + +/* + * BRK instruction for provoking a fault on purpose + * Unlike kgdb, #imm16 value with unallocated handler is used for faulting. + */ +#define AARCH64_BREAK_FAULT (AARCH64_BREAK_MON | (FAULT_BRK_IMM << 5)) + +#ifndef __ASSEMBLY__ +/* + * ARM Architecture Reference Manual for ARMv8 Profile-A, Issue A.a + * Section C3.1 "A64 instruction index by encoding": + * AArch64 main encoding table + * Bit position + * 28 27 26 25 Encoding Group + * 0 0 - - Unallocated + * 1 0 0 - Data processing, immediate + * 1 0 1 - Branch, exception generation and system instructions + * - 1 - 0 Loads and stores + * - 1 0 1 Data processing - register + * 0 1 1 1 Data processing - SIMD and floating point + * 1 1 1 1 Data processing - SIMD and floating point + * "-" means "don't care" + */ +enum aarch64_insn_encoding_class { + AARCH64_INSN_CLS_UNKNOWN, /* UNALLOCATED */ + AARCH64_INSN_CLS_SVE, /* SVE instructions */ + AARCH64_INSN_CLS_DP_IMM, /* Data processing - immediate */ + AARCH64_INSN_CLS_DP_REG, /* Data processing - register */ + AARCH64_INSN_CLS_DP_FPSIMD, /* Data processing - SIMD and FP */ + AARCH64_INSN_CLS_LDST, /* Loads and stores */ + AARCH64_INSN_CLS_BR_SYS, /* Branch, exception generation and + * system instructions */ +}; + +enum aarch64_insn_hint_cr_op { + AARCH64_INSN_HINT_NOP = 0x0 << 5, + AARCH64_INSN_HINT_YIELD = 0x1 << 5, + AARCH64_INSN_HINT_WFE = 0x2 << 5, + AARCH64_INSN_HINT_WFI = 0x3 << 5, + AARCH64_INSN_HINT_SEV = 0x4 << 5, + AARCH64_INSN_HINT_SEVL = 0x5 << 5, + + AARCH64_INSN_HINT_XPACLRI = 0x07 << 5, + AARCH64_INSN_HINT_PACIA_1716 = 0x08 << 5, + AARCH64_INSN_HINT_PACIB_1716 = 0x0A << 5, + AARCH64_INSN_HINT_AUTIA_1716 = 0x0C << 5, + AARCH64_INSN_HINT_AUTIB_1716 = 0x0E << 5, + AARCH64_INSN_HINT_PACIAZ = 0x18 << 5, + AARCH64_INSN_HINT_PACIASP = 0x19 << 5, + AARCH64_INSN_HINT_PACIBZ = 0x1A << 5, + AARCH64_INSN_HINT_PACIBSP = 0x1B << 5, + AARCH64_INSN_HINT_AUTIAZ = 0x1C << 5, + AARCH64_INSN_HINT_AUTIASP = 0x1D << 5, + AARCH64_INSN_HINT_AUTIBZ = 0x1E << 5, + AARCH64_INSN_HINT_AUTIBSP = 0x1F << 5, + + AARCH64_INSN_HINT_ESB = 0x10 << 5, + AARCH64_INSN_HINT_PSB = 0x11 << 5, + AARCH64_INSN_HINT_TSB = 0x12 << 5, + AARCH64_INSN_HINT_CSDB = 0x14 << 5, + + AARCH64_INSN_HINT_BTI = 0x20 << 5, + AARCH64_INSN_HINT_BTIC = 0x22 << 5, + AARCH64_INSN_HINT_BTIJ = 0x24 << 5, + AARCH64_INSN_HINT_BTIJC = 0x26 << 5, +}; + +enum aarch64_insn_imm_type { + AARCH64_INSN_IMM_ADR, + AARCH64_INSN_IMM_26, + AARCH64_INSN_IMM_19, + AARCH64_INSN_IMM_16, + AARCH64_INSN_IMM_14, + AARCH64_INSN_IMM_12, + AARCH64_INSN_IMM_9, + AARCH64_INSN_IMM_7, + AARCH64_INSN_IMM_6, + AARCH64_INSN_IMM_S, + AARCH64_INSN_IMM_R, + AARCH64_INSN_IMM_N, + AARCH64_INSN_IMM_MAX +}; + +enum aarch64_insn_register_type { + AARCH64_INSN_REGTYPE_RT, + AARCH64_INSN_REGTYPE_RN, + AARCH64_INSN_REGTYPE_RT2, + AARCH64_INSN_REGTYPE_RM, + AARCH64_INSN_REGTYPE_RD, + AARCH64_INSN_REGTYPE_RA, + AARCH64_INSN_REGTYPE_RS, +}; + +enum aarch64_insn_register { + AARCH64_INSN_REG_0 = 0, + AARCH64_INSN_REG_1 = 1, + AARCH64_INSN_REG_2 = 2, + AARCH64_INSN_REG_3 = 3, + AARCH64_INSN_REG_4 = 4, + AARCH64_INSN_REG_5 = 5, + AARCH64_INSN_REG_6 = 6, + AARCH64_INSN_REG_7 = 7, + AARCH64_INSN_REG_8 = 8, + AARCH64_INSN_REG_9 = 9, + AARCH64_INSN_REG_10 = 10, + AARCH64_INSN_REG_11 = 11, + AARCH64_INSN_REG_12 = 12, + AARCH64_INSN_REG_13 = 13, + AARCH64_INSN_REG_14 = 14, + AARCH64_INSN_REG_15 = 15, + AARCH64_INSN_REG_16 = 16, + AARCH64_INSN_REG_17 = 17, + AARCH64_INSN_REG_18 = 18, + AARCH64_INSN_REG_19 = 19, + AARCH64_INSN_REG_20 = 20, + AARCH64_INSN_REG_21 = 21, + AARCH64_INSN_REG_22 = 22, + AARCH64_INSN_REG_23 = 23, + AARCH64_INSN_REG_24 = 24, + AARCH64_INSN_REG_25 = 25, + AARCH64_INSN_REG_26 = 26, + AARCH64_INSN_REG_27 = 27, + AARCH64_INSN_REG_28 = 28, + AARCH64_INSN_REG_29 = 29, + AARCH64_INSN_REG_FP = 29, /* Frame pointer */ + AARCH64_INSN_REG_30 = 30, + AARCH64_INSN_REG_LR = 30, /* Link register */ + AARCH64_INSN_REG_ZR = 31, /* Zero: as source register */ + AARCH64_INSN_REG_SP = 31 /* Stack pointer: as load/store base reg */ +}; + +enum aarch64_insn_special_register { + AARCH64_INSN_SPCLREG_SPSR_EL1 = 0xC200, + AARCH64_INSN_SPCLREG_ELR_EL1 = 0xC201, + AARCH64_INSN_SPCLREG_SP_EL0 = 0xC208, + AARCH64_INSN_SPCLREG_SPSEL = 0xC210, + AARCH64_INSN_SPCLREG_CURRENTEL = 0xC212, + AARCH64_INSN_SPCLREG_DAIF = 0xDA11, + AARCH64_INSN_SPCLREG_NZCV = 0xDA10, + AARCH64_INSN_SPCLREG_FPCR = 0xDA20, + AARCH64_INSN_SPCLREG_DSPSR_EL0 = 0xDA28, + AARCH64_INSN_SPCLREG_DLR_EL0 = 0xDA29, + AARCH64_INSN_SPCLREG_SPSR_EL2 = 0xE200, + AARCH64_INSN_SPCLREG_ELR_EL2 = 0xE201, + AARCH64_INSN_SPCLREG_SP_EL1 = 0xE208, + AARCH64_INSN_SPCLREG_SPSR_INQ = 0xE218, + AARCH64_INSN_SPCLREG_SPSR_ABT = 0xE219, + AARCH64_INSN_SPCLREG_SPSR_UND = 0xE21A, + AARCH64_INSN_SPCLREG_SPSR_FIQ = 0xE21B, + AARCH64_INSN_SPCLREG_SPSR_EL3 = 0xF200, + AARCH64_INSN_SPCLREG_ELR_EL3 = 0xF201, + AARCH64_INSN_SPCLREG_SP_EL2 = 0xF210 +}; + +enum aarch64_insn_variant { + AARCH64_INSN_VARIANT_32BIT, + AARCH64_INSN_VARIANT_64BIT +}; + +enum aarch64_insn_condition { + AARCH64_INSN_COND_EQ = 0x0, /* == */ + AARCH64_INSN_COND_NE = 0x1, /* != */ + AARCH64_INSN_COND_CS = 0x2, /* unsigned >= */ + AARCH64_INSN_COND_CC = 0x3, /* unsigned < */ + AARCH64_INSN_COND_MI = 0x4, /* < 0 */ + AARCH64_INSN_COND_PL = 0x5, /* >= 0 */ + AARCH64_INSN_COND_VS = 0x6, /* overflow */ + AARCH64_INSN_COND_VC = 0x7, /* no overflow */ + AARCH64_INSN_COND_HI = 0x8, /* unsigned > */ + AARCH64_INSN_COND_LS = 0x9, /* unsigned <= */ + AARCH64_INSN_COND_GE = 0xa, /* signed >= */ + AARCH64_INSN_COND_LT = 0xb, /* signed < */ + AARCH64_INSN_COND_GT = 0xc, /* signed > */ + AARCH64_INSN_COND_LE = 0xd, /* signed <= */ + AARCH64_INSN_COND_AL = 0xe, /* always */ +}; + +enum aarch64_insn_branch_type { + AARCH64_INSN_BRANCH_NOLINK, + AARCH64_INSN_BRANCH_LINK, + AARCH64_INSN_BRANCH_RETURN, + AARCH64_INSN_BRANCH_COMP_ZERO, + AARCH64_INSN_BRANCH_COMP_NONZERO, +}; + +enum aarch64_insn_size_type { + AARCH64_INSN_SIZE_8, + AARCH64_INSN_SIZE_16, + AARCH64_INSN_SIZE_32, + AARCH64_INSN_SIZE_64, +}; + +enum aarch64_insn_ldst_type { + AARCH64_INSN_LDST_LOAD_REG_OFFSET, + AARCH64_INSN_LDST_STORE_REG_OFFSET, + AARCH64_INSN_LDST_LOAD_PAIR_PRE_INDEX, + AARCH64_INSN_LDST_STORE_PAIR_PRE_INDEX, + AARCH64_INSN_LDST_LOAD_PAIR_POST_INDEX, + AARCH64_INSN_LDST_STORE_PAIR_POST_INDEX, + AARCH64_INSN_LDST_LOAD_EX, + AARCH64_INSN_LDST_STORE_EX, +}; + +enum aarch64_insn_adsb_type { + AARCH64_INSN_ADSB_ADD, + AARCH64_INSN_ADSB_SUB, + AARCH64_INSN_ADSB_ADD_SETFLAGS, + AARCH64_INSN_ADSB_SUB_SETFLAGS +}; + +enum aarch64_insn_movewide_type { + AARCH64_INSN_MOVEWIDE_ZERO, + AARCH64_INSN_MOVEWIDE_KEEP, + AARCH64_INSN_MOVEWIDE_INVERSE +}; + +enum aarch64_insn_bitfield_type { + AARCH64_INSN_BITFIELD_MOVE, + AARCH64_INSN_BITFIELD_MOVE_UNSIGNED, + AARCH64_INSN_BITFIELD_MOVE_SIGNED +}; + +enum aarch64_insn_data1_type { + AARCH64_INSN_DATA1_REVERSE_16, + AARCH64_INSN_DATA1_REVERSE_32, + AARCH64_INSN_DATA1_REVERSE_64, +}; + +enum aarch64_insn_data2_type { + AARCH64_INSN_DATA2_UDIV, + AARCH64_INSN_DATA2_SDIV, + AARCH64_INSN_DATA2_LSLV, + AARCH64_INSN_DATA2_LSRV, + AARCH64_INSN_DATA2_ASRV, + AARCH64_INSN_DATA2_RORV, +}; + +enum aarch64_insn_data3_type { + AARCH64_INSN_DATA3_MADD, + AARCH64_INSN_DATA3_MSUB, +}; + +enum aarch64_insn_logic_type { + AARCH64_INSN_LOGIC_AND, + AARCH64_INSN_LOGIC_BIC, + AARCH64_INSN_LOGIC_ORR, + AARCH64_INSN_LOGIC_ORN, + AARCH64_INSN_LOGIC_EOR, + AARCH64_INSN_LOGIC_EON, + AARCH64_INSN_LOGIC_AND_SETFLAGS, + AARCH64_INSN_LOGIC_BIC_SETFLAGS +}; + +enum aarch64_insn_prfm_type { + AARCH64_INSN_PRFM_TYPE_PLD, + AARCH64_INSN_PRFM_TYPE_PLI, + AARCH64_INSN_PRFM_TYPE_PST, +}; + +enum aarch64_insn_prfm_target { + AARCH64_INSN_PRFM_TARGET_L1, + AARCH64_INSN_PRFM_TARGET_L2, + AARCH64_INSN_PRFM_TARGET_L3, +}; + +enum aarch64_insn_prfm_policy { + AARCH64_INSN_PRFM_POLICY_KEEP, + AARCH64_INSN_PRFM_POLICY_STRM, +}; + +enum aarch64_insn_adr_type { + AARCH64_INSN_ADR_TYPE_ADRP, + AARCH64_INSN_ADR_TYPE_ADR, +}; + +#define __AARCH64_INSN_FUNCS(abbr, mask, val) \ +static __always_inline bool aarch64_insn_is_##abbr(u32 code) \ +{ \ + BUILD_BUG_ON(~(mask) & (val)); \ + return (code & (mask)) == (val); \ +} \ +static __always_inline u32 aarch64_insn_get_##abbr##_value(void) \ +{ \ + return (val); \ +} + +__AARCH64_INSN_FUNCS(adr, 0x9F000000, 0x10000000) +__AARCH64_INSN_FUNCS(adrp, 0x9F000000, 0x90000000) +__AARCH64_INSN_FUNCS(prfm, 0x3FC00000, 0x39800000) +__AARCH64_INSN_FUNCS(prfm_lit, 0xFF000000, 0xD8000000) +__AARCH64_INSN_FUNCS(store_imm, 0x3FC00000, 0x39000000) +__AARCH64_INSN_FUNCS(load_imm, 0x3FC00000, 0x39400000) +__AARCH64_INSN_FUNCS(store_pre, 0x3FE00C00, 0x38000C00) +__AARCH64_INSN_FUNCS(load_pre, 0x3FE00C00, 0x38400C00) +__AARCH64_INSN_FUNCS(store_post, 0x3FE00C00, 0x38000400) +__AARCH64_INSN_FUNCS(load_post, 0x3FE00C00, 0x38400400) +__AARCH64_INSN_FUNCS(str_reg, 0x3FE0EC00, 0x38206800) +__AARCH64_INSN_FUNCS(ldadd, 0x3F20FC00, 0x38200000) +__AARCH64_INSN_FUNCS(ldr_reg, 0x3FE0EC00, 0x38606800) +__AARCH64_INSN_FUNCS(ldr_lit, 0xBF000000, 0x18000000) +__AARCH64_INSN_FUNCS(ldrsw_lit, 0xFF000000, 0x98000000) +__AARCH64_INSN_FUNCS(exclusive, 0x3F800000, 0x08000000) +__AARCH64_INSN_FUNCS(load_ex, 0x3F400000, 0x08400000) +__AARCH64_INSN_FUNCS(store_ex, 0x3F400000, 0x08000000) +__AARCH64_INSN_FUNCS(stp, 0x7FC00000, 0x29000000) +__AARCH64_INSN_FUNCS(ldp, 0x7FC00000, 0x29400000) +__AARCH64_INSN_FUNCS(stp_post, 0x7FC00000, 0x28800000) +__AARCH64_INSN_FUNCS(ldp_post, 0x7FC00000, 0x28C00000) +__AARCH64_INSN_FUNCS(stp_pre, 0x7FC00000, 0x29800000) +__AARCH64_INSN_FUNCS(ldp_pre, 0x7FC00000, 0x29C00000) +__AARCH64_INSN_FUNCS(add_imm, 0x7F000000, 0x11000000) +__AARCH64_INSN_FUNCS(adds_imm, 0x7F000000, 0x31000000) +__AARCH64_INSN_FUNCS(sub_imm, 0x7F000000, 0x51000000) +__AARCH64_INSN_FUNCS(subs_imm, 0x7F000000, 0x71000000) +__AARCH64_INSN_FUNCS(movn, 0x7F800000, 0x12800000) +__AARCH64_INSN_FUNCS(sbfm, 0x7F800000, 0x13000000) +__AARCH64_INSN_FUNCS(bfm, 0x7F800000, 0x33000000) +__AARCH64_INSN_FUNCS(movz, 0x7F800000, 0x52800000) +__AARCH64_INSN_FUNCS(ubfm, 0x7F800000, 0x53000000) +__AARCH64_INSN_FUNCS(movk, 0x7F800000, 0x72800000) +__AARCH64_INSN_FUNCS(add, 0x7F200000, 0x0B000000) +__AARCH64_INSN_FUNCS(adds, 0x7F200000, 0x2B000000) +__AARCH64_INSN_FUNCS(sub, 0x7F200000, 0x4B000000) +__AARCH64_INSN_FUNCS(subs, 0x7F200000, 0x6B000000) +__AARCH64_INSN_FUNCS(madd, 0x7FE08000, 0x1B000000) +__AARCH64_INSN_FUNCS(msub, 0x7FE08000, 0x1B008000) +__AARCH64_INSN_FUNCS(udiv, 0x7FE0FC00, 0x1AC00800) +__AARCH64_INSN_FUNCS(sdiv, 0x7FE0FC00, 0x1AC00C00) +__AARCH64_INSN_FUNCS(lslv, 0x7FE0FC00, 0x1AC02000) +__AARCH64_INSN_FUNCS(lsrv, 0x7FE0FC00, 0x1AC02400) +__AARCH64_INSN_FUNCS(asrv, 0x7FE0FC00, 0x1AC02800) +__AARCH64_INSN_FUNCS(rorv, 0x7FE0FC00, 0x1AC02C00) +__AARCH64_INSN_FUNCS(rev16, 0x7FFFFC00, 0x5AC00400) +__AARCH64_INSN_FUNCS(rev32, 0x7FFFFC00, 0x5AC00800) +__AARCH64_INSN_FUNCS(rev64, 0x7FFFFC00, 0x5AC00C00) +__AARCH64_INSN_FUNCS(and, 0x7F200000, 0x0A000000) +__AARCH64_INSN_FUNCS(bic, 0x7F200000, 0x0A200000) +__AARCH64_INSN_FUNCS(orr, 0x7F200000, 0x2A000000) +__AARCH64_INSN_FUNCS(mov_reg, 0x7FE0FFE0, 0x2A0003E0) +__AARCH64_INSN_FUNCS(orn, 0x7F200000, 0x2A200000) +__AARCH64_INSN_FUNCS(eor, 0x7F200000, 0x4A000000) +__AARCH64_INSN_FUNCS(eon, 0x7F200000, 0x4A200000) +__AARCH64_INSN_FUNCS(ands, 0x7F200000, 0x6A000000) +__AARCH64_INSN_FUNCS(bics, 0x7F200000, 0x6A200000) +__AARCH64_INSN_FUNCS(and_imm, 0x7F800000, 0x12000000) +__AARCH64_INSN_FUNCS(orr_imm, 0x7F800000, 0x32000000) +__AARCH64_INSN_FUNCS(eor_imm, 0x7F800000, 0x52000000) +__AARCH64_INSN_FUNCS(ands_imm, 0x7F800000, 0x72000000) +__AARCH64_INSN_FUNCS(extr, 0x7FA00000, 0x13800000) +__AARCH64_INSN_FUNCS(b, 0xFC000000, 0x14000000) +__AARCH64_INSN_FUNCS(bl, 0xFC000000, 0x94000000) +__AARCH64_INSN_FUNCS(cbz, 0x7F000000, 0x34000000) +__AARCH64_INSN_FUNCS(cbnz, 0x7F000000, 0x35000000) +__AARCH64_INSN_FUNCS(tbz, 0x7F000000, 0x36000000) +__AARCH64_INSN_FUNCS(tbnz, 0x7F000000, 0x37000000) +__AARCH64_INSN_FUNCS(bcond, 0xFF000010, 0x54000000) +__AARCH64_INSN_FUNCS(svc, 0xFFE0001F, 0xD4000001) +__AARCH64_INSN_FUNCS(hvc, 0xFFE0001F, 0xD4000002) +__AARCH64_INSN_FUNCS(smc, 0xFFE0001F, 0xD4000003) +__AARCH64_INSN_FUNCS(brk, 0xFFE0001F, 0xD4200000) +__AARCH64_INSN_FUNCS(exception, 0xFF000000, 0xD4000000) +__AARCH64_INSN_FUNCS(hint, 0xFFFFF01F, 0xD503201F) +__AARCH64_INSN_FUNCS(br, 0xFFFFFC1F, 0xD61F0000) +__AARCH64_INSN_FUNCS(br_auth, 0xFEFFF800, 0xD61F0800) +__AARCH64_INSN_FUNCS(blr, 0xFFFFFC1F, 0xD63F0000) +__AARCH64_INSN_FUNCS(blr_auth, 0xFEFFF800, 0xD63F0800) +__AARCH64_INSN_FUNCS(ret, 0xFFFFFC1F, 0xD65F0000) +__AARCH64_INSN_FUNCS(ret_auth, 0xFFFFFBFF, 0xD65F0BFF) +__AARCH64_INSN_FUNCS(eret, 0xFFFFFFFF, 0xD69F03E0) +__AARCH64_INSN_FUNCS(eret_auth, 0xFFFFFBFF, 0xD69F0BFF) +__AARCH64_INSN_FUNCS(mrs, 0xFFF00000, 0xD5300000) +__AARCH64_INSN_FUNCS(msr_imm, 0xFFF8F01F, 0xD500401F) +__AARCH64_INSN_FUNCS(msr_reg, 0xFFF00000, 0xD5100000) +__AARCH64_INSN_FUNCS(dmb, 0xFFFFF0FF, 0xD50330BF) +__AARCH64_INSN_FUNCS(dsb, 0xFFFFF0FF, 0xD503309F) +__AARCH64_INSN_FUNCS(isb, 0xFFFFF0FF, 0xD50330DF) + +#undef __AARCH64_INSN_FUNCS + +bool aarch64_insn_is_steppable_hint(u32 insn); +bool aarch64_insn_is_branch_imm(u32 insn); + +static inline bool aarch64_insn_is_adr_adrp(u32 insn) +{ + return aarch64_insn_is_adr(insn) || aarch64_insn_is_adrp(insn); +} + +static inline bool aarch64_insn_is_barrier(u32 insn) +{ + return aarch64_insn_is_dmb(insn) || aarch64_insn_is_dsb(insn) || + aarch64_insn_is_isb(insn); +} + +static inline bool aarch64_insn_is_store_single(u32 insn) +{ + return aarch64_insn_is_store_imm(insn) || + aarch64_insn_is_store_pre(insn) || + aarch64_insn_is_store_post(insn); +} + +static inline bool aarch64_insn_is_store_pair(u32 insn) +{ + return aarch64_insn_is_stp(insn) || + aarch64_insn_is_stp_pre(insn) || + aarch64_insn_is_stp_post(insn); +} + +static inline bool aarch64_insn_is_load_single(u32 insn) +{ + return aarch64_insn_is_load_imm(insn) || + aarch64_insn_is_load_pre(insn) || + aarch64_insn_is_load_post(insn); +} + +static inline bool aarch64_insn_is_load_pair(u32 insn) +{ + return aarch64_insn_is_ldp(insn) || + aarch64_insn_is_ldp_pre(insn) || + aarch64_insn_is_ldp_post(insn); +} + +enum aarch64_insn_encoding_class aarch64_get_insn_class(u32 insn); +bool aarch64_insn_uses_literal(u32 insn); +bool aarch64_insn_is_branch(u32 insn); +u64 aarch64_insn_decode_immediate(enum aarch64_insn_imm_type type, u32 insn); +u32 aarch64_insn_encode_immediate(enum aarch64_insn_imm_type type, + u32 insn, u64 imm); +u32 aarch64_insn_decode_register(enum aarch64_insn_register_type type, + u32 insn); +u32 aarch64_insn_gen_branch_imm(unsigned long pc, unsigned long addr, + enum aarch64_insn_branch_type type); +u32 aarch64_insn_gen_comp_branch_imm(unsigned long pc, unsigned long addr, + enum aarch64_insn_register reg, + enum aarch64_insn_variant variant, + enum aarch64_insn_branch_type type); +u32 aarch64_insn_gen_cond_branch_imm(unsigned long pc, unsigned long addr, + enum aarch64_insn_condition cond); +u32 aarch64_insn_gen_hint(enum aarch64_insn_hint_cr_op op); +u32 aarch64_insn_gen_nop(void); +u32 aarch64_insn_gen_branch_reg(enum aarch64_insn_register reg, + enum aarch64_insn_branch_type type); +u32 aarch64_insn_gen_load_store_reg(enum aarch64_insn_register reg, + enum aarch64_insn_register base, + enum aarch64_insn_register offset, + enum aarch64_insn_size_type size, + enum aarch64_insn_ldst_type type); +u32 aarch64_insn_gen_load_store_pair(enum aarch64_insn_register reg1, + enum aarch64_insn_register reg2, + enum aarch64_insn_register base, + int offset, + enum aarch64_insn_variant variant, + enum aarch64_insn_ldst_type type); +u32 aarch64_insn_gen_load_store_ex(enum aarch64_insn_register reg, + enum aarch64_insn_register base, + enum aarch64_insn_register state, + enum aarch64_insn_size_type size, + enum aarch64_insn_ldst_type type); +u32 aarch64_insn_gen_ldadd(enum aarch64_insn_register result, + enum aarch64_insn_register address, + enum aarch64_insn_register value, + enum aarch64_insn_size_type size); +u32 aarch64_insn_gen_stadd(enum aarch64_insn_register address, + enum aarch64_insn_register value, + enum aarch64_insn_size_type size); +u32 aarch64_insn_gen_add_sub_imm(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + int imm, enum aarch64_insn_variant variant, + enum aarch64_insn_adsb_type type); +u32 aarch64_insn_gen_adr(unsigned long pc, unsigned long addr, + enum aarch64_insn_register reg, + enum aarch64_insn_adr_type type); +u32 aarch64_insn_gen_bitfield(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + int immr, int imms, + enum aarch64_insn_variant variant, + enum aarch64_insn_bitfield_type type); +u32 aarch64_insn_gen_movewide(enum aarch64_insn_register dst, + int imm, int shift, + enum aarch64_insn_variant variant, + enum aarch64_insn_movewide_type type); +u32 aarch64_insn_gen_add_sub_shifted_reg(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + enum aarch64_insn_register reg, + int shift, + enum aarch64_insn_variant variant, + enum aarch64_insn_adsb_type type); +u32 aarch64_insn_gen_data1(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + enum aarch64_insn_variant variant, + enum aarch64_insn_data1_type type); +u32 aarch64_insn_gen_data2(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + enum aarch64_insn_register reg, + enum aarch64_insn_variant variant, + enum aarch64_insn_data2_type type); +u32 aarch64_insn_gen_data3(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + enum aarch64_insn_register reg1, + enum aarch64_insn_register reg2, + enum aarch64_insn_variant variant, + enum aarch64_insn_data3_type type); +u32 aarch64_insn_gen_logical_shifted_reg(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + enum aarch64_insn_register reg, + int shift, + enum aarch64_insn_variant variant, + enum aarch64_insn_logic_type type); +u32 aarch64_insn_gen_move_reg(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + enum aarch64_insn_variant variant); +u32 aarch64_insn_gen_logical_immediate(enum aarch64_insn_logic_type type, + enum aarch64_insn_variant variant, + enum aarch64_insn_register Rn, + enum aarch64_insn_register Rd, + u64 imm); +u32 aarch64_insn_gen_extr(enum aarch64_insn_variant variant, + enum aarch64_insn_register Rm, + enum aarch64_insn_register Rn, + enum aarch64_insn_register Rd, + u8 lsb); +u32 aarch64_insn_gen_prefetch(enum aarch64_insn_register base, + enum aarch64_insn_prfm_type type, + enum aarch64_insn_prfm_target target, + enum aarch64_insn_prfm_policy policy); +s32 aarch64_get_branch_offset(u32 insn); +u32 aarch64_set_branch_offset(u32 insn, s32 offset); + +s32 aarch64_insn_adrp_get_offset(u32 insn); +u32 aarch64_insn_adrp_set_offset(u32 insn, s32 offset); + +u32 aarch64_insn_extract_system_reg(u32 insn); + + +#endif /* !__ASSEMBLY__ */ +#endif /* __ASM_AARCH64_INSN_H */ diff --git a/tools/arch/arm64/lib/aarch64-insn.c b/tools/arch/arm64/lib/aarch64-insn.c new file mode 100644 index 000000000000..18e0b66a8284 --- /dev/null +++ b/tools/arch/arm64/lib/aarch64-insn.c @@ -0,0 +1,1425 @@ +// SPDX-License-Identifier: GPL-2.0-only + +#include <linux/bitops.h> +#include <linux/bug.h> +#include <linux/printk.h> +#include <linux/sizes.h> +#include <linux/types.h> + +#include <asm/aarch64-insn.h> +#include <asm/errno.h> + +#define AARCH64_INSN_SF_BIT BIT(31) +#define AARCH64_INSN_N_BIT BIT(22) +#define AARCH64_INSN_LSL_12 BIT(22) + +static const int aarch64_insn_encoding_class[] = { + AARCH64_INSN_CLS_UNKNOWN, + AARCH64_INSN_CLS_UNKNOWN, + AARCH64_INSN_CLS_SVE, + AARCH64_INSN_CLS_UNKNOWN, + AARCH64_INSN_CLS_LDST, + AARCH64_INSN_CLS_DP_REG, + AARCH64_INSN_CLS_LDST, + AARCH64_INSN_CLS_DP_FPSIMD, + AARCH64_INSN_CLS_DP_IMM, + AARCH64_INSN_CLS_DP_IMM, + AARCH64_INSN_CLS_BR_SYS, + AARCH64_INSN_CLS_BR_SYS, + AARCH64_INSN_CLS_LDST, + AARCH64_INSN_CLS_DP_REG, + AARCH64_INSN_CLS_LDST, + AARCH64_INSN_CLS_DP_FPSIMD, +}; + +enum aarch64_insn_encoding_class __kprobes aarch64_get_insn_class(u32 insn) +{ + return aarch64_insn_encoding_class[(insn >> 25) & 0xf]; +} + +bool __kprobes aarch64_insn_is_steppable_hint(u32 insn) +{ + if (!aarch64_insn_is_hint(insn)) + return false; + + switch (insn & 0xFE0) { + case AARCH64_INSN_HINT_XPACLRI: + case AARCH64_INSN_HINT_PACIA_1716: + case AARCH64_INSN_HINT_PACIB_1716: + case AARCH64_INSN_HINT_PACIAZ: + case AARCH64_INSN_HINT_PACIASP: + case AARCH64_INSN_HINT_PACIBZ: + case AARCH64_INSN_HINT_PACIBSP: + case AARCH64_INSN_HINT_BTI: + case AARCH64_INSN_HINT_BTIC: + case AARCH64_INSN_HINT_BTIJ: + case AARCH64_INSN_HINT_BTIJC: + case AARCH64_INSN_HINT_NOP: + return true; + default: + return false; + } +} + +bool aarch64_insn_is_branch_imm(u32 insn) +{ + return (aarch64_insn_is_b(insn) || aarch64_insn_is_bl(insn) || + aarch64_insn_is_tbz(insn) || aarch64_insn_is_tbnz(insn) || + aarch64_insn_is_cbz(insn) || aarch64_insn_is_cbnz(insn) || + aarch64_insn_is_bcond(insn)); +} + +bool __kprobes aarch64_insn_uses_literal(u32 insn) +{ + /* ldr/ldrsw (literal), prfm */ + + return aarch64_insn_is_ldr_lit(insn) || + aarch64_insn_is_ldrsw_lit(insn) || + aarch64_insn_is_adr_adrp(insn) || + aarch64_insn_is_prfm_lit(insn); +} + +bool __kprobes aarch64_insn_is_branch(u32 insn) +{ + /* b, bl, cb*, tb*, ret*, b.cond, br*, blr* */ + + return aarch64_insn_is_b(insn) || + aarch64_insn_is_bl(insn) || + aarch64_insn_is_cbz(insn) || + aarch64_insn_is_cbnz(insn) || + aarch64_insn_is_tbz(insn) || + aarch64_insn_is_tbnz(insn) || + aarch64_insn_is_ret(insn) || + aarch64_insn_is_ret_auth(insn) || + aarch64_insn_is_br(insn) || + aarch64_insn_is_br_auth(insn) || + aarch64_insn_is_blr(insn) || + aarch64_insn_is_blr_auth(insn) || + aarch64_insn_is_bcond(insn); +} + +static int __kprobes aarch64_get_imm_shift_mask(enum aarch64_insn_imm_type type, + u32 *maskp, int *shiftp) +{ + u32 mask; + int shift; + + switch (type) { + case AARCH64_INSN_IMM_26: + mask = BIT(26) - 1; + shift = 0; + break; + case AARCH64_INSN_IMM_19: + mask = BIT(19) - 1; + shift = 5; + break; + case AARCH64_INSN_IMM_16: + mask = BIT(16) - 1; + shift = 5; + break; + case AARCH64_INSN_IMM_14: + mask = BIT(14) - 1; + shift = 5; + break; + case AARCH64_INSN_IMM_12: + mask = BIT(12) - 1; + shift = 10; + break; + case AARCH64_INSN_IMM_9: + mask = BIT(9) - 1; + shift = 12; + break; + case AARCH64_INSN_IMM_7: + mask = BIT(7) - 1; + shift = 15; + break; + case AARCH64_INSN_IMM_6: + case AARCH64_INSN_IMM_S: + mask = BIT(6) - 1; + shift = 10; + break; + case AARCH64_INSN_IMM_R: + mask = BIT(6) - 1; + shift = 16; + break; + case AARCH64_INSN_IMM_N: + mask = 1; + shift = 22; + break; + default: + return -EINVAL; + } + + *maskp = mask; + *shiftp = shift; + + return 0; +} + +#define ADR_IMM_HILOSPLIT 2 +#define ADR_IMM_SIZE SZ_2M +#define ADR_IMM_LOMASK ((1 << ADR_IMM_HILOSPLIT) - 1) +#define ADR_IMM_HIMASK ((ADR_IMM_SIZE >> ADR_IMM_HILOSPLIT) - 1) +#define ADR_IMM_LOSHIFT 29 +#define ADR_IMM_HISHIFT 5 + +u64 aarch64_insn_decode_immediate(enum aarch64_insn_imm_type type, u32 insn) +{ + u32 immlo, immhi, mask; + int shift; + + switch (type) { + case AARCH64_INSN_IMM_ADR: + shift = 0; + immlo = (insn >> ADR_IMM_LOSHIFT) & ADR_IMM_LOMASK; + immhi = (insn >> ADR_IMM_HISHIFT) & ADR_IMM_HIMASK; + insn = (immhi << ADR_IMM_HILOSPLIT) | immlo; + mask = ADR_IMM_SIZE - 1; + break; + default: + if (aarch64_get_imm_shift_mask(type, &mask, &shift) < 0) { + pr_err("aarch64_insn_decode_immediate: unknown immediate encoding %d\n", + type); + return 0; + } + } + + return (insn >> shift) & mask; +} + +u32 __kprobes aarch64_insn_encode_immediate(enum aarch64_insn_imm_type type, + u32 insn, u64 imm) +{ + u32 immlo, immhi, mask; + int shift; + + if (insn == AARCH64_BREAK_FAULT) + return AARCH64_BREAK_FAULT; + + switch (type) { + case AARCH64_INSN_IMM_ADR: + shift = 0; + immlo = (imm & ADR_IMM_LOMASK) << ADR_IMM_LOSHIFT; + imm >>= ADR_IMM_HILOSPLIT; + immhi = (imm & ADR_IMM_HIMASK) << ADR_IMM_HISHIFT; + imm = immlo | immhi; + mask = ((ADR_IMM_LOMASK << ADR_IMM_LOSHIFT) | + (ADR_IMM_HIMASK << ADR_IMM_HISHIFT)); + break; + default: + if (aarch64_get_imm_shift_mask(type, &mask, &shift) < 0) { + pr_err("aarch64_insn_encode_immediate: unknown immediate encoding %d\n", + type); + return AARCH64_BREAK_FAULT; + } + } + + /* Update the immediate field. */ + insn &= ~(mask << shift); + insn |= (imm & mask) << shift; + + return insn; +} + +u32 aarch64_insn_decode_register(enum aarch64_insn_register_type type, + u32 insn) +{ + int shift; + + switch (type) { + case AARCH64_INSN_REGTYPE_RT: + case AARCH64_INSN_REGTYPE_RD: + shift = 0; + break; + case AARCH64_INSN_REGTYPE_RN: + shift = 5; + break; + case AARCH64_INSN_REGTYPE_RT2: + case AARCH64_INSN_REGTYPE_RA: + shift = 10; + break; + case AARCH64_INSN_REGTYPE_RM: + shift = 16; + break; + default: + pr_err("%s: unknown register type encoding %d\n", __func__, + type); + return 0; + } + + return (insn >> shift) & GENMASK(4, 0); +} + +static u32 aarch64_insn_encode_register(enum aarch64_insn_register_type type, + u32 insn, + enum aarch64_insn_register reg) +{ + int shift; + + if (insn == AARCH64_BREAK_FAULT) + return AARCH64_BREAK_FAULT; + + if (reg < AARCH64_INSN_REG_0 || reg > AARCH64_INSN_REG_SP) { + pr_err("%s: unknown register encoding %d\n", __func__, reg); + return AARCH64_BREAK_FAULT; + } + + switch (type) { + case AARCH64_INSN_REGTYPE_RT: + case AARCH64_INSN_REGTYPE_RD: + shift = 0; + break; + case AARCH64_INSN_REGTYPE_RN: + shift = 5; + break; + case AARCH64_INSN_REGTYPE_RT2: + case AARCH64_INSN_REGTYPE_RA: + shift = 10; + break; + case AARCH64_INSN_REGTYPE_RM: + case AARCH64_INSN_REGTYPE_RS: + shift = 16; + break; + default: + pr_err("%s: unknown register type encoding %d\n", __func__, + type); + return AARCH64_BREAK_FAULT; + } + + insn &= ~(GENMASK(4, 0) << shift); + insn |= reg << shift; + + return insn; +} + +static u32 aarch64_insn_encode_ldst_size(enum aarch64_insn_size_type type, + u32 insn) +{ + u32 size; + + switch (type) { + case AARCH64_INSN_SIZE_8: + size = 0; + break; + case AARCH64_INSN_SIZE_16: + size = 1; + break; + case AARCH64_INSN_SIZE_32: + size = 2; + break; + case AARCH64_INSN_SIZE_64: + size = 3; + break; + default: + pr_err("%s: unknown size encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + insn &= ~GENMASK(31, 30); + insn |= size << 30; + + return insn; +} + +static inline long branch_imm_common(unsigned long pc, unsigned long addr, + long range) +{ + long offset; + + if ((pc & 0x3) || (addr & 0x3)) { + pr_err("%s: A64 instructions must be word aligned\n", __func__); + return range; + } + + offset = ((long)addr - (long)pc); + + if (offset < -range || offset >= range) { + pr_err("%s: offset out of range\n", __func__); + return range; + } + + return offset; +} + +u32 __kprobes aarch64_insn_gen_branch_imm(unsigned long pc, unsigned long addr, + enum aarch64_insn_branch_type type) +{ + u32 insn; + long offset; + + /* + * B/BL support [-128M, 128M) offset + * ARM64 virtual address arrangement guarantees all kernel and module + * texts are within +/-128M. + */ + offset = branch_imm_common(pc, addr, SZ_128M); + if (offset >= SZ_128M) + return AARCH64_BREAK_FAULT; + + switch (type) { + case AARCH64_INSN_BRANCH_LINK: + insn = aarch64_insn_get_bl_value(); + break; + case AARCH64_INSN_BRANCH_NOLINK: + insn = aarch64_insn_get_b_value(); + break; + default: + pr_err("%s: unknown branch encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_26, insn, + offset >> 2); +} + +u32 aarch64_insn_gen_comp_branch_imm(unsigned long pc, unsigned long addr, + enum aarch64_insn_register reg, + enum aarch64_insn_variant variant, + enum aarch64_insn_branch_type type) +{ + u32 insn; + long offset; + + offset = branch_imm_common(pc, addr, SZ_1M); + if (offset >= SZ_1M) + return AARCH64_BREAK_FAULT; + + switch (type) { + case AARCH64_INSN_BRANCH_COMP_ZERO: + insn = aarch64_insn_get_cbz_value(); + break; + case AARCH64_INSN_BRANCH_COMP_NONZERO: + insn = aarch64_insn_get_cbnz_value(); + break; + default: + pr_err("%s: unknown branch encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + switch (variant) { + case AARCH64_INSN_VARIANT_32BIT: + break; + case AARCH64_INSN_VARIANT_64BIT: + insn |= AARCH64_INSN_SF_BIT; + break; + default: + pr_err("%s: unknown variant encoding %d\n", __func__, variant); + return AARCH64_BREAK_FAULT; + } + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RT, insn, reg); + + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_19, insn, + offset >> 2); +} + +u32 aarch64_insn_gen_cond_branch_imm(unsigned long pc, unsigned long addr, + enum aarch64_insn_condition cond) +{ + u32 insn; + long offset; + + offset = branch_imm_common(pc, addr, SZ_1M); + + insn = aarch64_insn_get_bcond_value(); + + if (cond < AARCH64_INSN_COND_EQ || cond > AARCH64_INSN_COND_AL) { + pr_err("%s: unknown condition encoding %d\n", __func__, cond); + return AARCH64_BREAK_FAULT; + } + insn |= cond; + + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_19, insn, + offset >> 2); +} + +u32 __kprobes aarch64_insn_gen_hint(enum aarch64_insn_hint_cr_op op) +{ + return aarch64_insn_get_hint_value() | op; +} + +u32 __kprobes aarch64_insn_gen_nop(void) +{ + return aarch64_insn_gen_hint(AARCH64_INSN_HINT_NOP); +} + +u32 aarch64_insn_gen_branch_reg(enum aarch64_insn_register reg, + enum aarch64_insn_branch_type type) +{ + u32 insn; + + switch (type) { + case AARCH64_INSN_BRANCH_NOLINK: + insn = aarch64_insn_get_br_value(); + break; + case AARCH64_INSN_BRANCH_LINK: + insn = aarch64_insn_get_blr_value(); + break; + case AARCH64_INSN_BRANCH_RETURN: + insn = aarch64_insn_get_ret_value(); + break; + default: + pr_err("%s: unknown branch encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + return aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, reg); +} + +u32 aarch64_insn_gen_load_store_reg(enum aarch64_insn_register reg, + enum aarch64_insn_register base, + enum aarch64_insn_register offset, + enum aarch64_insn_size_type size, + enum aarch64_insn_ldst_type type) +{ + u32 insn; + + switch (type) { + case AARCH64_INSN_LDST_LOAD_REG_OFFSET: + insn = aarch64_insn_get_ldr_reg_value(); + break; + case AARCH64_INSN_LDST_STORE_REG_OFFSET: + insn = aarch64_insn_get_str_reg_value(); + break; + default: + pr_err("%s: unknown load/store encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + insn = aarch64_insn_encode_ldst_size(size, insn); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RT, insn, reg); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, + base); + + return aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RM, insn, + offset); +} + +u32 aarch64_insn_gen_load_store_pair(enum aarch64_insn_register reg1, + enum aarch64_insn_register reg2, + enum aarch64_insn_register base, + int offset, + enum aarch64_insn_variant variant, + enum aarch64_insn_ldst_type type) +{ + u32 insn; + int shift; + + switch (type) { + case AARCH64_INSN_LDST_LOAD_PAIR_PRE_INDEX: + insn = aarch64_insn_get_ldp_pre_value(); + break; + case AARCH64_INSN_LDST_STORE_PAIR_PRE_INDEX: + insn = aarch64_insn_get_stp_pre_value(); + break; + case AARCH64_INSN_LDST_LOAD_PAIR_POST_INDEX: + insn = aarch64_insn_get_ldp_post_value(); + break; + case AARCH64_INSN_LDST_STORE_PAIR_POST_INDEX: + insn = aarch64_insn_get_stp_post_value(); + break; + default: + pr_err("%s: unknown load/store encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + switch (variant) { + case AARCH64_INSN_VARIANT_32BIT: + if ((offset & 0x3) || (offset < -256) || (offset > 252)) { + pr_err("%s: offset must be multiples of 4 in the range of [-256, 252] %d\n", + __func__, offset); + return AARCH64_BREAK_FAULT; + } + shift = 2; + break; + case AARCH64_INSN_VARIANT_64BIT: + if ((offset & 0x7) || (offset < -512) || (offset > 504)) { + pr_err("%s: offset must be multiples of 8 in the range of [-512, 504] %d\n", + __func__, offset); + return AARCH64_BREAK_FAULT; + } + shift = 3; + insn |= AARCH64_INSN_SF_BIT; + break; + default: + pr_err("%s: unknown variant encoding %d\n", __func__, variant); + return AARCH64_BREAK_FAULT; + } + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RT, insn, + reg1); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RT2, insn, + reg2); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, + base); + + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_7, insn, + offset >> shift); +} + +u32 aarch64_insn_gen_load_store_ex(enum aarch64_insn_register reg, + enum aarch64_insn_register base, + enum aarch64_insn_register state, + enum aarch64_insn_size_type size, + enum aarch64_insn_ldst_type type) +{ + u32 insn; + + switch (type) { + case AARCH64_INSN_LDST_LOAD_EX: + insn = aarch64_insn_get_load_ex_value(); + break; + case AARCH64_INSN_LDST_STORE_EX: + insn = aarch64_insn_get_store_ex_value(); + break; + default: + pr_err("%s: unknown load/store exclusive encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + insn = aarch64_insn_encode_ldst_size(size, insn); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RT, insn, + reg); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, + base); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RT2, insn, + AARCH64_INSN_REG_ZR); + + return aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RS, insn, + state); +} + +u32 aarch64_insn_gen_ldadd(enum aarch64_insn_register result, + enum aarch64_insn_register address, + enum aarch64_insn_register value, + enum aarch64_insn_size_type size) +{ + u32 insn = aarch64_insn_get_ldadd_value(); + + switch (size) { + case AARCH64_INSN_SIZE_32: + case AARCH64_INSN_SIZE_64: + break; + default: + pr_err("%s: unimplemented size encoding %d\n", __func__, size); + return AARCH64_BREAK_FAULT; + } + + insn = aarch64_insn_encode_ldst_size(size, insn); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RT, insn, + result); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, + address); + + return aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RS, insn, + value); +} + +u32 aarch64_insn_gen_stadd(enum aarch64_insn_register address, + enum aarch64_insn_register value, + enum aarch64_insn_size_type size) +{ + /* + * STADD is simply encoded as an alias for LDADD with XZR as + * the destination register. + */ + return aarch64_insn_gen_ldadd(AARCH64_INSN_REG_ZR, address, + value, size); +} + +static u32 aarch64_insn_encode_prfm_imm(enum aarch64_insn_prfm_type type, + enum aarch64_insn_prfm_target target, + enum aarch64_insn_prfm_policy policy, + u32 insn) +{ + u32 imm_type = 0, imm_target = 0, imm_policy = 0; + + switch (type) { + case AARCH64_INSN_PRFM_TYPE_PLD: + break; + case AARCH64_INSN_PRFM_TYPE_PLI: + imm_type = BIT(0); + break; + case AARCH64_INSN_PRFM_TYPE_PST: + imm_type = BIT(1); + break; + default: + pr_err("%s: unknown prfm type encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + switch (target) { + case AARCH64_INSN_PRFM_TARGET_L1: + break; + case AARCH64_INSN_PRFM_TARGET_L2: + imm_target = BIT(0); + break; + case AARCH64_INSN_PRFM_TARGET_L3: + imm_target = BIT(1); + break; + default: + pr_err("%s: unknown prfm target encoding %d\n", __func__, target); + return AARCH64_BREAK_FAULT; + } + + switch (policy) { + case AARCH64_INSN_PRFM_POLICY_KEEP: + break; + case AARCH64_INSN_PRFM_POLICY_STRM: + imm_policy = BIT(0); + break; + default: + pr_err("%s: unknown prfm policy encoding %d\n", __func__, policy); + return AARCH64_BREAK_FAULT; + } + + /* In this case, imm5 is encoded into Rt field. */ + insn &= ~GENMASK(4, 0); + insn |= imm_policy | (imm_target << 1) | (imm_type << 3); + + return insn; +} + +u32 aarch64_insn_gen_prefetch(enum aarch64_insn_register base, + enum aarch64_insn_prfm_type type, + enum aarch64_insn_prfm_target target, + enum aarch64_insn_prfm_policy policy) +{ + u32 insn = aarch64_insn_get_prfm_value(); + + insn = aarch64_insn_encode_ldst_size(AARCH64_INSN_SIZE_64, insn); + + insn = aarch64_insn_encode_prfm_imm(type, target, policy, insn); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, + base); + + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_12, insn, 0); +} + +u32 aarch64_insn_gen_add_sub_imm(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + int imm, enum aarch64_insn_variant variant, + enum aarch64_insn_adsb_type type) +{ + u32 insn; + + switch (type) { + case AARCH64_INSN_ADSB_ADD: + insn = aarch64_insn_get_add_imm_value(); + break; + case AARCH64_INSN_ADSB_SUB: + insn = aarch64_insn_get_sub_imm_value(); + break; + case AARCH64_INSN_ADSB_ADD_SETFLAGS: + insn = aarch64_insn_get_adds_imm_value(); + break; + case AARCH64_INSN_ADSB_SUB_SETFLAGS: + insn = aarch64_insn_get_subs_imm_value(); + break; + default: + pr_err("%s: unknown add/sub encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + switch (variant) { + case AARCH64_INSN_VARIANT_32BIT: + break; + case AARCH64_INSN_VARIANT_64BIT: + insn |= AARCH64_INSN_SF_BIT; + break; + default: + pr_err("%s: unknown variant encoding %d\n", __func__, variant); + return AARCH64_BREAK_FAULT; + } + + /* We can't encode more than a 24bit value (12bit + 12bit shift) */ + if (imm & ~(BIT(24) - 1)) + goto out; + + /* If we have something in the top 12 bits... */ + if (imm & ~(SZ_4K - 1)) { + /* ... and in the low 12 bits -> error */ + if (imm & (SZ_4K - 1)) + goto out; + + imm >>= 12; + insn |= AARCH64_INSN_LSL_12; + } + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RD, insn, dst); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, src); + + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_12, insn, imm); + +out: + pr_err("%s: invalid immediate encoding %d\n", __func__, imm); + return AARCH64_BREAK_FAULT; +} + +u32 aarch64_insn_gen_bitfield(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + int immr, int imms, + enum aarch64_insn_variant variant, + enum aarch64_insn_bitfield_type type) +{ + u32 insn; + u32 mask; + + switch (type) { + case AARCH64_INSN_BITFIELD_MOVE: + insn = aarch64_insn_get_bfm_value(); + break; + case AARCH64_INSN_BITFIELD_MOVE_UNSIGNED: + insn = aarch64_insn_get_ubfm_value(); + break; + case AARCH64_INSN_BITFIELD_MOVE_SIGNED: + insn = aarch64_insn_get_sbfm_value(); + break; + default: + pr_err("%s: unknown bitfield encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + switch (variant) { + case AARCH64_INSN_VARIANT_32BIT: + mask = GENMASK(4, 0); + break; + case AARCH64_INSN_VARIANT_64BIT: + insn |= AARCH64_INSN_SF_BIT | AARCH64_INSN_N_BIT; + mask = GENMASK(5, 0); + break; + default: + pr_err("%s: unknown variant encoding %d\n", __func__, variant); + return AARCH64_BREAK_FAULT; + } + + if (immr & ~mask) { + pr_err("%s: invalid immr encoding %d\n", __func__, immr); + return AARCH64_BREAK_FAULT; + } + if (imms & ~mask) { + pr_err("%s: invalid imms encoding %d\n", __func__, imms); + return AARCH64_BREAK_FAULT; + } + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RD, insn, dst); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, src); + + insn = aarch64_insn_encode_immediate(AARCH64_INSN_IMM_R, insn, immr); + + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_S, insn, imms); +} + +u32 aarch64_insn_gen_movewide(enum aarch64_insn_register dst, + int imm, int shift, + enum aarch64_insn_variant variant, + enum aarch64_insn_movewide_type type) +{ + u32 insn; + + switch (type) { + case AARCH64_INSN_MOVEWIDE_ZERO: + insn = aarch64_insn_get_movz_value(); + break; + case AARCH64_INSN_MOVEWIDE_KEEP: + insn = aarch64_insn_get_movk_value(); + break; + case AARCH64_INSN_MOVEWIDE_INVERSE: + insn = aarch64_insn_get_movn_value(); + break; + default: + pr_err("%s: unknown movewide encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + if (imm & ~(SZ_64K - 1)) { + pr_err("%s: invalid immediate encoding %d\n", __func__, imm); + return AARCH64_BREAK_FAULT; + } + + switch (variant) { + case AARCH64_INSN_VARIANT_32BIT: + if (shift != 0 && shift != 16) { + pr_err("%s: invalid shift encoding %d\n", __func__, + shift); + return AARCH64_BREAK_FAULT; + } + break; + case AARCH64_INSN_VARIANT_64BIT: + insn |= AARCH64_INSN_SF_BIT; + if (shift != 0 && shift != 16 && shift != 32 && shift != 48) { + pr_err("%s: invalid shift encoding %d\n", __func__, + shift); + return AARCH64_BREAK_FAULT; + } + break; + default: + pr_err("%s: unknown variant encoding %d\n", __func__, variant); + return AARCH64_BREAK_FAULT; + } + + insn |= (shift >> 4) << 21; + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RD, insn, dst); + + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_16, insn, imm); +} + +u32 aarch64_insn_gen_add_sub_shifted_reg(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + enum aarch64_insn_register reg, + int shift, + enum aarch64_insn_variant variant, + enum aarch64_insn_adsb_type type) +{ + u32 insn; + + switch (type) { + case AARCH64_INSN_ADSB_ADD: + insn = aarch64_insn_get_add_value(); + break; + case AARCH64_INSN_ADSB_SUB: + insn = aarch64_insn_get_sub_value(); + break; + case AARCH64_INSN_ADSB_ADD_SETFLAGS: + insn = aarch64_insn_get_adds_value(); + break; + case AARCH64_INSN_ADSB_SUB_SETFLAGS: + insn = aarch64_insn_get_subs_value(); + break; + default: + pr_err("%s: unknown add/sub encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + switch (variant) { + case AARCH64_INSN_VARIANT_32BIT: + if (shift & ~(SZ_32 - 1)) { + pr_err("%s: invalid shift encoding %d\n", __func__, + shift); + return AARCH64_BREAK_FAULT; + } + break; + case AARCH64_INSN_VARIANT_64BIT: + insn |= AARCH64_INSN_SF_BIT; + if (shift & ~(SZ_64 - 1)) { + pr_err("%s: invalid shift encoding %d\n", __func__, + shift); + return AARCH64_BREAK_FAULT; + } + break; + default: + pr_err("%s: unknown variant encoding %d\n", __func__, variant); + return AARCH64_BREAK_FAULT; + } + + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RD, insn, dst); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, src); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RM, insn, reg); + + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_6, insn, shift); +} + +u32 aarch64_insn_gen_data1(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + enum aarch64_insn_variant variant, + enum aarch64_insn_data1_type type) +{ + u32 insn; + + switch (type) { + case AARCH64_INSN_DATA1_REVERSE_16: + insn = aarch64_insn_get_rev16_value(); + break; + case AARCH64_INSN_DATA1_REVERSE_32: + insn = aarch64_insn_get_rev32_value(); + break; + case AARCH64_INSN_DATA1_REVERSE_64: + if (variant != AARCH64_INSN_VARIANT_64BIT) { + pr_err("%s: invalid variant for reverse64 %d\n", + __func__, variant); + return AARCH64_BREAK_FAULT; + } + insn = aarch64_insn_get_rev64_value(); + break; + default: + pr_err("%s: unknown data1 encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + switch (variant) { + case AARCH64_INSN_VARIANT_32BIT: + break; + case AARCH64_INSN_VARIANT_64BIT: + insn |= AARCH64_INSN_SF_BIT; + break; + default: + pr_err("%s: unknown variant encoding %d\n", __func__, variant); + return AARCH64_BREAK_FAULT; + } + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RD, insn, dst); + + return aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, src); +} + +u32 aarch64_insn_gen_data2(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + enum aarch64_insn_register reg, + enum aarch64_insn_variant variant, + enum aarch64_insn_data2_type type) +{ + u32 insn; + + switch (type) { + case AARCH64_INSN_DATA2_UDIV: + insn = aarch64_insn_get_udiv_value(); + break; + case AARCH64_INSN_DATA2_SDIV: + insn = aarch64_insn_get_sdiv_value(); + break; + case AARCH64_INSN_DATA2_LSLV: + insn = aarch64_insn_get_lslv_value(); + break; + case AARCH64_INSN_DATA2_LSRV: + insn = aarch64_insn_get_lsrv_value(); + break; + case AARCH64_INSN_DATA2_ASRV: + insn = aarch64_insn_get_asrv_value(); + break; + case AARCH64_INSN_DATA2_RORV: + insn = aarch64_insn_get_rorv_value(); + break; + default: + pr_err("%s: unknown data2 encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + switch (variant) { + case AARCH64_INSN_VARIANT_32BIT: + break; + case AARCH64_INSN_VARIANT_64BIT: + insn |= AARCH64_INSN_SF_BIT; + break; + default: + pr_err("%s: unknown variant encoding %d\n", __func__, variant); + return AARCH64_BREAK_FAULT; + } + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RD, insn, dst); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, src); + + return aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RM, insn, reg); +} + +u32 aarch64_insn_gen_data3(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + enum aarch64_insn_register reg1, + enum aarch64_insn_register reg2, + enum aarch64_insn_variant variant, + enum aarch64_insn_data3_type type) +{ + u32 insn; + + switch (type) { + case AARCH64_INSN_DATA3_MADD: + insn = aarch64_insn_get_madd_value(); + break; + case AARCH64_INSN_DATA3_MSUB: + insn = aarch64_insn_get_msub_value(); + break; + default: + pr_err("%s: unknown data3 encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + switch (variant) { + case AARCH64_INSN_VARIANT_32BIT: + break; + case AARCH64_INSN_VARIANT_64BIT: + insn |= AARCH64_INSN_SF_BIT; + break; + default: + pr_err("%s: unknown variant encoding %d\n", __func__, variant); + return AARCH64_BREAK_FAULT; + } + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RD, insn, dst); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RA, insn, src); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, + reg1); + + return aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RM, insn, + reg2); +} + +u32 aarch64_insn_gen_logical_shifted_reg(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + enum aarch64_insn_register reg, + int shift, + enum aarch64_insn_variant variant, + enum aarch64_insn_logic_type type) +{ + u32 insn; + + switch (type) { + case AARCH64_INSN_LOGIC_AND: + insn = aarch64_insn_get_and_value(); + break; + case AARCH64_INSN_LOGIC_BIC: + insn = aarch64_insn_get_bic_value(); + break; + case AARCH64_INSN_LOGIC_ORR: + insn = aarch64_insn_get_orr_value(); + break; + case AARCH64_INSN_LOGIC_ORN: + insn = aarch64_insn_get_orn_value(); + break; + case AARCH64_INSN_LOGIC_EOR: + insn = aarch64_insn_get_eor_value(); + break; + case AARCH64_INSN_LOGIC_EON: + insn = aarch64_insn_get_eon_value(); + break; + case AARCH64_INSN_LOGIC_AND_SETFLAGS: + insn = aarch64_insn_get_ands_value(); + break; + case AARCH64_INSN_LOGIC_BIC_SETFLAGS: + insn = aarch64_insn_get_bics_value(); + break; + default: + pr_err("%s: unknown logical encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + switch (variant) { + case AARCH64_INSN_VARIANT_32BIT: + if (shift & ~(SZ_32 - 1)) { + pr_err("%s: invalid shift encoding %d\n", __func__, + shift); + return AARCH64_BREAK_FAULT; + } + break; + case AARCH64_INSN_VARIANT_64BIT: + insn |= AARCH64_INSN_SF_BIT; + if (shift & ~(SZ_64 - 1)) { + pr_err("%s: invalid shift encoding %d\n", __func__, + shift); + return AARCH64_BREAK_FAULT; + } + break; + default: + pr_err("%s: unknown variant encoding %d\n", __func__, variant); + return AARCH64_BREAK_FAULT; + } + + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RD, insn, dst); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, src); + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RM, insn, reg); + + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_6, insn, shift); +} + +/* + * MOV (register) is architecturally an alias of ORR (shifted register) where + * MOV <*d>, <*m> is equivalent to ORR <*d>, <*ZR>, <*m> + */ +u32 aarch64_insn_gen_move_reg(enum aarch64_insn_register dst, + enum aarch64_insn_register src, + enum aarch64_insn_variant variant) +{ + return aarch64_insn_gen_logical_shifted_reg(dst, AARCH64_INSN_REG_ZR, + src, 0, variant, + AARCH64_INSN_LOGIC_ORR); +} + +u32 aarch64_insn_gen_adr(unsigned long pc, unsigned long addr, + enum aarch64_insn_register reg, + enum aarch64_insn_adr_type type) +{ + u32 insn; + s32 offset; + + switch (type) { + case AARCH64_INSN_ADR_TYPE_ADR: + insn = aarch64_insn_get_adr_value(); + offset = addr - pc; + break; + case AARCH64_INSN_ADR_TYPE_ADRP: + insn = aarch64_insn_get_adrp_value(); + offset = (addr - ALIGN_DOWN(pc, SZ_4K)) >> 12; + break; + default: + pr_err("%s: unknown adr encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + if (offset < -SZ_1M || offset >= SZ_1M) + return AARCH64_BREAK_FAULT; + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RD, insn, reg); + + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_ADR, insn, offset); +} + +/* + * Decode the imm field of a branch, and return the byte offset as a + * signed value (so it can be used when computing a new branch + * target). + */ +s32 aarch64_get_branch_offset(u32 insn) +{ + s32 imm; + + if (aarch64_insn_is_b(insn) || aarch64_insn_is_bl(insn)) { + imm = aarch64_insn_decode_immediate(AARCH64_INSN_IMM_26, insn); + return (imm << 6) >> 4; + } + + if (aarch64_insn_is_cbz(insn) || aarch64_insn_is_cbnz(insn) || + aarch64_insn_is_bcond(insn)) { + imm = aarch64_insn_decode_immediate(AARCH64_INSN_IMM_19, insn); + return (imm << 13) >> 11; + } + + if (aarch64_insn_is_tbz(insn) || aarch64_insn_is_tbnz(insn)) { + imm = aarch64_insn_decode_immediate(AARCH64_INSN_IMM_14, insn); + return (imm << 18) >> 16; + } + + /* Unhandled instruction */ + BUG(); +} + +/* + * Encode the displacement of a branch in the imm field and return the + * updated instruction. + */ +u32 aarch64_set_branch_offset(u32 insn, s32 offset) +{ + if (aarch64_insn_is_b(insn) || aarch64_insn_is_bl(insn)) + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_26, insn, + offset >> 2); + + if (aarch64_insn_is_cbz(insn) || aarch64_insn_is_cbnz(insn) || + aarch64_insn_is_bcond(insn)) + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_19, insn, + offset >> 2); + + if (aarch64_insn_is_tbz(insn) || aarch64_insn_is_tbnz(insn)) + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_14, insn, + offset >> 2); + + /* Unhandled instruction */ + BUG(); +} + +s32 aarch64_insn_adrp_get_offset(u32 insn) +{ + BUG_ON(!aarch64_insn_is_adrp(insn)); + return aarch64_insn_decode_immediate(AARCH64_INSN_IMM_ADR, insn) << 12; +} + +u32 aarch64_insn_adrp_set_offset(u32 insn, s32 offset) +{ + BUG_ON(!aarch64_insn_is_adrp(insn)); + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_ADR, insn, + offset >> 12); +} + +/* + * Extract the Op/CR data from a msr/mrs instruction. + */ +u32 aarch64_insn_extract_system_reg(u32 insn) +{ + return (insn & 0x1FFFE0) >> 5; +} + +static bool range_of_ones(u64 val) +{ + /* Doesn't handle full ones or full zeroes */ + u64 sval = val >> __ffs64(val); + + /* One of Sean Eron Anderson's bithack tricks */ + return ((sval + 1) & (sval)) == 0; +} + +static u32 aarch64_encode_immediate(u64 imm, + enum aarch64_insn_variant variant, + u32 insn) +{ + unsigned int immr, imms, n, ones, ror, esz, tmp; + u64 mask; + + switch (variant) { + case AARCH64_INSN_VARIANT_32BIT: + esz = 32; + break; + case AARCH64_INSN_VARIANT_64BIT: + insn |= AARCH64_INSN_SF_BIT; + esz = 64; + break; + default: + pr_err("%s: unknown variant encoding %d\n", __func__, variant); + return AARCH64_BREAK_FAULT; + } + + mask = GENMASK(esz - 1, 0); + + /* Can't encode full zeroes, full ones, or value wider than the mask */ + if (!imm || imm == mask || imm & ~mask) + return AARCH64_BREAK_FAULT; + + /* + * Inverse of Replicate(). Try to spot a repeating pattern + * with a pow2 stride. + */ + for (tmp = esz / 2; tmp >= 2; tmp /= 2) { + u64 emask = BIT(tmp) - 1; + + if ((imm & emask) != ((imm >> tmp) & emask)) + break; + + esz = tmp; + mask = emask; + } + + /* N is only set if we're encoding a 64bit value */ + n = esz == 64; + + /* Trim imm to the element size */ + imm &= mask; + + /* That's how many ones we need to encode */ + ones = hweight64(imm); + + /* + * imms is set to (ones - 1), prefixed with a string of ones + * and a zero if they fit. Cap it to 6 bits. + */ + imms = ones - 1; + imms |= 0xf << ffs(esz); + imms &= BIT(6) - 1; + + /* Compute the rotation */ + if (range_of_ones(imm)) { + /* + * Pattern: 0..01..10..0 + * + * Compute how many rotate we need to align it right + */ + ror = __ffs64(imm); + } else { + /* + * Pattern: 0..01..10..01..1 + * + * Fill the unused top bits with ones, and check if + * the result is a valid immediate (all ones with a + * contiguous ranges of zeroes). + */ + imm |= ~mask; + if (!range_of_ones(~imm)) + return AARCH64_BREAK_FAULT; + + /* + * Compute the rotation to get a continuous set of + * ones, with the first bit set at position 0 + */ + ror = fls(~imm); + } + + /* + * immr is the number of bits we need to rotate back to the + * original set of ones. Note that this is relative to the + * element size... + */ + immr = (esz - ror) % esz; + + insn = aarch64_insn_encode_immediate(AARCH64_INSN_IMM_N, insn, n); + insn = aarch64_insn_encode_immediate(AARCH64_INSN_IMM_R, insn, immr); + return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_S, insn, imms); +} + +u32 aarch64_insn_gen_logical_immediate(enum aarch64_insn_logic_type type, + enum aarch64_insn_variant variant, + enum aarch64_insn_register Rn, + enum aarch64_insn_register Rd, + u64 imm) +{ + u32 insn; + + switch (type) { + case AARCH64_INSN_LOGIC_AND: + insn = aarch64_insn_get_and_imm_value(); + break; + case AARCH64_INSN_LOGIC_ORR: + insn = aarch64_insn_get_orr_imm_value(); + break; + case AARCH64_INSN_LOGIC_EOR: + insn = aarch64_insn_get_eor_imm_value(); + break; + case AARCH64_INSN_LOGIC_AND_SETFLAGS: + insn = aarch64_insn_get_ands_imm_value(); + break; + default: + pr_err("%s: unknown logical encoding %d\n", __func__, type); + return AARCH64_BREAK_FAULT; + } + + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RD, insn, Rd); + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, Rn); + return aarch64_encode_immediate(imm, variant, insn); +} + +u32 aarch64_insn_gen_extr(enum aarch64_insn_variant variant, + enum aarch64_insn_register Rm, + enum aarch64_insn_register Rn, + enum aarch64_insn_register Rd, + u8 lsb) +{ + u32 insn; + + insn = aarch64_insn_get_extr_value(); + + switch (variant) { + case AARCH64_INSN_VARIANT_32BIT: + if (lsb > 31) + return AARCH64_BREAK_FAULT; + break; + case AARCH64_INSN_VARIANT_64BIT: + if (lsb > 63) + return AARCH64_BREAK_FAULT; + insn |= AARCH64_INSN_SF_BIT; + insn = aarch64_insn_encode_immediate(AARCH64_INSN_IMM_N, insn, 1); + break; + default: + pr_err("%s: unknown variant encoding %d\n", __func__, variant); + return AARCH64_BREAK_FAULT; + } + + insn = aarch64_insn_encode_immediate(AARCH64_INSN_IMM_S, insn, lsb); + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RD, insn, Rd); + insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RN, insn, Rn); + return aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RM, insn, Rm); +} -- 2.25.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 03/17] tools: bug: Remove duplicate definition 2021-01-20 17:37 ` Julien Thierry @ 2021-01-20 17:37 ` Julien Thierry -1 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: catalin.marinas, will, ardb, masahiroy, keescook, michal.lkml, jpoimboe, peterz, mark.rutland, broonie, linux-efi, linux-hardening, Julien Thierry Under tools, bug.h only defines BUILD_BUG_ON_ZERO() which is already defined in build_bug.h. This prevents a file to include both headers at the same time. Have bug.h include build_bug.h instead. Signed-off-by: Julien Thierry <jthierry@redhat.com> --- tools/include/linux/bug.h | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/tools/include/linux/bug.h b/tools/include/linux/bug.h index 85f80258a15f..548be7cffa8e 100644 --- a/tools/include/linux/bug.h +++ b/tools/include/linux/bug.h @@ -2,10 +2,6 @@ #ifndef _TOOLS_PERF_LINUX_BUG_H #define _TOOLS_PERF_LINUX_BUG_H -/* Force a compilation error if condition is true, but also produce a - result (of value 0 and type size_t), so the expression can be used - e.g. in a structure initializer (or where-ever else comma expressions - aren't permitted). */ -#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); })) +#include <linux/build_bug.h> #endif /* _TOOLS_PERF_LINUX_BUG_H */ -- 2.25.4 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 03/17] tools: bug: Remove duplicate definition @ 2021-01-20 17:37 ` Julien Thierry 0 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: mark.rutland, linux-efi, michal.lkml, keescook, peterz, catalin.marinas, masahiroy, broonie, linux-hardening, jpoimboe, will, ardb, Julien Thierry Under tools, bug.h only defines BUILD_BUG_ON_ZERO() which is already defined in build_bug.h. This prevents a file to include both headers at the same time. Have bug.h include build_bug.h instead. Signed-off-by: Julien Thierry <jthierry@redhat.com> --- tools/include/linux/bug.h | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/tools/include/linux/bug.h b/tools/include/linux/bug.h index 85f80258a15f..548be7cffa8e 100644 --- a/tools/include/linux/bug.h +++ b/tools/include/linux/bug.h @@ -2,10 +2,6 @@ #ifndef _TOOLS_PERF_LINUX_BUG_H #define _TOOLS_PERF_LINUX_BUG_H -/* Force a compilation error if condition is true, but also produce a - result (of value 0 and type size_t), so the expression can be used - e.g. in a structure initializer (or where-ever else comma expressions - aren't permitted). */ -#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); })) +#include <linux/build_bug.h> #endif /* _TOOLS_PERF_LINUX_BUG_H */ -- 2.25.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 04/17] objtool: arm64: Add base definition for arm64 backend 2021-01-20 17:37 ` Julien Thierry @ 2021-01-20 17:37 ` Julien Thierry -1 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: catalin.marinas, will, ardb, masahiroy, keescook, michal.lkml, jpoimboe, peterz, mark.rutland, broonie, linux-efi, linux-hardening, Julien Thierry Provide needed definitions for a new architecture instruction decoder. No proper decoding is done yet. Signed-off-by: Julien Thierry <jthierry@redhat.com> --- tools/objtool/Makefile | 5 + tools/objtool/arch/arm64/Build | 8 ++ tools/objtool/arch/arm64/decode.c | 130 ++++++++++++++++++ .../arch/arm64/include/arch/cfi_regs.h | 14 ++ tools/objtool/arch/arm64/include/arch/elf.h | 6 + .../arch/arm64/include/arch/endianness.h | 9 ++ .../objtool/arch/arm64/include/arch/special.h | 21 +++ tools/objtool/arch/arm64/special.c | 21 +++ tools/objtool/sync-check.sh | 5 + 9 files changed, 219 insertions(+) create mode 100644 tools/objtool/arch/arm64/Build create mode 100644 tools/objtool/arch/arm64/decode.c create mode 100644 tools/objtool/arch/arm64/include/arch/cfi_regs.h create mode 100644 tools/objtool/arch/arm64/include/arch/elf.h create mode 100644 tools/objtool/arch/arm64/include/arch/endianness.h create mode 100644 tools/objtool/arch/arm64/include/arch/special.h create mode 100644 tools/objtool/arch/arm64/special.c diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile index 92ce4fce7bc7..d5cfbec87c02 100644 --- a/tools/objtool/Makefile +++ b/tools/objtool/Makefile @@ -47,6 +47,11 @@ ifeq ($(SRCARCH),x86) SUBCMD_ORC := y endif +ifeq ($(SRCARCH),arm64) + SUBCMD_CHECK := y + CFLAGS += -Wno-nested-externs +endif + export SUBCMD_CHECK SUBCMD_ORC export srctree OUTPUT CFLAGS SRCARCH AWK include $(srctree)/tools/build/Makefile.include diff --git a/tools/objtool/arch/arm64/Build b/tools/objtool/arch/arm64/Build new file mode 100644 index 000000000000..f3de3a50d541 --- /dev/null +++ b/tools/objtool/arch/arm64/Build @@ -0,0 +1,8 @@ +objtool-y += special.o +objtool-y += decode.o + +objtool-y += libhweight.o + +$(OUTPUT)arch/arm64/libhweight.o: ../lib/hweight.c FORCE + $(call rule_mkdir) + $(call if_changed_dep,cc_o_c) diff --git a/tools/objtool/arch/arm64/decode.c b/tools/objtool/arch/arm64/decode.c new file mode 100644 index 000000000000..8ae822f553ca --- /dev/null +++ b/tools/objtool/arch/arm64/decode.c @@ -0,0 +1,130 @@ +// SPDX-License-Identifier: GPL-2.0-or-later + +#include <stdio.h> +#include <stdlib.h> +#include <stdint.h> + +/* Hack needed to avoid depending on brk-imm.h */ +#define FAULT_BRK_IMM 0x100 + +#include <asm/aarch64-insn.h> + +#include <objtool/check.h> +#include <objtool/arch.h> +#include <objtool/elf.h> +#include <objtool/warn.h> + +#include <arch/cfi_regs.h> + +/* Hack needed to avoid depending on kprobes.h */ +#ifndef __kprobes +#define __kprobes +#endif + +#include "../../../arch/arm64/lib/aarch64-insn.c" + +bool arch_callee_saved_reg(unsigned char reg) +{ + switch (reg) { + case AARCH64_INSN_REG_19: + case AARCH64_INSN_REG_20: + case AARCH64_INSN_REG_21: + case AARCH64_INSN_REG_22: + case AARCH64_INSN_REG_23: + case AARCH64_INSN_REG_24: + case AARCH64_INSN_REG_25: + case AARCH64_INSN_REG_26: + case AARCH64_INSN_REG_27: + case AARCH64_INSN_REG_28: + case AARCH64_INSN_REG_FP: + case AARCH64_INSN_REG_LR: + return true; + default: + return false; + } +} + +void arch_initial_func_cfi_state(struct cfi_init_state *state) +{ + int i; + + for (i = 0; i < CFI_NUM_REGS; i++) { + state->regs[i].base = CFI_UNDEFINED; + state->regs[i].offset = 0; + } + + /* initial CFA (call frame address) */ + state->cfa.base = CFI_SP; + state->cfa.offset = 0; +} + +unsigned long arch_dest_reloc_offset(int addend) +{ + return addend; +} + +unsigned long arch_jump_destination(struct instruction *insn) +{ + return insn->offset + insn->immediate; +} + +const char *arch_nop_insn(int len) +{ + static u32 nop = 0; + + if (len != AARCH64_INSN_SIZE) + WARN("invalid NOP size: %d\n", len); + + if (!nop) + nop = aarch64_insn_gen_nop(); + + return (const char*)&nop; +} + +static int is_arm64(const struct elf *elf) +{ + switch (elf->ehdr.e_machine) { + case EM_AARCH64: //0xB7 + return 1; + default: + WARN("unexpected ELF machine type %x", + elf->ehdr.e_machine); + return 0; + } +} + +int arch_decode_hint_reg(struct instruction *insn, u8 sp_reg) +{ + return -1; +} + +int arch_decode_instruction(const struct elf *elf, const struct section *sec, + unsigned long offset, unsigned int maxlen, + unsigned int *len, enum insn_type *type, + unsigned long *immediate, + struct list_head *ops_list) +{ + u32 insn; + + if (!is_arm64(elf)) + return -1; + + if (maxlen < AARCH64_INSN_SIZE) + return 0; + + *len = AARCH64_INSN_SIZE; + *immediate = 0; + + insn = *(u32 *)(sec->data->d_buf + offset); + + switch (aarch64_get_insn_class(insn)) { + case AARCH64_INSN_CLS_UNKNOWN: + WARN("can't decode instruction at %s:0x%lx", sec->name, offset); + return -1; + default: + *type = INSN_OTHER; + break; + } + + return 0; +} diff --git a/tools/objtool/arch/arm64/include/arch/cfi_regs.h b/tools/objtool/arch/arm64/include/arch/cfi_regs.h new file mode 100644 index 000000000000..43ad56b6c3f9 --- /dev/null +++ b/tools/objtool/arch/arm64/include/arch/cfi_regs.h @@ -0,0 +1,14 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ + +#ifndef _OBJTOOL_CFI_REGS_H +#define _OBJTOOL_CFI_REGS_H + +#include <asm/aarch64-insn.h> + +#define CFI_BP AARCH64_INSN_REG_FP +#define CFI_RA AARCH64_INSN_REG_LR +#define CFI_SP AARCH64_INSN_REG_SP + +#define CFI_NUM_REGS 32 + +#endif /* _OBJTOOL_CFI_REGS_H */ diff --git a/tools/objtool/arch/arm64/include/arch/elf.h b/tools/objtool/arch/arm64/include/arch/elf.h new file mode 100644 index 000000000000..a31a29b1a386 --- /dev/null +++ b/tools/objtool/arch/arm64/include/arch/elf.h @@ -0,0 +1,6 @@ +#ifndef _OBJTOOL_ARCH_ELF +#define _OBJTOOL_ARCH_ELF + +#define R_NONE R_AARCH64_NONE + +#endif /* _OBJTOOL_ARCH_ELF */ diff --git a/tools/objtool/arch/arm64/include/arch/endianness.h b/tools/objtool/arch/arm64/include/arch/endianness.h new file mode 100644 index 000000000000..7c362527da20 --- /dev/null +++ b/tools/objtool/arch/arm64/include/arch/endianness.h @@ -0,0 +1,9 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ +#ifndef _ARCH_ENDIANNESS_H +#define _ARCH_ENDIANNESS_H + +#include <endian.h> + +#define __TARGET_BYTE_ORDER __LITTLE_ENDIAN + +#endif /* _ARCH_ENDIANNESS_H */ diff --git a/tools/objtool/arch/arm64/include/arch/special.h b/tools/objtool/arch/arm64/include/arch/special.h new file mode 100644 index 000000000000..a82a9b3e51df --- /dev/null +++ b/tools/objtool/arch/arm64/include/arch/special.h @@ -0,0 +1,21 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ + +#ifndef _ARM64_ARCH_SPECIAL_H +#define _ARM64_ARCH_SPECIAL_H + +#define EX_ENTRY_SIZE 8 +#define EX_ORIG_OFFSET 0 +#define EX_NEW_OFFSET 4 + +#define JUMP_ENTRY_SIZE 16 +#define JUMP_ORIG_OFFSET 0 +#define JUMP_NEW_OFFSET 4 + +#define ALT_ENTRY_SIZE 12 +#define ALT_ORIG_OFFSET 0 +#define ALT_NEW_OFFSET 4 +#define ALT_FEATURE_OFFSET 8 +#define ALT_ORIG_LEN_OFFSET 10 +#define ALT_NEW_LEN_OFFSET 11 + +#endif /* _ARM64_ARCH_SPECIAL_H */ diff --git a/tools/objtool/arch/arm64/special.c b/tools/objtool/arch/arm64/special.c new file mode 100644 index 000000000000..45f283283091 --- /dev/null +++ b/tools/objtool/arch/arm64/special.c @@ -0,0 +1,21 @@ +// SPDX-License-Identifier: GPL-2.0-or-later + +#include <objtool/special.h> + +void arch_handle_alternative(unsigned short feature, struct special_alt *alt) +{ +} + +bool arch_support_alt_relocation(struct special_alt *special_alt, + struct instruction *insn, + struct reloc *reloc) +{ + return false; +} + + +struct reloc *arch_find_switch_table(struct objtool_file *file, + struct instruction *insn) +{ + return NULL; +} diff --git a/tools/objtool/sync-check.sh b/tools/objtool/sync-check.sh index 606a4b5e929f..69e7ebe8911b 100755 --- a/tools/objtool/sync-check.sh +++ b/tools/objtool/sync-check.sh @@ -21,6 +21,11 @@ arch/x86/include/asm/insn.h -I '^#include [\"<]\(asm/\)*inat.h[\">]' arch/x86/lib/inat.c -I '^#include [\"<]\(../include/\)*asm/insn.h[\">]' arch/x86/lib/insn.c -I '^#include [\"<]\(../include/\)*asm/in\(at\|sn\).h[\">]' -I '^#include [\"<]\(../include/\)*asm/emulate_prefix.h[\">]' " +elif [ "$SRCARCH" = "arm64" ]; then +FILES="$FILES +arch/arm64/include/asm/aarch64-insn.h -I '^#include [\"<]\(asm/\)*brk-imm.h[\">]' +arch/arm64/lib/aarch64-insn.c -I '^#include [\"<]\(asm/\)*kprobes.h[\">]' +" fi check_2 () { -- 2.25.4 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 04/17] objtool: arm64: Add base definition for arm64 backend @ 2021-01-20 17:37 ` Julien Thierry 0 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: mark.rutland, linux-efi, michal.lkml, keescook, peterz, catalin.marinas, masahiroy, broonie, linux-hardening, jpoimboe, will, ardb, Julien Thierry Provide needed definitions for a new architecture instruction decoder. No proper decoding is done yet. Signed-off-by: Julien Thierry <jthierry@redhat.com> --- tools/objtool/Makefile | 5 + tools/objtool/arch/arm64/Build | 8 ++ tools/objtool/arch/arm64/decode.c | 130 ++++++++++++++++++ .../arch/arm64/include/arch/cfi_regs.h | 14 ++ tools/objtool/arch/arm64/include/arch/elf.h | 6 + .../arch/arm64/include/arch/endianness.h | 9 ++ .../objtool/arch/arm64/include/arch/special.h | 21 +++ tools/objtool/arch/arm64/special.c | 21 +++ tools/objtool/sync-check.sh | 5 + 9 files changed, 219 insertions(+) create mode 100644 tools/objtool/arch/arm64/Build create mode 100644 tools/objtool/arch/arm64/decode.c create mode 100644 tools/objtool/arch/arm64/include/arch/cfi_regs.h create mode 100644 tools/objtool/arch/arm64/include/arch/elf.h create mode 100644 tools/objtool/arch/arm64/include/arch/endianness.h create mode 100644 tools/objtool/arch/arm64/include/arch/special.h create mode 100644 tools/objtool/arch/arm64/special.c diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile index 92ce4fce7bc7..d5cfbec87c02 100644 --- a/tools/objtool/Makefile +++ b/tools/objtool/Makefile @@ -47,6 +47,11 @@ ifeq ($(SRCARCH),x86) SUBCMD_ORC := y endif +ifeq ($(SRCARCH),arm64) + SUBCMD_CHECK := y + CFLAGS += -Wno-nested-externs +endif + export SUBCMD_CHECK SUBCMD_ORC export srctree OUTPUT CFLAGS SRCARCH AWK include $(srctree)/tools/build/Makefile.include diff --git a/tools/objtool/arch/arm64/Build b/tools/objtool/arch/arm64/Build new file mode 100644 index 000000000000..f3de3a50d541 --- /dev/null +++ b/tools/objtool/arch/arm64/Build @@ -0,0 +1,8 @@ +objtool-y += special.o +objtool-y += decode.o + +objtool-y += libhweight.o + +$(OUTPUT)arch/arm64/libhweight.o: ../lib/hweight.c FORCE + $(call rule_mkdir) + $(call if_changed_dep,cc_o_c) diff --git a/tools/objtool/arch/arm64/decode.c b/tools/objtool/arch/arm64/decode.c new file mode 100644 index 000000000000..8ae822f553ca --- /dev/null +++ b/tools/objtool/arch/arm64/decode.c @@ -0,0 +1,130 @@ +// SPDX-License-Identifier: GPL-2.0-or-later + +#include <stdio.h> +#include <stdlib.h> +#include <stdint.h> + +/* Hack needed to avoid depending on brk-imm.h */ +#define FAULT_BRK_IMM 0x100 + +#include <asm/aarch64-insn.h> + +#include <objtool/check.h> +#include <objtool/arch.h> +#include <objtool/elf.h> +#include <objtool/warn.h> + +#include <arch/cfi_regs.h> + +/* Hack needed to avoid depending on kprobes.h */ +#ifndef __kprobes +#define __kprobes +#endif + +#include "../../../arch/arm64/lib/aarch64-insn.c" + +bool arch_callee_saved_reg(unsigned char reg) +{ + switch (reg) { + case AARCH64_INSN_REG_19: + case AARCH64_INSN_REG_20: + case AARCH64_INSN_REG_21: + case AARCH64_INSN_REG_22: + case AARCH64_INSN_REG_23: + case AARCH64_INSN_REG_24: + case AARCH64_INSN_REG_25: + case AARCH64_INSN_REG_26: + case AARCH64_INSN_REG_27: + case AARCH64_INSN_REG_28: + case AARCH64_INSN_REG_FP: + case AARCH64_INSN_REG_LR: + return true; + default: + return false; + } +} + +void arch_initial_func_cfi_state(struct cfi_init_state *state) +{ + int i; + + for (i = 0; i < CFI_NUM_REGS; i++) { + state->regs[i].base = CFI_UNDEFINED; + state->regs[i].offset = 0; + } + + /* initial CFA (call frame address) */ + state->cfa.base = CFI_SP; + state->cfa.offset = 0; +} + +unsigned long arch_dest_reloc_offset(int addend) +{ + return addend; +} + +unsigned long arch_jump_destination(struct instruction *insn) +{ + return insn->offset + insn->immediate; +} + +const char *arch_nop_insn(int len) +{ + static u32 nop = 0; + + if (len != AARCH64_INSN_SIZE) + WARN("invalid NOP size: %d\n", len); + + if (!nop) + nop = aarch64_insn_gen_nop(); + + return (const char*)&nop; +} + +static int is_arm64(const struct elf *elf) +{ + switch (elf->ehdr.e_machine) { + case EM_AARCH64: //0xB7 + return 1; + default: + WARN("unexpected ELF machine type %x", + elf->ehdr.e_machine); + return 0; + } +} + +int arch_decode_hint_reg(struct instruction *insn, u8 sp_reg) +{ + return -1; +} + +int arch_decode_instruction(const struct elf *elf, const struct section *sec, + unsigned long offset, unsigned int maxlen, + unsigned int *len, enum insn_type *type, + unsigned long *immediate, + struct list_head *ops_list) +{ + u32 insn; + + if (!is_arm64(elf)) + return -1; + + if (maxlen < AARCH64_INSN_SIZE) + return 0; + + *len = AARCH64_INSN_SIZE; + *immediate = 0; + + insn = *(u32 *)(sec->data->d_buf + offset); + + switch (aarch64_get_insn_class(insn)) { + case AARCH64_INSN_CLS_UNKNOWN: + WARN("can't decode instruction at %s:0x%lx", sec->name, offset); + return -1; + default: + *type = INSN_OTHER; + break; + } + + return 0; +} diff --git a/tools/objtool/arch/arm64/include/arch/cfi_regs.h b/tools/objtool/arch/arm64/include/arch/cfi_regs.h new file mode 100644 index 000000000000..43ad56b6c3f9 --- /dev/null +++ b/tools/objtool/arch/arm64/include/arch/cfi_regs.h @@ -0,0 +1,14 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ + +#ifndef _OBJTOOL_CFI_REGS_H +#define _OBJTOOL_CFI_REGS_H + +#include <asm/aarch64-insn.h> + +#define CFI_BP AARCH64_INSN_REG_FP +#define CFI_RA AARCH64_INSN_REG_LR +#define CFI_SP AARCH64_INSN_REG_SP + +#define CFI_NUM_REGS 32 + +#endif /* _OBJTOOL_CFI_REGS_H */ diff --git a/tools/objtool/arch/arm64/include/arch/elf.h b/tools/objtool/arch/arm64/include/arch/elf.h new file mode 100644 index 000000000000..a31a29b1a386 --- /dev/null +++ b/tools/objtool/arch/arm64/include/arch/elf.h @@ -0,0 +1,6 @@ +#ifndef _OBJTOOL_ARCH_ELF +#define _OBJTOOL_ARCH_ELF + +#define R_NONE R_AARCH64_NONE + +#endif /* _OBJTOOL_ARCH_ELF */ diff --git a/tools/objtool/arch/arm64/include/arch/endianness.h b/tools/objtool/arch/arm64/include/arch/endianness.h new file mode 100644 index 000000000000..7c362527da20 --- /dev/null +++ b/tools/objtool/arch/arm64/include/arch/endianness.h @@ -0,0 +1,9 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ +#ifndef _ARCH_ENDIANNESS_H +#define _ARCH_ENDIANNESS_H + +#include <endian.h> + +#define __TARGET_BYTE_ORDER __LITTLE_ENDIAN + +#endif /* _ARCH_ENDIANNESS_H */ diff --git a/tools/objtool/arch/arm64/include/arch/special.h b/tools/objtool/arch/arm64/include/arch/special.h new file mode 100644 index 000000000000..a82a9b3e51df --- /dev/null +++ b/tools/objtool/arch/arm64/include/arch/special.h @@ -0,0 +1,21 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ + +#ifndef _ARM64_ARCH_SPECIAL_H +#define _ARM64_ARCH_SPECIAL_H + +#define EX_ENTRY_SIZE 8 +#define EX_ORIG_OFFSET 0 +#define EX_NEW_OFFSET 4 + +#define JUMP_ENTRY_SIZE 16 +#define JUMP_ORIG_OFFSET 0 +#define JUMP_NEW_OFFSET 4 + +#define ALT_ENTRY_SIZE 12 +#define ALT_ORIG_OFFSET 0 +#define ALT_NEW_OFFSET 4 +#define ALT_FEATURE_OFFSET 8 +#define ALT_ORIG_LEN_OFFSET 10 +#define ALT_NEW_LEN_OFFSET 11 + +#endif /* _ARM64_ARCH_SPECIAL_H */ diff --git a/tools/objtool/arch/arm64/special.c b/tools/objtool/arch/arm64/special.c new file mode 100644 index 000000000000..45f283283091 --- /dev/null +++ b/tools/objtool/arch/arm64/special.c @@ -0,0 +1,21 @@ +// SPDX-License-Identifier: GPL-2.0-or-later + +#include <objtool/special.h> + +void arch_handle_alternative(unsigned short feature, struct special_alt *alt) +{ +} + +bool arch_support_alt_relocation(struct special_alt *special_alt, + struct instruction *insn, + struct reloc *reloc) +{ + return false; +} + + +struct reloc *arch_find_switch_table(struct objtool_file *file, + struct instruction *insn) +{ + return NULL; +} diff --git a/tools/objtool/sync-check.sh b/tools/objtool/sync-check.sh index 606a4b5e929f..69e7ebe8911b 100755 --- a/tools/objtool/sync-check.sh +++ b/tools/objtool/sync-check.sh @@ -21,6 +21,11 @@ arch/x86/include/asm/insn.h -I '^#include [\"<]\(asm/\)*inat.h[\">]' arch/x86/lib/inat.c -I '^#include [\"<]\(../include/\)*asm/insn.h[\">]' arch/x86/lib/insn.c -I '^#include [\"<]\(../include/\)*asm/in\(at\|sn\).h[\">]' -I '^#include [\"<]\(../include/\)*asm/emulate_prefix.h[\">]' " +elif [ "$SRCARCH" = "arm64" ]; then +FILES="$FILES +arch/arm64/include/asm/aarch64-insn.h -I '^#include [\"<]\(asm/\)*brk-imm.h[\">]' +arch/arm64/lib/aarch64-insn.c -I '^#include [\"<]\(asm/\)*kprobes.h[\">]' +" fi check_2 () { -- 2.25.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 05/17] objtool: arm64: Decode add/sub instructions 2021-01-20 17:37 ` Julien Thierry @ 2021-01-20 17:37 ` Julien Thierry -1 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: catalin.marinas, will, ardb, masahiroy, keescook, michal.lkml, jpoimboe, peterz, mark.rutland, broonie, linux-efi, linux-hardening, Julien Thierry Decode aarch64 additions and substractions and create stack_ops for instructions interacting with SP or FP. Signed-off-by: Julien Thierry <jthierry@redhat.com> --- tools/objtool/arch/arm64/decode.c | 84 +++++++++++++++++++++++++++++++ 1 file changed, 84 insertions(+) diff --git a/tools/objtool/arch/arm64/decode.c b/tools/objtool/arch/arm64/decode.c index 8ae822f553ca..0f312dd1b146 100644 --- a/tools/objtool/arch/arm64/decode.c +++ b/tools/objtool/arch/arm64/decode.c @@ -23,6 +23,13 @@ #include "../../../arch/arm64/lib/aarch64-insn.c" +static unsigned long sign_extend(unsigned long x, int nbits) +{ + unsigned long sign_bit = (x >> (nbits - 1)) & 1; + + return ((~0UL + (sign_bit ^ 1)) << nbits) | x; +} + bool arch_callee_saved_reg(unsigned char reg) { switch (reg) { @@ -98,6 +105,53 @@ int arch_decode_hint_reg(struct instruction *insn, u8 sp_reg) return -1; } +static struct stack_op *arm_make_add_op(enum aarch64_insn_register dest, + enum aarch64_insn_register src, + int val) +{ + struct stack_op *op; + + op = calloc(1, sizeof(*op)); + op->dest.type = OP_DEST_REG; + op->dest.reg = dest; + op->src.reg = src; + op->src.type = val != 0 ? OP_SRC_ADD : OP_SRC_REG; + op->src.offset = val; + + return op; +} + +static void arm_decode_add_sub_imm(u32 instr, bool set_flags, + enum insn_type *type, + unsigned long *immediate, + struct list_head *ops_list) +{ + u32 rd = aarch64_insn_decode_register(AARCH64_INSN_REGTYPE_RD, instr); + u32 rn = aarch64_insn_decode_register(AARCH64_INSN_REGTYPE_RN, instr); + + *type = INSN_OTHER; + *immediate = aarch64_insn_decode_immediate(AARCH64_INSN_IMM_12, instr); + + if (instr & AARCH64_INSN_LSL_12) + *immediate <<= 12; + + if ((!set_flags && rd == AARCH64_INSN_REG_SP) || + rd == AARCH64_INSN_REG_FP || + rn == AARCH64_INSN_REG_FP || + rn == AARCH64_INSN_REG_SP) { + struct stack_op *op; + int value; + + if (aarch64_insn_is_subs_imm(instr) || aarch64_insn_is_sub_imm(instr)) + value = -*immediate; + else + value = *immediate; + + op = arm_make_add_op(rd, rn, value); + list_add_tail(&op->list, ops_list); + } +} + int arch_decode_instruction(const struct elf *elf, const struct section *sec, unsigned long offset, unsigned int maxlen, unsigned int *len, enum insn_type *type, @@ -121,6 +175,36 @@ int arch_decode_instruction(const struct elf *elf, const struct section *sec, case AARCH64_INSN_CLS_UNKNOWN: WARN("can't decode instruction at %s:0x%lx", sec->name, offset); return -1; + case AARCH64_INSN_CLS_DP_IMM: + /* Mov register to and from SP are aliases of add_imm */ + if (aarch64_insn_is_add_imm(insn) || + aarch64_insn_is_sub_imm(insn)) + arm_decode_add_sub_imm(insn, false, type, immediate, + ops_list); + else if (aarch64_insn_is_adds_imm(insn) || + aarch64_insn_is_subs_imm(insn)) + arm_decode_add_sub_imm(insn, true, type, immediate, + ops_list); + else + *type = INSN_OTHER; + break; + case AARCH64_INSN_CLS_DP_REG: + if (aarch64_insn_is_mov_reg(insn)) { + enum aarch64_insn_register rd; + enum aarch64_insn_register rm; + + rd = aarch64_insn_decode_register(AARCH64_INSN_REGTYPE_RD, insn); + rm = aarch64_insn_decode_register(AARCH64_INSN_REGTYPE_RM, insn); + if (rd == AARCH64_INSN_REG_FP || rm == AARCH64_INSN_REG_FP) { + struct stack_op *op; + + op = arm_make_add_op(rd, rm, 0); + list_add_tail(&op->list, ops_list); + break; + } + } + *type = INSN_OTHER; + break; default: *type = INSN_OTHER; break; -- 2.25.4 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 05/17] objtool: arm64: Decode add/sub instructions @ 2021-01-20 17:37 ` Julien Thierry 0 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: mark.rutland, linux-efi, michal.lkml, keescook, peterz, catalin.marinas, masahiroy, broonie, linux-hardening, jpoimboe, will, ardb, Julien Thierry Decode aarch64 additions and substractions and create stack_ops for instructions interacting with SP or FP. Signed-off-by: Julien Thierry <jthierry@redhat.com> --- tools/objtool/arch/arm64/decode.c | 84 +++++++++++++++++++++++++++++++ 1 file changed, 84 insertions(+) diff --git a/tools/objtool/arch/arm64/decode.c b/tools/objtool/arch/arm64/decode.c index 8ae822f553ca..0f312dd1b146 100644 --- a/tools/objtool/arch/arm64/decode.c +++ b/tools/objtool/arch/arm64/decode.c @@ -23,6 +23,13 @@ #include "../../../arch/arm64/lib/aarch64-insn.c" +static unsigned long sign_extend(unsigned long x, int nbits) +{ + unsigned long sign_bit = (x >> (nbits - 1)) & 1; + + return ((~0UL + (sign_bit ^ 1)) << nbits) | x; +} + bool arch_callee_saved_reg(unsigned char reg) { switch (reg) { @@ -98,6 +105,53 @@ int arch_decode_hint_reg(struct instruction *insn, u8 sp_reg) return -1; } +static struct stack_op *arm_make_add_op(enum aarch64_insn_register dest, + enum aarch64_insn_register src, + int val) +{ + struct stack_op *op; + + op = calloc(1, sizeof(*op)); + op->dest.type = OP_DEST_REG; + op->dest.reg = dest; + op->src.reg = src; + op->src.type = val != 0 ? OP_SRC_ADD : OP_SRC_REG; + op->src.offset = val; + + return op; +} + +static void arm_decode_add_sub_imm(u32 instr, bool set_flags, + enum insn_type *type, + unsigned long *immediate, + struct list_head *ops_list) +{ + u32 rd = aarch64_insn_decode_register(AARCH64_INSN_REGTYPE_RD, instr); + u32 rn = aarch64_insn_decode_register(AARCH64_INSN_REGTYPE_RN, instr); + + *type = INSN_OTHER; + *immediate = aarch64_insn_decode_immediate(AARCH64_INSN_IMM_12, instr); + + if (instr & AARCH64_INSN_LSL_12) + *immediate <<= 12; + + if ((!set_flags && rd == AARCH64_INSN_REG_SP) || + rd == AARCH64_INSN_REG_FP || + rn == AARCH64_INSN_REG_FP || + rn == AARCH64_INSN_REG_SP) { + struct stack_op *op; + int value; + + if (aarch64_insn_is_subs_imm(instr) || aarch64_insn_is_sub_imm(instr)) + value = -*immediate; + else + value = *immediate; + + op = arm_make_add_op(rd, rn, value); + list_add_tail(&op->list, ops_list); + } +} + int arch_decode_instruction(const struct elf *elf, const struct section *sec, unsigned long offset, unsigned int maxlen, unsigned int *len, enum insn_type *type, @@ -121,6 +175,36 @@ int arch_decode_instruction(const struct elf *elf, const struct section *sec, case AARCH64_INSN_CLS_UNKNOWN: WARN("can't decode instruction at %s:0x%lx", sec->name, offset); return -1; + case AARCH64_INSN_CLS_DP_IMM: + /* Mov register to and from SP are aliases of add_imm */ + if (aarch64_insn_is_add_imm(insn) || + aarch64_insn_is_sub_imm(insn)) + arm_decode_add_sub_imm(insn, false, type, immediate, + ops_list); + else if (aarch64_insn_is_adds_imm(insn) || + aarch64_insn_is_subs_imm(insn)) + arm_decode_add_sub_imm(insn, true, type, immediate, + ops_list); + else + *type = INSN_OTHER; + break; + case AARCH64_INSN_CLS_DP_REG: + if (aarch64_insn_is_mov_reg(insn)) { + enum aarch64_insn_register rd; + enum aarch64_insn_register rm; + + rd = aarch64_insn_decode_register(AARCH64_INSN_REGTYPE_RD, insn); + rm = aarch64_insn_decode_register(AARCH64_INSN_REGTYPE_RM, insn); + if (rd == AARCH64_INSN_REG_FP || rm == AARCH64_INSN_REG_FP) { + struct stack_op *op; + + op = arm_make_add_op(rd, rm, 0); + list_add_tail(&op->list, ops_list); + break; + } + } + *type = INSN_OTHER; + break; default: *type = INSN_OTHER; break; -- 2.25.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 06/17] objtool: arm64: Decode jump and call related instructions 2021-01-20 17:37 ` Julien Thierry @ 2021-01-20 17:37 ` Julien Thierry -1 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: catalin.marinas, will, ardb, masahiroy, keescook, michal.lkml, jpoimboe, peterz, mark.rutland, broonie, linux-efi, linux-hardening, Julien Thierry Decode branch, branch and link (aarch64's call) and return instructions. Signed-off-by: Julien Thierry <jthierry@redhat.com> --- tools/objtool/arch/arm64/decode.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/tools/objtool/arch/arm64/decode.c b/tools/objtool/arch/arm64/decode.c index 0f312dd1b146..924121b4b466 100644 --- a/tools/objtool/arch/arm64/decode.c +++ b/tools/objtool/arch/arm64/decode.c @@ -205,6 +205,28 @@ int arch_decode_instruction(const struct elf *elf, const struct section *sec, } *type = INSN_OTHER; break; + case AARCH64_INSN_CLS_BR_SYS: + if (aarch64_insn_is_ret(insn) && + aarch64_insn_decode_register(AARCH64_INSN_REGTYPE_RN, insn) == AARCH64_INSN_REG_LR) { + *type = INSN_RETURN; + } else if (aarch64_insn_is_bl(insn)) { + *type = INSN_CALL; + *immediate = aarch64_get_branch_offset(insn); + } else if (aarch64_insn_is_blr(insn)) { + *type = INSN_CALL_DYNAMIC; + } else if (aarch64_insn_is_b(insn)) { + *type = INSN_JUMP_UNCONDITIONAL; + *immediate = aarch64_get_branch_offset(insn); + } else if (aarch64_insn_is_br(insn)) { + *type = INSN_JUMP_DYNAMIC; + } else if (aarch64_insn_is_branch_imm(insn)) { + /* Remaining branch opcodes are conditional */ + *type = INSN_JUMP_CONDITIONAL; + *immediate = aarch64_get_branch_offset(insn); + } else { + *type = INSN_OTHER; + } + break; default: *type = INSN_OTHER; break; -- 2.25.4 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 06/17] objtool: arm64: Decode jump and call related instructions @ 2021-01-20 17:37 ` Julien Thierry 0 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: mark.rutland, linux-efi, michal.lkml, keescook, peterz, catalin.marinas, masahiroy, broonie, linux-hardening, jpoimboe, will, ardb, Julien Thierry Decode branch, branch and link (aarch64's call) and return instructions. Signed-off-by: Julien Thierry <jthierry@redhat.com> --- tools/objtool/arch/arm64/decode.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/tools/objtool/arch/arm64/decode.c b/tools/objtool/arch/arm64/decode.c index 0f312dd1b146..924121b4b466 100644 --- a/tools/objtool/arch/arm64/decode.c +++ b/tools/objtool/arch/arm64/decode.c @@ -205,6 +205,28 @@ int arch_decode_instruction(const struct elf *elf, const struct section *sec, } *type = INSN_OTHER; break; + case AARCH64_INSN_CLS_BR_SYS: + if (aarch64_insn_is_ret(insn) && + aarch64_insn_decode_register(AARCH64_INSN_REGTYPE_RN, insn) == AARCH64_INSN_REG_LR) { + *type = INSN_RETURN; + } else if (aarch64_insn_is_bl(insn)) { + *type = INSN_CALL; + *immediate = aarch64_get_branch_offset(insn); + } else if (aarch64_insn_is_blr(insn)) { + *type = INSN_CALL_DYNAMIC; + } else if (aarch64_insn_is_b(insn)) { + *type = INSN_JUMP_UNCONDITIONAL; + *immediate = aarch64_get_branch_offset(insn); + } else if (aarch64_insn_is_br(insn)) { + *type = INSN_JUMP_DYNAMIC; + } else if (aarch64_insn_is_branch_imm(insn)) { + /* Remaining branch opcodes are conditional */ + *type = INSN_JUMP_CONDITIONAL; + *immediate = aarch64_get_branch_offset(insn); + } else { + *type = INSN_OTHER; + } + break; default: *type = INSN_OTHER; break; -- 2.25.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 07/17] objtool: arm64: Decode other system instructions 2021-01-20 17:37 ` Julien Thierry @ 2021-01-20 17:37 ` Julien Thierry -1 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: catalin.marinas, will, ardb, masahiroy, keescook, michal.lkml, jpoimboe, peterz, mark.rutland, broonie, linux-efi, linux-hardening, Julien Thierry Decode ERET, BRK and NOPs Signed-off-by: Julien Thierry <jthierry@redhat.com> --- tools/objtool/arch/arm64/decode.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/tools/objtool/arch/arm64/decode.c b/tools/objtool/arch/arm64/decode.c index 924121b4b466..a4a587c400a1 100644 --- a/tools/objtool/arch/arm64/decode.c +++ b/tools/objtool/arch/arm64/decode.c @@ -223,6 +223,13 @@ int arch_decode_instruction(const struct elf *elf, const struct section *sec, /* Remaining branch opcodes are conditional */ *type = INSN_JUMP_CONDITIONAL; *immediate = aarch64_get_branch_offset(insn); + } else if (aarch64_insn_is_eret(insn)) { + *type = INSN_CONTEXT_SWITCH; + } else if (aarch64_insn_is_steppable_hint(insn)) { + *type = INSN_NOP; + } else if (aarch64_insn_is_brk(insn)) { + *immediate = aarch64_insn_decode_immediate(AARCH64_INSN_IMM_16, insn); + *type = INSN_BUG; } else { *type = INSN_OTHER; } -- 2.25.4 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 07/17] objtool: arm64: Decode other system instructions @ 2021-01-20 17:37 ` Julien Thierry 0 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: mark.rutland, linux-efi, michal.lkml, keescook, peterz, catalin.marinas, masahiroy, broonie, linux-hardening, jpoimboe, will, ardb, Julien Thierry Decode ERET, BRK and NOPs Signed-off-by: Julien Thierry <jthierry@redhat.com> --- tools/objtool/arch/arm64/decode.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/tools/objtool/arch/arm64/decode.c b/tools/objtool/arch/arm64/decode.c index 924121b4b466..a4a587c400a1 100644 --- a/tools/objtool/arch/arm64/decode.c +++ b/tools/objtool/arch/arm64/decode.c @@ -223,6 +223,13 @@ int arch_decode_instruction(const struct elf *elf, const struct section *sec, /* Remaining branch opcodes are conditional */ *type = INSN_JUMP_CONDITIONAL; *immediate = aarch64_get_branch_offset(insn); + } else if (aarch64_insn_is_eret(insn)) { + *type = INSN_CONTEXT_SWITCH; + } else if (aarch64_insn_is_steppable_hint(insn)) { + *type = INSN_NOP; + } else if (aarch64_insn_is_brk(insn)) { + *immediate = aarch64_insn_decode_immediate(AARCH64_INSN_IMM_16, insn); + *type = INSN_BUG; } else { *type = INSN_OTHER; } -- 2.25.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 08/17] objtool: arm64: Decode load/store instructions 2021-01-20 17:37 ` Julien Thierry @ 2021-01-20 17:37 ` Julien Thierry -1 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: catalin.marinas, will, ardb, masahiroy, keescook, michal.lkml, jpoimboe, peterz, mark.rutland, broonie, linux-efi, linux-hardening, Julien Thierry Decode load/store operations and create corresponding stack_ops for operations targetting SP or FP. Operations storing/loading multiple registers are split into separate stack_ops storing single registers. Operations modifying the base register get an additional stack_op for the register update. Since the atomic register(s) load/store + base register update gets split into multiple operations, to make sure objtool always sees a valid stack, consider store instruction to perform stack allocations (i.e. modifying the base pointer before the storing) and loads de-allocations (i.e. modifying the base pointer after the load). Signed-off-by: Julien Thierry <jthierry@redhat.com> --- tools/objtool/arch/arm64/decode.c | 127 ++++++++++++++++++++++++++++++ 1 file changed, 127 insertions(+) diff --git a/tools/objtool/arch/arm64/decode.c b/tools/objtool/arch/arm64/decode.c index a4a587c400a1..1087ede67bcd 100644 --- a/tools/objtool/arch/arm64/decode.c +++ b/tools/objtool/arch/arm64/decode.c @@ -105,6 +105,40 @@ int arch_decode_hint_reg(struct instruction *insn, u8 sp_reg) return -1; } +static struct stack_op *arm_make_store_op(enum aarch64_insn_register base, + enum aarch64_insn_register reg, + int offset) +{ + struct stack_op *op; + + op = calloc(1, sizeof(*op)); + op->dest.type = OP_DEST_REG_INDIRECT; + op->dest.reg = base; + op->dest.offset = offset; + op->src.type = OP_SRC_REG; + op->src.reg = reg; + op->src.offset = 0; + + return op; +} + +static struct stack_op *arm_make_load_op(enum aarch64_insn_register base, + enum aarch64_insn_register reg, + int offset) +{ + struct stack_op *op; + + op = calloc(1, sizeof(*op)); + op->dest.type = OP_DEST_REG; + op->dest.reg = reg; + op->dest.offset = 0; + op->src.type = OP_SRC_REG_INDIRECT; + op->src.reg = base; + op->src.offset = offset; + + return op; +} + static struct stack_op *arm_make_add_op(enum aarch64_insn_register dest, enum aarch64_insn_register src, int val) @@ -121,6 +155,94 @@ static struct stack_op *arm_make_add_op(enum aarch64_insn_register dest, return op; } +static bool arm_decode_load_store(u32 insn, enum insn_type *type, + unsigned long *immediate, + struct list_head *ops_list) +{ + enum aarch64_insn_register base; + enum aarch64_insn_register rt; + struct stack_op *op; + int size; + int offset; + + *type = INSN_OTHER; + + if (aarch64_insn_is_store_single(insn) || + aarch64_insn_is_load_single(insn)) + size = 1 << ((insn & GENMASK(31, 30)) >> 30); + else + size = 4 << ((insn >> 31) & 1); + + if (aarch64_insn_is_store_imm(insn) || aarch64_insn_is_load_imm(insn)) + *immediate = size * aarch64_insn_decode_immediate(AARCH64_INSN_IMM_12, + insn); + else if (aarch64_insn_is_store_pre(insn) || + aarch64_insn_is_load_pre(insn) || + aarch64_insn_is_store_post(insn) || + aarch64_insn_is_load_post(insn)) + *immediate = sign_extend(aarch64_insn_decode_immediate(AARCH64_INSN_IMM_9, + insn), + 9); + else if (aarch64_insn_is_stp(insn) || aarch64_insn_is_ldp(insn) || + aarch64_insn_is_stp_pre(insn) || + aarch64_insn_is_ldp_pre(insn) || + aarch64_insn_is_stp_post(insn) || + aarch64_insn_is_ldp_post(insn)) + *immediate = size * sign_extend(aarch64_insn_decode_immediate(AARCH64_INSN_IMM_7, + insn), + 7); + else + return false; + + base = aarch64_insn_decode_register(AARCH64_INSN_REGTYPE_RN, insn); + if (base != AARCH64_INSN_REG_FP && base != AARCH64_INSN_REG_SP) + return true; + + offset = *immediate; + + if (aarch64_insn_is_store_pre(insn) || aarch64_insn_is_stp_pre(insn) || + aarch64_insn_is_store_post(insn) || aarch64_insn_is_stp_post(insn)) { + op = arm_make_add_op(base, base, *immediate); + list_add_tail(&op->list, ops_list); + + if (aarch64_insn_is_store_post(insn) || aarch64_insn_is_stp_post(insn)) + offset = -*immediate; + else + offset = 0; + } else if (aarch64_insn_is_load_post(insn) || aarch64_insn_is_ldp_post(insn)) { + offset = 0; + } + + /* First register */ + rt = aarch64_insn_decode_register(AARCH64_INSN_REGTYPE_RT, insn); + if (aarch64_insn_is_store_single(insn) || + aarch64_insn_is_store_pair(insn)) + op = arm_make_store_op(base, rt, offset); + else + op = arm_make_load_op(base, rt, offset); + list_add_tail(&op->list, ops_list); + + /* Second register (if present) */ + if (aarch64_insn_is_store_pair(insn) || + aarch64_insn_is_load_pair(insn)) { + rt = aarch64_insn_decode_register(AARCH64_INSN_REGTYPE_RT2, + insn); + if (aarch64_insn_is_store_pair(insn)) + op = arm_make_store_op(base, rt, offset + size); + else + op = arm_make_load_op(base, rt, offset + size); + list_add_tail(&op->list, ops_list); + } + + if (aarch64_insn_is_load_pre(insn) || aarch64_insn_is_ldp_pre(insn) || + aarch64_insn_is_load_post(insn) || aarch64_insn_is_ldp_post(insn)) { + op = arm_make_add_op(base, base, *immediate); + list_add_tail(&op->list, ops_list); + } + + return true; +} + static void arm_decode_add_sub_imm(u32 instr, bool set_flags, enum insn_type *type, unsigned long *immediate, @@ -234,6 +356,11 @@ int arch_decode_instruction(const struct elf *elf, const struct section *sec, *type = INSN_OTHER; } break; + case AARCH64_INSN_CLS_LDST: + if (arm_decode_load_store(insn, type, immediate, ops_list)) + break; + *type = INSN_OTHER; + break; default: *type = INSN_OTHER; break; -- 2.25.4 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 08/17] objtool: arm64: Decode load/store instructions @ 2021-01-20 17:37 ` Julien Thierry 0 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: mark.rutland, linux-efi, michal.lkml, keescook, peterz, catalin.marinas, masahiroy, broonie, linux-hardening, jpoimboe, will, ardb, Julien Thierry Decode load/store operations and create corresponding stack_ops for operations targetting SP or FP. Operations storing/loading multiple registers are split into separate stack_ops storing single registers. Operations modifying the base register get an additional stack_op for the register update. Since the atomic register(s) load/store + base register update gets split into multiple operations, to make sure objtool always sees a valid stack, consider store instruction to perform stack allocations (i.e. modifying the base pointer before the storing) and loads de-allocations (i.e. modifying the base pointer after the load). Signed-off-by: Julien Thierry <jthierry@redhat.com> --- tools/objtool/arch/arm64/decode.c | 127 ++++++++++++++++++++++++++++++ 1 file changed, 127 insertions(+) diff --git a/tools/objtool/arch/arm64/decode.c b/tools/objtool/arch/arm64/decode.c index a4a587c400a1..1087ede67bcd 100644 --- a/tools/objtool/arch/arm64/decode.c +++ b/tools/objtool/arch/arm64/decode.c @@ -105,6 +105,40 @@ int arch_decode_hint_reg(struct instruction *insn, u8 sp_reg) return -1; } +static struct stack_op *arm_make_store_op(enum aarch64_insn_register base, + enum aarch64_insn_register reg, + int offset) +{ + struct stack_op *op; + + op = calloc(1, sizeof(*op)); + op->dest.type = OP_DEST_REG_INDIRECT; + op->dest.reg = base; + op->dest.offset = offset; + op->src.type = OP_SRC_REG; + op->src.reg = reg; + op->src.offset = 0; + + return op; +} + +static struct stack_op *arm_make_load_op(enum aarch64_insn_register base, + enum aarch64_insn_register reg, + int offset) +{ + struct stack_op *op; + + op = calloc(1, sizeof(*op)); + op->dest.type = OP_DEST_REG; + op->dest.reg = reg; + op->dest.offset = 0; + op->src.type = OP_SRC_REG_INDIRECT; + op->src.reg = base; + op->src.offset = offset; + + return op; +} + static struct stack_op *arm_make_add_op(enum aarch64_insn_register dest, enum aarch64_insn_register src, int val) @@ -121,6 +155,94 @@ static struct stack_op *arm_make_add_op(enum aarch64_insn_register dest, return op; } +static bool arm_decode_load_store(u32 insn, enum insn_type *type, + unsigned long *immediate, + struct list_head *ops_list) +{ + enum aarch64_insn_register base; + enum aarch64_insn_register rt; + struct stack_op *op; + int size; + int offset; + + *type = INSN_OTHER; + + if (aarch64_insn_is_store_single(insn) || + aarch64_insn_is_load_single(insn)) + size = 1 << ((insn & GENMASK(31, 30)) >> 30); + else + size = 4 << ((insn >> 31) & 1); + + if (aarch64_insn_is_store_imm(insn) || aarch64_insn_is_load_imm(insn)) + *immediate = size * aarch64_insn_decode_immediate(AARCH64_INSN_IMM_12, + insn); + else if (aarch64_insn_is_store_pre(insn) || + aarch64_insn_is_load_pre(insn) || + aarch64_insn_is_store_post(insn) || + aarch64_insn_is_load_post(insn)) + *immediate = sign_extend(aarch64_insn_decode_immediate(AARCH64_INSN_IMM_9, + insn), + 9); + else if (aarch64_insn_is_stp(insn) || aarch64_insn_is_ldp(insn) || + aarch64_insn_is_stp_pre(insn) || + aarch64_insn_is_ldp_pre(insn) || + aarch64_insn_is_stp_post(insn) || + aarch64_insn_is_ldp_post(insn)) + *immediate = size * sign_extend(aarch64_insn_decode_immediate(AARCH64_INSN_IMM_7, + insn), + 7); + else + return false; + + base = aarch64_insn_decode_register(AARCH64_INSN_REGTYPE_RN, insn); + if (base != AARCH64_INSN_REG_FP && base != AARCH64_INSN_REG_SP) + return true; + + offset = *immediate; + + if (aarch64_insn_is_store_pre(insn) || aarch64_insn_is_stp_pre(insn) || + aarch64_insn_is_store_post(insn) || aarch64_insn_is_stp_post(insn)) { + op = arm_make_add_op(base, base, *immediate); + list_add_tail(&op->list, ops_list); + + if (aarch64_insn_is_store_post(insn) || aarch64_insn_is_stp_post(insn)) + offset = -*immediate; + else + offset = 0; + } else if (aarch64_insn_is_load_post(insn) || aarch64_insn_is_ldp_post(insn)) { + offset = 0; + } + + /* First register */ + rt = aarch64_insn_decode_register(AARCH64_INSN_REGTYPE_RT, insn); + if (aarch64_insn_is_store_single(insn) || + aarch64_insn_is_store_pair(insn)) + op = arm_make_store_op(base, rt, offset); + else + op = arm_make_load_op(base, rt, offset); + list_add_tail(&op->list, ops_list); + + /* Second register (if present) */ + if (aarch64_insn_is_store_pair(insn) || + aarch64_insn_is_load_pair(insn)) { + rt = aarch64_insn_decode_register(AARCH64_INSN_REGTYPE_RT2, + insn); + if (aarch64_insn_is_store_pair(insn)) + op = arm_make_store_op(base, rt, offset + size); + else + op = arm_make_load_op(base, rt, offset + size); + list_add_tail(&op->list, ops_list); + } + + if (aarch64_insn_is_load_pre(insn) || aarch64_insn_is_ldp_pre(insn) || + aarch64_insn_is_load_post(insn) || aarch64_insn_is_ldp_post(insn)) { + op = arm_make_add_op(base, base, *immediate); + list_add_tail(&op->list, ops_list); + } + + return true; +} + static void arm_decode_add_sub_imm(u32 instr, bool set_flags, enum insn_type *type, unsigned long *immediate, @@ -234,6 +356,11 @@ int arch_decode_instruction(const struct elf *elf, const struct section *sec, *type = INSN_OTHER; } break; + case AARCH64_INSN_CLS_LDST: + if (arm_decode_load_store(insn, type, immediate, ops_list)) + break; + *type = INSN_OTHER; + break; default: *type = INSN_OTHER; break; -- 2.25.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 09/17] objtool: arm64: Decode LDR instructions 2021-01-20 17:37 ` Julien Thierry @ 2021-01-20 17:37 ` Julien Thierry -1 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: catalin.marinas, will, ardb, masahiroy, keescook, michal.lkml, jpoimboe, peterz, mark.rutland, broonie, linux-efi, linux-hardening, Julien Thierry Load literal instructions can generate constants inside code sections. Record the locations of the constants in order to be able to remove their corresponding "struct instruction". Signed-off-by: Julien Thierry <jthierry@redhat.com> --- tools/objtool/arch/arm64/decode.c | 86 ++++++++++++++++++++++++++++ tools/objtool/arch/x86/decode.c | 5 ++ tools/objtool/check.c | 3 + tools/objtool/include/objtool/arch.h | 3 + 4 files changed, 97 insertions(+) diff --git a/tools/objtool/arch/arm64/decode.c b/tools/objtool/arch/arm64/decode.c index 1087ede67bcd..b4d4d5b051b0 100644 --- a/tools/objtool/arch/arm64/decode.c +++ b/tools/objtool/arch/arm64/decode.c @@ -30,6 +30,73 @@ static unsigned long sign_extend(unsigned long x, int nbits) return ((~0UL + (sign_bit ^ 1)) << nbits) | x; } +struct insn_loc { + const struct section *sec; + unsigned long offset; + struct hlist_node hnode; + bool ignorable; +}; + +DEFINE_HASHTABLE(invalid_insns, 16); + +static int record_invalid_insn(const struct section *sec, + unsigned long offset, + bool ignore) +{ + struct insn_loc *loc; + struct hlist_head *l; + + l = &invalid_insns[hash_min(offset, HASH_BITS(invalid_insns))]; + if (!hlist_empty(l)) { + loc = hlist_entry(l->first, struct insn_loc, hnode); + loc->ignorable |= ignore; + return 0; + } + + loc = malloc(sizeof(*loc)); + if (!loc) { + WARN("malloc failed"); + return -1; + } + + loc->sec = sec; + loc->offset = offset; + loc->ignorable = ignore; + + hash_add(invalid_insns, &loc->hnode, loc->offset); + + return 0; +} + +int arch_post_process_instructions(struct objtool_file *file) +{ + struct hlist_node *tmp; + struct insn_loc *loc; + unsigned int bkt; + int res = 0; + + hash_for_each_safe(invalid_insns, bkt, tmp, loc, hnode) { + struct instruction *insn; + + insn = find_insn(file, (struct section *) loc->sec, loc->offset); + if (insn) { + if (loc->ignorable) { + list_del(&insn->list); + hash_del(&insn->hash); + free(insn); + } else { + WARN_FUNC("can't decode instruction", insn->sec, insn->offset); + return -1; + } + } + + hash_del(&loc->hnode); + free(loc); + } + + return res; +} + bool arch_callee_saved_reg(unsigned char reg) { switch (reg) { @@ -359,6 +426,25 @@ int arch_decode_instruction(const struct elf *elf, const struct section *sec, case AARCH64_INSN_CLS_LDST: if (arm_decode_load_store(insn, type, immediate, ops_list)) break; + if (aarch64_insn_is_ldr_lit(insn)) { + long pc_offset; + + pc_offset = insn & GENMASK(23, 5); + /* Sign extend and multiply by 4 */ + pc_offset = (pc_offset << (64 - 23)); + pc_offset = ((pc_offset >> (64 - 23)) >> 5) << 2; + + if (record_invalid_insn(sec, offset + pc_offset, true)) + return -1; + + /* 64-bit literal */ + if (insn & BIT(30)) { + if (record_invalid_insn(sec, + offset + pc_offset + 4, + true)) + return -1; + } + } *type = INSN_OTHER; break; default: diff --git a/tools/objtool/arch/x86/decode.c b/tools/objtool/arch/x86/decode.c index 6baa22732ca6..e76d987ce3c7 100644 --- a/tools/objtool/arch/x86/decode.c +++ b/tools/objtool/arch/x86/decode.c @@ -549,6 +549,11 @@ int arch_decode_instruction(const struct elf *elf, const struct section *sec, return 0; } +int arch_post_process_instructions(struct objtool_file *file) +{ + return 0; +} + void arch_initial_func_cfi_state(struct cfi_init_state *state) { int i; diff --git a/tools/objtool/check.c b/tools/objtool/check.c index 270b507e7098..d902697a388e 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -319,6 +319,9 @@ static int decode_instructions(struct objtool_file *file) if (stats) printf("nr_insns: %lu\n", nr_insns); + if (arch_post_process_instructions(file)) + return -1; + return 0; err: diff --git a/tools/objtool/include/objtool/arch.h b/tools/objtool/include/objtool/arch.h index 6ff0685f5cc5..456d0465b676 100644 --- a/tools/objtool/include/objtool/arch.h +++ b/tools/objtool/include/objtool/arch.h @@ -66,6 +66,7 @@ struct stack_op { struct list_head list; }; +struct objtool_file; struct instruction; void arch_initial_func_cfi_state(struct cfi_init_state *state); @@ -76,6 +77,8 @@ int arch_decode_instruction(const struct elf *elf, const struct section *sec, unsigned long *immediate, struct list_head *ops_list); +int arch_post_process_instructions(struct objtool_file *file); + bool arch_callee_saved_reg(unsigned char reg); unsigned long arch_jump_destination(struct instruction *insn); -- 2.25.4 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 09/17] objtool: arm64: Decode LDR instructions @ 2021-01-20 17:37 ` Julien Thierry 0 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: mark.rutland, linux-efi, michal.lkml, keescook, peterz, catalin.marinas, masahiroy, broonie, linux-hardening, jpoimboe, will, ardb, Julien Thierry Load literal instructions can generate constants inside code sections. Record the locations of the constants in order to be able to remove their corresponding "struct instruction". Signed-off-by: Julien Thierry <jthierry@redhat.com> --- tools/objtool/arch/arm64/decode.c | 86 ++++++++++++++++++++++++++++ tools/objtool/arch/x86/decode.c | 5 ++ tools/objtool/check.c | 3 + tools/objtool/include/objtool/arch.h | 3 + 4 files changed, 97 insertions(+) diff --git a/tools/objtool/arch/arm64/decode.c b/tools/objtool/arch/arm64/decode.c index 1087ede67bcd..b4d4d5b051b0 100644 --- a/tools/objtool/arch/arm64/decode.c +++ b/tools/objtool/arch/arm64/decode.c @@ -30,6 +30,73 @@ static unsigned long sign_extend(unsigned long x, int nbits) return ((~0UL + (sign_bit ^ 1)) << nbits) | x; } +struct insn_loc { + const struct section *sec; + unsigned long offset; + struct hlist_node hnode; + bool ignorable; +}; + +DEFINE_HASHTABLE(invalid_insns, 16); + +static int record_invalid_insn(const struct section *sec, + unsigned long offset, + bool ignore) +{ + struct insn_loc *loc; + struct hlist_head *l; + + l = &invalid_insns[hash_min(offset, HASH_BITS(invalid_insns))]; + if (!hlist_empty(l)) { + loc = hlist_entry(l->first, struct insn_loc, hnode); + loc->ignorable |= ignore; + return 0; + } + + loc = malloc(sizeof(*loc)); + if (!loc) { + WARN("malloc failed"); + return -1; + } + + loc->sec = sec; + loc->offset = offset; + loc->ignorable = ignore; + + hash_add(invalid_insns, &loc->hnode, loc->offset); + + return 0; +} + +int arch_post_process_instructions(struct objtool_file *file) +{ + struct hlist_node *tmp; + struct insn_loc *loc; + unsigned int bkt; + int res = 0; + + hash_for_each_safe(invalid_insns, bkt, tmp, loc, hnode) { + struct instruction *insn; + + insn = find_insn(file, (struct section *) loc->sec, loc->offset); + if (insn) { + if (loc->ignorable) { + list_del(&insn->list); + hash_del(&insn->hash); + free(insn); + } else { + WARN_FUNC("can't decode instruction", insn->sec, insn->offset); + return -1; + } + } + + hash_del(&loc->hnode); + free(loc); + } + + return res; +} + bool arch_callee_saved_reg(unsigned char reg) { switch (reg) { @@ -359,6 +426,25 @@ int arch_decode_instruction(const struct elf *elf, const struct section *sec, case AARCH64_INSN_CLS_LDST: if (arm_decode_load_store(insn, type, immediate, ops_list)) break; + if (aarch64_insn_is_ldr_lit(insn)) { + long pc_offset; + + pc_offset = insn & GENMASK(23, 5); + /* Sign extend and multiply by 4 */ + pc_offset = (pc_offset << (64 - 23)); + pc_offset = ((pc_offset >> (64 - 23)) >> 5) << 2; + + if (record_invalid_insn(sec, offset + pc_offset, true)) + return -1; + + /* 64-bit literal */ + if (insn & BIT(30)) { + if (record_invalid_insn(sec, + offset + pc_offset + 4, + true)) + return -1; + } + } *type = INSN_OTHER; break; default: diff --git a/tools/objtool/arch/x86/decode.c b/tools/objtool/arch/x86/decode.c index 6baa22732ca6..e76d987ce3c7 100644 --- a/tools/objtool/arch/x86/decode.c +++ b/tools/objtool/arch/x86/decode.c @@ -549,6 +549,11 @@ int arch_decode_instruction(const struct elf *elf, const struct section *sec, return 0; } +int arch_post_process_instructions(struct objtool_file *file) +{ + return 0; +} + void arch_initial_func_cfi_state(struct cfi_init_state *state) { int i; diff --git a/tools/objtool/check.c b/tools/objtool/check.c index 270b507e7098..d902697a388e 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -319,6 +319,9 @@ static int decode_instructions(struct objtool_file *file) if (stats) printf("nr_insns: %lu\n", nr_insns); + if (arch_post_process_instructions(file)) + return -1; + return 0; err: diff --git a/tools/objtool/include/objtool/arch.h b/tools/objtool/include/objtool/arch.h index 6ff0685f5cc5..456d0465b676 100644 --- a/tools/objtool/include/objtool/arch.h +++ b/tools/objtool/include/objtool/arch.h @@ -66,6 +66,7 @@ struct stack_op { struct list_head list; }; +struct objtool_file; struct instruction; void arch_initial_func_cfi_state(struct cfi_init_state *state); @@ -76,6 +77,8 @@ int arch_decode_instruction(const struct elf *elf, const struct section *sec, unsigned long *immediate, struct list_head *ops_list); +int arch_post_process_instructions(struct objtool_file *file); + bool arch_callee_saved_reg(unsigned char reg); unsigned long arch_jump_destination(struct instruction *insn); -- 2.25.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 10/17] objtool: arm64: Accept padding in code sections 2021-01-20 17:37 ` Julien Thierry @ 2021-01-20 17:37 ` Julien Thierry -1 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: catalin.marinas, will, ardb, masahiroy, keescook, michal.lkml, jpoimboe, peterz, mark.rutland, broonie, linux-efi, linux-hardening, Julien Thierry The compiler can introduce some '0' words in code sections to pad the end of functions. Similar to load literal functions, record these zero words to remove the "struct instruction" created for them. Signed-off-by: Julien Thierry <jthierry@redhat.com> --- tools/objtool/arch/arm64/decode.c | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/tools/objtool/arch/arm64/decode.c b/tools/objtool/arch/arm64/decode.c index b4d4d5b051b0..ed5ef0b52bbe 100644 --- a/tools/objtool/arch/arm64/decode.c +++ b/tools/objtool/arch/arm64/decode.c @@ -362,8 +362,23 @@ int arch_decode_instruction(const struct elf *elf, const struct section *sec, switch (aarch64_get_insn_class(insn)) { case AARCH64_INSN_CLS_UNKNOWN: - WARN("can't decode instruction at %s:0x%lx", sec->name, offset); - return -1; + { + /* + * There are a few reasons we might have non-valid opcodes in + * code sections: + * - For load literal, assembler can generate the data to be + * loaded in the code section + * - Compiler/assembler can generate zeroes to pad function that + * do not end on 8-byte alignment + */ + /* Compiler might put zeroes as padding */ + if (record_invalid_insn(sec, offset, insn == 0x0)) + return -1; + + *type = INSN_OTHER; + + break; + } case AARCH64_INSN_CLS_DP_IMM: /* Mov register to and from SP are aliases of add_imm */ if (aarch64_insn_is_add_imm(insn) || -- 2.25.4 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 10/17] objtool: arm64: Accept padding in code sections @ 2021-01-20 17:37 ` Julien Thierry 0 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: mark.rutland, linux-efi, michal.lkml, keescook, peterz, catalin.marinas, masahiroy, broonie, linux-hardening, jpoimboe, will, ardb, Julien Thierry The compiler can introduce some '0' words in code sections to pad the end of functions. Similar to load literal functions, record these zero words to remove the "struct instruction" created for them. Signed-off-by: Julien Thierry <jthierry@redhat.com> --- tools/objtool/arch/arm64/decode.c | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/tools/objtool/arch/arm64/decode.c b/tools/objtool/arch/arm64/decode.c index b4d4d5b051b0..ed5ef0b52bbe 100644 --- a/tools/objtool/arch/arm64/decode.c +++ b/tools/objtool/arch/arm64/decode.c @@ -362,8 +362,23 @@ int arch_decode_instruction(const struct elf *elf, const struct section *sec, switch (aarch64_get_insn_class(insn)) { case AARCH64_INSN_CLS_UNKNOWN: - WARN("can't decode instruction at %s:0x%lx", sec->name, offset); - return -1; + { + /* + * There are a few reasons we might have non-valid opcodes in + * code sections: + * - For load literal, assembler can generate the data to be + * loaded in the code section + * - Compiler/assembler can generate zeroes to pad function that + * do not end on 8-byte alignment + */ + /* Compiler might put zeroes as padding */ + if (record_invalid_insn(sec, offset, insn == 0x0)) + return -1; + + *type = INSN_OTHER; + + break; + } case AARCH64_INSN_CLS_DP_IMM: /* Mov register to and from SP are aliases of add_imm */ if (aarch64_insn_is_add_imm(insn) || -- 2.25.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 11/17] efi: libstub: Ignore relocations for .discard sections 2021-01-20 17:37 ` Julien Thierry @ 2021-01-20 17:37 ` Julien Thierry -1 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: catalin.marinas, will, ardb, masahiroy, keescook, michal.lkml, jpoimboe, peterz, mark.rutland, broonie, linux-efi, linux-hardening, Julien Thierry EFI stub cannot have absolute relocations in sections affecting the execution flow. However, for sections that get discarded at link time, it doesn't really matter if they have absolute relocations. Ignore the relocation associated with such sections. Signed-off-by: Julien Thierry <jthierry@redhat.com> --- drivers/firmware/efi/libstub/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile index 8a94388e38b3..70e9c7f45d30 100644 --- a/drivers/firmware/efi/libstub/Makefile +++ b/drivers/firmware/efi/libstub/Makefile @@ -133,7 +133,7 @@ $(obj)/%.stub.o: $(obj)/%.o FORCE # quiet_cmd_stubcopy = STUBCPY $@ cmd_stubcopy = \ - $(STRIP) --strip-debug -o $@ $<; \ + $(STRIP) --strip-debug --remove-relocations=".discard.*" -o $@ $<; \ if $(OBJDUMP) -r $@ | grep $(STUBCOPY_RELOC-y); then \ echo "$@: absolute symbol references not allowed in the EFI stub" >&2; \ /bin/false; \ -- 2.25.4 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 11/17] efi: libstub: Ignore relocations for .discard sections @ 2021-01-20 17:37 ` Julien Thierry 0 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: mark.rutland, linux-efi, michal.lkml, keescook, peterz, catalin.marinas, masahiroy, broonie, linux-hardening, jpoimboe, will, ardb, Julien Thierry EFI stub cannot have absolute relocations in sections affecting the execution flow. However, for sections that get discarded at link time, it doesn't really matter if they have absolute relocations. Ignore the relocation associated with such sections. Signed-off-by: Julien Thierry <jthierry@redhat.com> --- drivers/firmware/efi/libstub/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile index 8a94388e38b3..70e9c7f45d30 100644 --- a/drivers/firmware/efi/libstub/Makefile +++ b/drivers/firmware/efi/libstub/Makefile @@ -133,7 +133,7 @@ $(obj)/%.stub.o: $(obj)/%.o FORCE # quiet_cmd_stubcopy = STUBCPY $@ cmd_stubcopy = \ - $(STRIP) --strip-debug -o $@ $<; \ + $(STRIP) --strip-debug --remove-relocations=".discard.*" -o $@ $<; \ if $(OBJDUMP) -r $@ | grep $(STUBCOPY_RELOC-y); then \ echo "$@: absolute symbol references not allowed in the EFI stub" >&2; \ /bin/false; \ -- 2.25.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 2021-01-20 17:37 ` Julien Thierry @ 2021-01-20 17:37 ` Julien Thierry -1 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: catalin.marinas, will, ardb, masahiroy, keescook, michal.lkml, jpoimboe, peterz, mark.rutland, broonie, linux-efi, linux-hardening, Raphael Gault, Julien Thierry From: Raphael Gault <raphael.gault@arm.com> This plugins comes into play before the final 2 RTL passes of GCC and detects switch-tables that are to be outputed in the ELF and writes information in an ".discard.switch_table_info" section which will be used by objtool. Signed-off-by: Raphael Gault <raphael.gault@arm.com> [J.T.: Change section name to store switch table information, Make plugin Kconfig be selected rather than opt-in by user, Add a relocation in the switch_table_info that points to the jump operation itself] Signed-off-by: Julien Thierry <jthierry@redhat.com> --- arch/arm64/Kconfig | 1 + scripts/Makefile.gcc-plugins | 2 + scripts/gcc-plugins/Kconfig | 4 + .../arm64_switch_table_detection_plugin.c | 85 +++++++++++++++++++ 4 files changed, 92 insertions(+) create mode 100644 scripts/gcc-plugins/arm64_switch_table_detection_plugin.c diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 05e17351e4f3..93a320cc8e03 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -100,6 +100,7 @@ config ARM64 select DMA_DIRECT_REMAP select EDAC_SUPPORT select FRAME_POINTER + select GCC_PLUGIN_SWITCH_TABLES if STACK_VALIDATION select GENERIC_ALLOCATOR select GENERIC_ARCH_TOPOLOGY select GENERIC_CLOCKEVENTS_BROADCAST diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins index 952e46876329..8af322311f6b 100644 --- a/scripts/Makefile.gcc-plugins +++ b/scripts/Makefile.gcc-plugins @@ -46,6 +46,8 @@ ifdef CONFIG_GCC_PLUGIN_ARM_SSP_PER_TASK endif export DISABLE_ARM_SSP_PER_TASK_PLUGIN +gcc-plugin-$(CONFIG_GCC_PLUGIN_SWITCH_TABLES) += arm64_switch_table_detection_plugin.so + # All the plugin CFLAGS are collected here in case a build target needs to # filter them out of the KBUILD_CFLAGS. GCC_PLUGINS_CFLAGS := $(strip $(addprefix -fplugin=$(objtree)/scripts/gcc-plugins/, $(gcc-plugin-y)) $(gcc-plugin-cflags-y)) diff --git a/scripts/gcc-plugins/Kconfig b/scripts/gcc-plugins/Kconfig index ab9eb4cbe33a..76efbb97d223 100644 --- a/scripts/gcc-plugins/Kconfig +++ b/scripts/gcc-plugins/Kconfig @@ -104,4 +104,8 @@ config GCC_PLUGIN_ARM_SSP_PER_TASK bool depends on GCC_PLUGINS && ARM +config GCC_PLUGIN_SWITCH_TABLES + bool + depends on GCC_PLUGINS && ARM64 + endif diff --git a/scripts/gcc-plugins/arm64_switch_table_detection_plugin.c b/scripts/gcc-plugins/arm64_switch_table_detection_plugin.c new file mode 100644 index 000000000000..60ef00ff2c5b --- /dev/null +++ b/scripts/gcc-plugins/arm64_switch_table_detection_plugin.c @@ -0,0 +1,85 @@ +// SPDX-License-Identifier: GPL-2.0 + +#include <stdio.h> +#include "gcc-common.h" + +__visible int plugin_is_GPL_compatible; + +#define GEN_QUAD(rtx) assemble_integer_with_op(".quad ", rtx) + +/* + * Create an array of metadata for each jump table found in the rtl. + * The metadata contains: + * - A reference to first instruction part of the RTL expanded into an + * acutal jump + * - The number of entries in the table of offsets + * - A reference to each possible jump target + * + * Separate each entry with a null quad word. + */ +static unsigned int arm64_switchtbl_rtl_execute(void) +{ + rtx_insn *insn; + rtx_insn *labelp = NULL; + rtx_jump_table_data *tablep = NULL; + section *swt_sec; + section *curr_sec = current_function_section(); + + swt_sec = get_section(".discard.switch_table_info", + SECTION_DEBUG | SECTION_EXCLUDE, NULL); + + for (insn = get_insns(); insn; insn = NEXT_INSN(insn)) { + /* + * Find a tablejump_p INSN (using a dispatch table) + */ + if (!tablejump_p(insn, &labelp, &tablep)) + continue; + + if (labelp && tablep) { + rtx_code_label *label_to_jump; + rtvec jump_labels = tablep->get_labels(); + int nr_labels = GET_NUM_ELEM(jump_labels); + int i; + + label_to_jump = gen_label_rtx(); + SET_LABEL_KIND(label_to_jump, LABEL_NORMAL); + emit_label_before(label_to_jump, insn); + LABEL_PRESERVE_P(label_to_jump) = 1; + + switch_to_section(swt_sec); + GEN_QUAD(GEN_INT(0)); // mark separation between rela tables + GEN_QUAD(gen_rtx_LABEL_REF(Pmode, label_to_jump)); + GEN_QUAD(GEN_INT(nr_labels)); + for (i = 0; i < nr_labels; i++) + GEN_QUAD(gen_rtx_LABEL_REF(Pmode, + label_ref_label(RTVEC_ELT(jump_labels, i)))); + switch_to_section(curr_sec); + delete_insn(label_to_jump); + } + } + return 0; +} + +#define PASS_NAME arm64_switchtbl_rtl + +#define NO_GATE +#include "gcc-generate-rtl-pass.h" + +__visible int plugin_init(struct plugin_name_args *plugin_info, + struct plugin_gcc_version *version) +{ + const char * const plugin_name = plugin_info->base_name; + + if (!plugin_default_version_check(version, &gcc_version)) { + error(G_("incompatible gcc/plugin versions")); + return 1; + } + + PASS_INFO(arm64_switchtbl_rtl, "final", 1, + PASS_POS_INSERT_BEFORE); + + register_callback(plugin_info->base_name, PLUGIN_PASS_MANAGER_SETUP, + NULL, &arm64_switchtbl_rtl_pass_info); + + return 0; +} -- 2.25.4 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 @ 2021-01-20 17:37 ` Julien Thierry 0 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: mark.rutland, linux-efi, michal.lkml, keescook, peterz, catalin.marinas, masahiroy, Raphael Gault, broonie, linux-hardening, jpoimboe, will, ardb, Julien Thierry From: Raphael Gault <raphael.gault@arm.com> This plugins comes into play before the final 2 RTL passes of GCC and detects switch-tables that are to be outputed in the ELF and writes information in an ".discard.switch_table_info" section which will be used by objtool. Signed-off-by: Raphael Gault <raphael.gault@arm.com> [J.T.: Change section name to store switch table information, Make plugin Kconfig be selected rather than opt-in by user, Add a relocation in the switch_table_info that points to the jump operation itself] Signed-off-by: Julien Thierry <jthierry@redhat.com> --- arch/arm64/Kconfig | 1 + scripts/Makefile.gcc-plugins | 2 + scripts/gcc-plugins/Kconfig | 4 + .../arm64_switch_table_detection_plugin.c | 85 +++++++++++++++++++ 4 files changed, 92 insertions(+) create mode 100644 scripts/gcc-plugins/arm64_switch_table_detection_plugin.c diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 05e17351e4f3..93a320cc8e03 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -100,6 +100,7 @@ config ARM64 select DMA_DIRECT_REMAP select EDAC_SUPPORT select FRAME_POINTER + select GCC_PLUGIN_SWITCH_TABLES if STACK_VALIDATION select GENERIC_ALLOCATOR select GENERIC_ARCH_TOPOLOGY select GENERIC_CLOCKEVENTS_BROADCAST diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins index 952e46876329..8af322311f6b 100644 --- a/scripts/Makefile.gcc-plugins +++ b/scripts/Makefile.gcc-plugins @@ -46,6 +46,8 @@ ifdef CONFIG_GCC_PLUGIN_ARM_SSP_PER_TASK endif export DISABLE_ARM_SSP_PER_TASK_PLUGIN +gcc-plugin-$(CONFIG_GCC_PLUGIN_SWITCH_TABLES) += arm64_switch_table_detection_plugin.so + # All the plugin CFLAGS are collected here in case a build target needs to # filter them out of the KBUILD_CFLAGS. GCC_PLUGINS_CFLAGS := $(strip $(addprefix -fplugin=$(objtree)/scripts/gcc-plugins/, $(gcc-plugin-y)) $(gcc-plugin-cflags-y)) diff --git a/scripts/gcc-plugins/Kconfig b/scripts/gcc-plugins/Kconfig index ab9eb4cbe33a..76efbb97d223 100644 --- a/scripts/gcc-plugins/Kconfig +++ b/scripts/gcc-plugins/Kconfig @@ -104,4 +104,8 @@ config GCC_PLUGIN_ARM_SSP_PER_TASK bool depends on GCC_PLUGINS && ARM +config GCC_PLUGIN_SWITCH_TABLES + bool + depends on GCC_PLUGINS && ARM64 + endif diff --git a/scripts/gcc-plugins/arm64_switch_table_detection_plugin.c b/scripts/gcc-plugins/arm64_switch_table_detection_plugin.c new file mode 100644 index 000000000000..60ef00ff2c5b --- /dev/null +++ b/scripts/gcc-plugins/arm64_switch_table_detection_plugin.c @@ -0,0 +1,85 @@ +// SPDX-License-Identifier: GPL-2.0 + +#include <stdio.h> +#include "gcc-common.h" + +__visible int plugin_is_GPL_compatible; + +#define GEN_QUAD(rtx) assemble_integer_with_op(".quad ", rtx) + +/* + * Create an array of metadata for each jump table found in the rtl. + * The metadata contains: + * - A reference to first instruction part of the RTL expanded into an + * acutal jump + * - The number of entries in the table of offsets + * - A reference to each possible jump target + * + * Separate each entry with a null quad word. + */ +static unsigned int arm64_switchtbl_rtl_execute(void) +{ + rtx_insn *insn; + rtx_insn *labelp = NULL; + rtx_jump_table_data *tablep = NULL; + section *swt_sec; + section *curr_sec = current_function_section(); + + swt_sec = get_section(".discard.switch_table_info", + SECTION_DEBUG | SECTION_EXCLUDE, NULL); + + for (insn = get_insns(); insn; insn = NEXT_INSN(insn)) { + /* + * Find a tablejump_p INSN (using a dispatch table) + */ + if (!tablejump_p(insn, &labelp, &tablep)) + continue; + + if (labelp && tablep) { + rtx_code_label *label_to_jump; + rtvec jump_labels = tablep->get_labels(); + int nr_labels = GET_NUM_ELEM(jump_labels); + int i; + + label_to_jump = gen_label_rtx(); + SET_LABEL_KIND(label_to_jump, LABEL_NORMAL); + emit_label_before(label_to_jump, insn); + LABEL_PRESERVE_P(label_to_jump) = 1; + + switch_to_section(swt_sec); + GEN_QUAD(GEN_INT(0)); // mark separation between rela tables + GEN_QUAD(gen_rtx_LABEL_REF(Pmode, label_to_jump)); + GEN_QUAD(GEN_INT(nr_labels)); + for (i = 0; i < nr_labels; i++) + GEN_QUAD(gen_rtx_LABEL_REF(Pmode, + label_ref_label(RTVEC_ELT(jump_labels, i)))); + switch_to_section(curr_sec); + delete_insn(label_to_jump); + } + } + return 0; +} + +#define PASS_NAME arm64_switchtbl_rtl + +#define NO_GATE +#include "gcc-generate-rtl-pass.h" + +__visible int plugin_init(struct plugin_name_args *plugin_info, + struct plugin_gcc_version *version) +{ + const char * const plugin_name = plugin_info->base_name; + + if (!plugin_default_version_check(version, &gcc_version)) { + error(G_("incompatible gcc/plugin versions")); + return 1; + } + + PASS_INFO(arm64_switchtbl_rtl, "final", 1, + PASS_POS_INSERT_BEFORE); + + register_callback(plugin_info->base_name, PLUGIN_PASS_MANAGER_SETUP, + NULL, &arm64_switchtbl_rtl_pass_info); + + return 0; +} -- 2.25.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 2021-01-20 17:37 ` Julien Thierry @ 2021-01-27 22:15 ` Nick Desaulniers -1 siblings, 0 replies; 106+ messages in thread From: Nick Desaulniers @ 2021-01-27 22:15 UTC (permalink / raw) To: jthierry Cc: ardb, broonie, catalin.marinas, jpoimboe, keescook, linux-arm-kernel, linux-efi, linux-hardening, linux-kernel, mark.rutland, masahiroy, michal.lkml, peterz, raphael.gault, will, clang-built-linux > From: Raphael Gault <raphael.gault@arm.com> > > This plugins comes into play before the final 2 RTL passes of GCC and > detects switch-tables that are to be outputed in the ELF and writes > information in an ".discard.switch_table_info" section which will be > used by objtool. > > Signed-off-by: Raphael Gault <raphael.gault@arm.com> > [J.T.: Change section name to store switch table information, > Make plugin Kconfig be selected rather than opt-in by user, > Add a relocation in the switch_table_info that points to > the jump operation itself] > Signed-off-by: Julien Thierry <jthierry@redhat.com> Rather than tightly couple this feature to a particular toolchain via plugin, it might be nice to consider what features could be spec'ed out for toolchains to implement (perhaps via a -f flag). Distributions (like Android, CrOS) wont be able to use such a feature as is. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 @ 2021-01-27 22:15 ` Nick Desaulniers 0 siblings, 0 replies; 106+ messages in thread From: Nick Desaulniers @ 2021-01-27 22:15 UTC (permalink / raw) To: jthierry Cc: mark.rutland, linux-efi, keescook, clang-built-linux, peterz, catalin.marinas, masahiroy, linux-kernel, michal.lkml, raphael.gault, broonie, linux-hardening, jpoimboe, will, ardb, linux-arm-kernel > From: Raphael Gault <raphael.gault@arm.com> > > This plugins comes into play before the final 2 RTL passes of GCC and > detects switch-tables that are to be outputed in the ELF and writes > information in an ".discard.switch_table_info" section which will be > used by objtool. > > Signed-off-by: Raphael Gault <raphael.gault@arm.com> > [J.T.: Change section name to store switch table information, > Make plugin Kconfig be selected rather than opt-in by user, > Add a relocation in the switch_table_info that points to > the jump operation itself] > Signed-off-by: Julien Thierry <jthierry@redhat.com> Rather than tightly couple this feature to a particular toolchain via plugin, it might be nice to consider what features could be spec'ed out for toolchains to implement (perhaps via a -f flag). Distributions (like Android, CrOS) wont be able to use such a feature as is. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 2021-01-27 22:15 ` Nick Desaulniers @ 2021-01-27 23:26 ` Josh Poimboeuf -1 siblings, 0 replies; 106+ messages in thread From: Josh Poimboeuf @ 2021-01-27 23:26 UTC (permalink / raw) To: Nick Desaulniers Cc: jthierry, ardb, broonie, catalin.marinas, keescook, linux-arm-kernel, linux-efi, linux-hardening, linux-kernel, mark.rutland, masahiroy, michal.lkml, peterz, raphael.gault, will, clang-built-linux On Wed, Jan 27, 2021 at 02:15:57PM -0800, Nick Desaulniers wrote: > > From: Raphael Gault <raphael.gault@arm.com> > > > > This plugins comes into play before the final 2 RTL passes of GCC and > > detects switch-tables that are to be outputed in the ELF and writes > > information in an ".discard.switch_table_info" section which will be > > used by objtool. > > > > Signed-off-by: Raphael Gault <raphael.gault@arm.com> > > [J.T.: Change section name to store switch table information, > > Make plugin Kconfig be selected rather than opt-in by user, > > Add a relocation in the switch_table_info that points to > > the jump operation itself] > > Signed-off-by: Julien Thierry <jthierry@redhat.com> > > Rather than tightly couple this feature to a particular toolchain via > plugin, it might be nice to consider what features could be spec'ed out > for toolchains to implement (perhaps via a -f flag). The problem is being able to detect switch statement jump table vectors. For a given indirect branch (due to a switch statement), what are all the corresponding jump targets? We would need the compiler to annotate that information somehow. > Distributions (like Android, CrOS) wont be able to use such a feature as > is. Would a Clang plugin be out of the question? -- Josh ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 @ 2021-01-27 23:26 ` Josh Poimboeuf 0 siblings, 0 replies; 106+ messages in thread From: Josh Poimboeuf @ 2021-01-27 23:26 UTC (permalink / raw) To: Nick Desaulniers Cc: mark.rutland, linux-efi, jthierry, clang-built-linux, peterz, catalin.marinas, masahiroy, linux-kernel, michal.lkml, raphael.gault, broonie, linux-hardening, will, ardb, linux-arm-kernel, keescook On Wed, Jan 27, 2021 at 02:15:57PM -0800, Nick Desaulniers wrote: > > From: Raphael Gault <raphael.gault@arm.com> > > > > This plugins comes into play before the final 2 RTL passes of GCC and > > detects switch-tables that are to be outputed in the ELF and writes > > information in an ".discard.switch_table_info" section which will be > > used by objtool. > > > > Signed-off-by: Raphael Gault <raphael.gault@arm.com> > > [J.T.: Change section name to store switch table information, > > Make plugin Kconfig be selected rather than opt-in by user, > > Add a relocation in the switch_table_info that points to > > the jump operation itself] > > Signed-off-by: Julien Thierry <jthierry@redhat.com> > > Rather than tightly couple this feature to a particular toolchain via > plugin, it might be nice to consider what features could be spec'ed out > for toolchains to implement (perhaps via a -f flag). The problem is being able to detect switch statement jump table vectors. For a given indirect branch (due to a switch statement), what are all the corresponding jump targets? We would need the compiler to annotate that information somehow. > Distributions (like Android, CrOS) wont be able to use such a feature as > is. Would a Clang plugin be out of the question? -- Josh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 2021-01-27 23:26 ` Josh Poimboeuf @ 2021-01-29 18:10 ` Nick Desaulniers -1 siblings, 0 replies; 106+ messages in thread From: Nick Desaulniers @ 2021-01-29 18:10 UTC (permalink / raw) To: Josh Poimboeuf Cc: Julien Thierry, Ard Biesheuvel, Mark Brown, Catalin Marinas, Kees Cook, Linux ARM, linux-efi, linux-hardening, LKML, Mark Rutland, Masahiro Yamada, Michal Marek, Peter Zijlstra, raphael.gault, Will Deacon, clang-built-linux On Wed, Jan 27, 2021 at 3:27 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > On Wed, Jan 27, 2021 at 02:15:57PM -0800, Nick Desaulniers wrote: > > > From: Raphael Gault <raphael.gault@arm.com> > > > > > > This plugins comes into play before the final 2 RTL passes of GCC and > > > detects switch-tables that are to be outputed in the ELF and writes > > > information in an ".discard.switch_table_info" section which will be > > > used by objtool. > > > > > > Signed-off-by: Raphael Gault <raphael.gault@arm.com> > > > [J.T.: Change section name to store switch table information, > > > Make plugin Kconfig be selected rather than opt-in by user, > > > Add a relocation in the switch_table_info that points to > > > the jump operation itself] > > > Signed-off-by: Julien Thierry <jthierry@redhat.com> > > > > Rather than tightly couple this feature to a particular toolchain via > > plugin, it might be nice to consider what features could be spec'ed out > > for toolchains to implement (perhaps via a -f flag). > > The problem is being able to detect switch statement jump table vectors. > > For a given indirect branch (due to a switch statement), what are all > the corresponding jump targets? > > We would need the compiler to annotate that information somehow. Makes sense, the compiler should have this information. How is this problem solved on x86? > > > Distributions (like Android, CrOS) wont be able to use such a feature as > > is. > > Would a Clang plugin be out of the question? Generally, we frown on out of tree kernel modules for a couple reasons. Maintaining ABI compatibility when the core kernel changes is generally not instantaneous; someone has to notice the ABI has changed which will be more delayed than if the module was in tree. Worse is when semantics subtly change. While we must not break userspace, we provide no such guarantees within the kernel proper. Also, it's less likely that out of tree kernel modules have been reviewed by kernel developers. They may not have the same quality, use the recommended interfaces, follow coding conventions, etc.. Oh, did I say "out of tree kernel modules?" I meant "compiler plugins." But it's two different sides of the same coin to me. FWIW, I think the approach taken by -mstack-protector-guard-reg= is a useful case study. It was prototyped as a GCC extension, then added to GCC proper, then added to LLVM (currently only x86, but most of the machinery is in place in the compiler to get it running on arm64). My recommendation is to skip the plugin part and work on a standard interface for compilers to implement, with input from compiler developers. -- Thanks, ~Nick Desaulniers ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 @ 2021-01-29 18:10 ` Nick Desaulniers 0 siblings, 0 replies; 106+ messages in thread From: Nick Desaulniers @ 2021-01-29 18:10 UTC (permalink / raw) To: Josh Poimboeuf Cc: Mark Rutland, linux-efi, Julien Thierry, clang-built-linux, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, LKML, Michal Marek, raphael.gault, Mark Brown, linux-hardening, Will Deacon, Ard Biesheuvel, Linux ARM, Kees Cook On Wed, Jan 27, 2021 at 3:27 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > On Wed, Jan 27, 2021 at 02:15:57PM -0800, Nick Desaulniers wrote: > > > From: Raphael Gault <raphael.gault@arm.com> > > > > > > This plugins comes into play before the final 2 RTL passes of GCC and > > > detects switch-tables that are to be outputed in the ELF and writes > > > information in an ".discard.switch_table_info" section which will be > > > used by objtool. > > > > > > Signed-off-by: Raphael Gault <raphael.gault@arm.com> > > > [J.T.: Change section name to store switch table information, > > > Make plugin Kconfig be selected rather than opt-in by user, > > > Add a relocation in the switch_table_info that points to > > > the jump operation itself] > > > Signed-off-by: Julien Thierry <jthierry@redhat.com> > > > > Rather than tightly couple this feature to a particular toolchain via > > plugin, it might be nice to consider what features could be spec'ed out > > for toolchains to implement (perhaps via a -f flag). > > The problem is being able to detect switch statement jump table vectors. > > For a given indirect branch (due to a switch statement), what are all > the corresponding jump targets? > > We would need the compiler to annotate that information somehow. Makes sense, the compiler should have this information. How is this problem solved on x86? > > > Distributions (like Android, CrOS) wont be able to use such a feature as > > is. > > Would a Clang plugin be out of the question? Generally, we frown on out of tree kernel modules for a couple reasons. Maintaining ABI compatibility when the core kernel changes is generally not instantaneous; someone has to notice the ABI has changed which will be more delayed than if the module was in tree. Worse is when semantics subtly change. While we must not break userspace, we provide no such guarantees within the kernel proper. Also, it's less likely that out of tree kernel modules have been reviewed by kernel developers. They may not have the same quality, use the recommended interfaces, follow coding conventions, etc.. Oh, did I say "out of tree kernel modules?" I meant "compiler plugins." But it's two different sides of the same coin to me. FWIW, I think the approach taken by -mstack-protector-guard-reg= is a useful case study. It was prototyped as a GCC extension, then added to GCC proper, then added to LLVM (currently only x86, but most of the machinery is in place in the compiler to get it running on arm64). My recommendation is to skip the plugin part and work on a standard interface for compilers to implement, with input from compiler developers. -- Thanks, ~Nick Desaulniers _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 2021-01-29 18:10 ` Nick Desaulniers @ 2021-02-01 21:44 ` Josh Poimboeuf -1 siblings, 0 replies; 106+ messages in thread From: Josh Poimboeuf @ 2021-02-01 21:44 UTC (permalink / raw) To: Nick Desaulniers Cc: Julien Thierry, Ard Biesheuvel, Mark Brown, Catalin Marinas, Kees Cook, Linux ARM, linux-efi, linux-hardening, LKML, Mark Rutland, Masahiro Yamada, Michal Marek, Peter Zijlstra, raphael.gault, Will Deacon, clang-built-linux On Fri, Jan 29, 2021 at 10:10:01AM -0800, Nick Desaulniers wrote: > On Wed, Jan 27, 2021 at 3:27 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > > > On Wed, Jan 27, 2021 at 02:15:57PM -0800, Nick Desaulniers wrote: > > > > From: Raphael Gault <raphael.gault@arm.com> > > > > > > > > This plugins comes into play before the final 2 RTL passes of GCC and > > > > detects switch-tables that are to be outputed in the ELF and writes > > > > information in an ".discard.switch_table_info" section which will be > > > > used by objtool. > > > > > > > > Signed-off-by: Raphael Gault <raphael.gault@arm.com> > > > > [J.T.: Change section name to store switch table information, > > > > Make plugin Kconfig be selected rather than opt-in by user, > > > > Add a relocation in the switch_table_info that points to > > > > the jump operation itself] > > > > Signed-off-by: Julien Thierry <jthierry@redhat.com> > > > > > > Rather than tightly couple this feature to a particular toolchain via > > > plugin, it might be nice to consider what features could be spec'ed out > > > for toolchains to implement (perhaps via a -f flag). > > > > The problem is being able to detect switch statement jump table vectors. > > > > For a given indirect branch (due to a switch statement), what are all > > the corresponding jump targets? > > > > We would need the compiler to annotate that information somehow. > > Makes sense, the compiler should have this information. How is this > problem solved on x86? Thus far we've been able to successfully reverse engineer it on x86, though it hasn't been easy. There were some particulars for arm64 which made doing so impossible. (I don't remember the details.) > > > Distributions (like Android, CrOS) wont be able to use such a feature as > > > is. > > > > Would a Clang plugin be out of the question? > > Generally, we frown on out of tree kernel modules for a couple reasons. > > Maintaining ABI compatibility when the core kernel changes is > generally not instantaneous; someone has to notice the ABI has changed > which will be more delayed than if the module was in tree. Worse is > when semantics subtly change. While we must not break userspace, we > provide no such guarantees within the kernel proper. > > Also, it's less likely that out of tree kernel modules have been > reviewed by kernel developers. They may not have the same quality, > use the recommended interfaces, follow coding conventions, etc.. > > Oh, did I say "out of tree kernel modules?" I meant "compiler > plugins." But it's two different sides of the same coin to me. I thought Android already relied on OOT modules. GCC plugins generally enforce the exact same GCC version for OOT modules. So there's no ABI to worry about. I assume Clang does the same? Or did I miss your point? > FWIW, I think the approach taken by -mstack-protector-guard-reg= is a > useful case study. It was prototyped as a GCC extension, then added > to GCC proper, then added to LLVM (currently only x86, but most of the > machinery is in place in the compiler to get it running on arm64). My > recommendation is to skip the plugin part and work on a standard > interface for compilers to implement, with input from compiler > developers. I like the idea. Is there a recommended forum for such discussions? Just an email to GCC/Clang development lists? -- Josh ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 @ 2021-02-01 21:44 ` Josh Poimboeuf 0 siblings, 0 replies; 106+ messages in thread From: Josh Poimboeuf @ 2021-02-01 21:44 UTC (permalink / raw) To: Nick Desaulniers Cc: Mark Rutland, linux-efi, Julien Thierry, clang-built-linux, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, LKML, Michal Marek, raphael.gault, Mark Brown, linux-hardening, Will Deacon, Ard Biesheuvel, Linux ARM, Kees Cook On Fri, Jan 29, 2021 at 10:10:01AM -0800, Nick Desaulniers wrote: > On Wed, Jan 27, 2021 at 3:27 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > > > On Wed, Jan 27, 2021 at 02:15:57PM -0800, Nick Desaulniers wrote: > > > > From: Raphael Gault <raphael.gault@arm.com> > > > > > > > > This plugins comes into play before the final 2 RTL passes of GCC and > > > > detects switch-tables that are to be outputed in the ELF and writes > > > > information in an ".discard.switch_table_info" section which will be > > > > used by objtool. > > > > > > > > Signed-off-by: Raphael Gault <raphael.gault@arm.com> > > > > [J.T.: Change section name to store switch table information, > > > > Make plugin Kconfig be selected rather than opt-in by user, > > > > Add a relocation in the switch_table_info that points to > > > > the jump operation itself] > > > > Signed-off-by: Julien Thierry <jthierry@redhat.com> > > > > > > Rather than tightly couple this feature to a particular toolchain via > > > plugin, it might be nice to consider what features could be spec'ed out > > > for toolchains to implement (perhaps via a -f flag). > > > > The problem is being able to detect switch statement jump table vectors. > > > > For a given indirect branch (due to a switch statement), what are all > > the corresponding jump targets? > > > > We would need the compiler to annotate that information somehow. > > Makes sense, the compiler should have this information. How is this > problem solved on x86? Thus far we've been able to successfully reverse engineer it on x86, though it hasn't been easy. There were some particulars for arm64 which made doing so impossible. (I don't remember the details.) > > > Distributions (like Android, CrOS) wont be able to use such a feature as > > > is. > > > > Would a Clang plugin be out of the question? > > Generally, we frown on out of tree kernel modules for a couple reasons. > > Maintaining ABI compatibility when the core kernel changes is > generally not instantaneous; someone has to notice the ABI has changed > which will be more delayed than if the module was in tree. Worse is > when semantics subtly change. While we must not break userspace, we > provide no such guarantees within the kernel proper. > > Also, it's less likely that out of tree kernel modules have been > reviewed by kernel developers. They may not have the same quality, > use the recommended interfaces, follow coding conventions, etc.. > > Oh, did I say "out of tree kernel modules?" I meant "compiler > plugins." But it's two different sides of the same coin to me. I thought Android already relied on OOT modules. GCC plugins generally enforce the exact same GCC version for OOT modules. So there's no ABI to worry about. I assume Clang does the same? Or did I miss your point? > FWIW, I think the approach taken by -mstack-protector-guard-reg= is a > useful case study. It was prototyped as a GCC extension, then added > to GCC proper, then added to LLVM (currently only x86, but most of the > machinery is in place in the compiler to get it running on arm64). My > recommendation is to skip the plugin part and work on a standard > interface for compilers to implement, with input from compiler > developers. I like the idea. Is there a recommended forum for such discussions? Just an email to GCC/Clang development lists? -- Josh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 2021-02-01 21:44 ` Josh Poimboeuf @ 2021-02-01 23:17 ` Nick Desaulniers -1 siblings, 0 replies; 106+ messages in thread From: Nick Desaulniers @ 2021-02-01 23:17 UTC (permalink / raw) To: Josh Poimboeuf Cc: Julien Thierry, Ard Biesheuvel, Mark Brown, Catalin Marinas, Kees Cook, Linux ARM, linux-efi, linux-hardening, LKML, Mark Rutland, Masahiro Yamada, Michal Marek, Peter Zijlstra, raphael.gault, Will Deacon, clang-built-linux, Bill Wendling On Mon, Feb 1, 2021 at 1:44 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > On Fri, Jan 29, 2021 at 10:10:01AM -0800, Nick Desaulniers wrote: > > On Wed, Jan 27, 2021 at 3:27 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > > > > > On Wed, Jan 27, 2021 at 02:15:57PM -0800, Nick Desaulniers wrote: > > > > > From: Raphael Gault <raphael.gault@arm.com> > > > > > > > > > > This plugins comes into play before the final 2 RTL passes of GCC and > > > > > detects switch-tables that are to be outputed in the ELF and writes > > > > > information in an ".discard.switch_table_info" section which will be > > > > > used by objtool. > > > > > > > > > > Signed-off-by: Raphael Gault <raphael.gault@arm.com> > > > > > [J.T.: Change section name to store switch table information, > > > > > Make plugin Kconfig be selected rather than opt-in by user, > > > > > Add a relocation in the switch_table_info that points to > > > > > the jump operation itself] > > > > > Signed-off-by: Julien Thierry <jthierry@redhat.com> > > > > > > > > Rather than tightly couple this feature to a particular toolchain via > > > > plugin, it might be nice to consider what features could be spec'ed out > > > > for toolchains to implement (perhaps via a -f flag). > > > > > > The problem is being able to detect switch statement jump table vectors. > > > > > > For a given indirect branch (due to a switch statement), what are all > > > the corresponding jump targets? > > > > > > We would need the compiler to annotate that information somehow. > > > > Makes sense, the compiler should have this information. How is this > > problem solved on x86? > > Thus far we've been able to successfully reverse engineer it on x86, > though it hasn't been easy. > > There were some particulars for arm64 which made doing so impossible. > (I don't remember the details.) I think the details are pertinent to finding a portable solution. The commit message of this commit in particular doesn't document such details, such as why such an approach is necessary or how the data is laid out for objtool to consume it. > > > > Distributions (like Android, CrOS) wont be able to use such a feature as > > > > is. > > > > > > Would a Clang plugin be out of the question? > > > > Generally, we frown on out of tree kernel modules for a couple reasons. > > > > Maintaining ABI compatibility when the core kernel changes is > > generally not instantaneous; someone has to notice the ABI has changed > > which will be more delayed than if the module was in tree. Worse is > > when semantics subtly change. While we must not break userspace, we > > provide no such guarantees within the kernel proper. > > > > Also, it's less likely that out of tree kernel modules have been > > reviewed by kernel developers. They may not have the same quality, > > use the recommended interfaces, follow coding conventions, etc.. > > > > Oh, did I say "out of tree kernel modules?" I meant "compiler > > plugins." But it's two different sides of the same coin to me. > > I thought Android already relied on OOT modules. Android Common Kernel does not *rely* on OOT modules or compiler plugins. Android doesn't forbid vendors from using OOT modules, though, just as the mainline kernel does not prevent modules from being built out of tree, or users from insmod'ing them. It's certainly a pragmatic approach; idealism doesn't work for all OEMs. Personally, I lean more towards idealistic; I prefer in-tree modules, dislike compiler plugins (for much the same reasons), and idealize loose coupling of software components. This series looks to me like it tightly couples arm64 live patching to objtool and GCC. On the earlier thread, Julien writes: >> I think most people interested in livepatching are using GCC built >> kernels, but I could be mistaken (althought in the long run, both >> compilers should be supported, and yes, I realize the objtool solution >> currently only would support GCC). Google's production kernels are using livepatching and are built with Clang. Getting similar functionality working for arm64 would be of interest. > GCC plugins generally enforce the exact same GCC version for OOT > modules. So there's no ABI to worry about. I assume Clang does the > same? > > Or did I miss your point? I think so. It would seem that the current solution for stack validation would require multiple different compiler plugins to work reliably. If jump tables are an issue, I don't see why you wouldn't pursue a more portable option like -fno-jump-tables first, then work to claw back any performance loss from that, if relevant? Then there's no complaint about toolchain specific implementations or tight coupling. Objtool support on arm64 is interesting to me though, because it has found bugs in LLVM codegen. That alone is extremely valuable. But not it's not helpful if it's predicated or tightly coupled to GCC, as this series appears to do. The idea of rebuilding control flow from binary analysis and using that to find codegen bugs is a really cool idea (novel, even? idk), and I wish we had some analog for userspace binaries that could perform similar checks. > > > FWIW, I think the approach taken by -mstack-protector-guard-reg= is a > > useful case study. It was prototyped as a GCC extension, then added > > to GCC proper, then added to LLVM (currently only x86, but most of the > > machinery is in place in the compiler to get it running on arm64). My > > recommendation is to skip the plugin part and work on a standard > > interface for compilers to implement, with input from compiler > > developers. > > I like the idea. Is there a recommended forum for such discussions? > Just an email to GCC/Clang development lists? linux-toolchains@vger.kernel.org is probably a good start. -- Thanks, ~Nick Desaulniers ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 @ 2021-02-01 23:17 ` Nick Desaulniers 0 siblings, 0 replies; 106+ messages in thread From: Nick Desaulniers @ 2021-02-01 23:17 UTC (permalink / raw) To: Josh Poimboeuf Cc: Mark Rutland, Bill Wendling, linux-efi, Julien Thierry, clang-built-linux, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, LKML, Michal Marek, raphael.gault, Mark Brown, linux-hardening, Will Deacon, Ard Biesheuvel, Linux ARM, Kees Cook On Mon, Feb 1, 2021 at 1:44 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > On Fri, Jan 29, 2021 at 10:10:01AM -0800, Nick Desaulniers wrote: > > On Wed, Jan 27, 2021 at 3:27 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > > > > > On Wed, Jan 27, 2021 at 02:15:57PM -0800, Nick Desaulniers wrote: > > > > > From: Raphael Gault <raphael.gault@arm.com> > > > > > > > > > > This plugins comes into play before the final 2 RTL passes of GCC and > > > > > detects switch-tables that are to be outputed in the ELF and writes > > > > > information in an ".discard.switch_table_info" section which will be > > > > > used by objtool. > > > > > > > > > > Signed-off-by: Raphael Gault <raphael.gault@arm.com> > > > > > [J.T.: Change section name to store switch table information, > > > > > Make plugin Kconfig be selected rather than opt-in by user, > > > > > Add a relocation in the switch_table_info that points to > > > > > the jump operation itself] > > > > > Signed-off-by: Julien Thierry <jthierry@redhat.com> > > > > > > > > Rather than tightly couple this feature to a particular toolchain via > > > > plugin, it might be nice to consider what features could be spec'ed out > > > > for toolchains to implement (perhaps via a -f flag). > > > > > > The problem is being able to detect switch statement jump table vectors. > > > > > > For a given indirect branch (due to a switch statement), what are all > > > the corresponding jump targets? > > > > > > We would need the compiler to annotate that information somehow. > > > > Makes sense, the compiler should have this information. How is this > > problem solved on x86? > > Thus far we've been able to successfully reverse engineer it on x86, > though it hasn't been easy. > > There were some particulars for arm64 which made doing so impossible. > (I don't remember the details.) I think the details are pertinent to finding a portable solution. The commit message of this commit in particular doesn't document such details, such as why such an approach is necessary or how the data is laid out for objtool to consume it. > > > > Distributions (like Android, CrOS) wont be able to use such a feature as > > > > is. > > > > > > Would a Clang plugin be out of the question? > > > > Generally, we frown on out of tree kernel modules for a couple reasons. > > > > Maintaining ABI compatibility when the core kernel changes is > > generally not instantaneous; someone has to notice the ABI has changed > > which will be more delayed than if the module was in tree. Worse is > > when semantics subtly change. While we must not break userspace, we > > provide no such guarantees within the kernel proper. > > > > Also, it's less likely that out of tree kernel modules have been > > reviewed by kernel developers. They may not have the same quality, > > use the recommended interfaces, follow coding conventions, etc.. > > > > Oh, did I say "out of tree kernel modules?" I meant "compiler > > plugins." But it's two different sides of the same coin to me. > > I thought Android already relied on OOT modules. Android Common Kernel does not *rely* on OOT modules or compiler plugins. Android doesn't forbid vendors from using OOT modules, though, just as the mainline kernel does not prevent modules from being built out of tree, or users from insmod'ing them. It's certainly a pragmatic approach; idealism doesn't work for all OEMs. Personally, I lean more towards idealistic; I prefer in-tree modules, dislike compiler plugins (for much the same reasons), and idealize loose coupling of software components. This series looks to me like it tightly couples arm64 live patching to objtool and GCC. On the earlier thread, Julien writes: >> I think most people interested in livepatching are using GCC built >> kernels, but I could be mistaken (althought in the long run, both >> compilers should be supported, and yes, I realize the objtool solution >> currently only would support GCC). Google's production kernels are using livepatching and are built with Clang. Getting similar functionality working for arm64 would be of interest. > GCC plugins generally enforce the exact same GCC version for OOT > modules. So there's no ABI to worry about. I assume Clang does the > same? > > Or did I miss your point? I think so. It would seem that the current solution for stack validation would require multiple different compiler plugins to work reliably. If jump tables are an issue, I don't see why you wouldn't pursue a more portable option like -fno-jump-tables first, then work to claw back any performance loss from that, if relevant? Then there's no complaint about toolchain specific implementations or tight coupling. Objtool support on arm64 is interesting to me though, because it has found bugs in LLVM codegen. That alone is extremely valuable. But not it's not helpful if it's predicated or tightly coupled to GCC, as this series appears to do. The idea of rebuilding control flow from binary analysis and using that to find codegen bugs is a really cool idea (novel, even? idk), and I wish we had some analog for userspace binaries that could perform similar checks. > > > FWIW, I think the approach taken by -mstack-protector-guard-reg= is a > > useful case study. It was prototyped as a GCC extension, then added > > to GCC proper, then added to LLVM (currently only x86, but most of the > > machinery is in place in the compiler to get it running on arm64). My > > recommendation is to skip the plugin part and work on a standard > > interface for compilers to implement, with input from compiler > > developers. > > I like the idea. Is there a recommended forum for such discussions? > Just an email to GCC/Clang development lists? linux-toolchains@vger.kernel.org is probably a good start. -- Thanks, ~Nick Desaulniers _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 2021-02-01 23:17 ` Nick Desaulniers @ 2021-02-02 0:02 ` Josh Poimboeuf -1 siblings, 0 replies; 106+ messages in thread From: Josh Poimboeuf @ 2021-02-02 0:02 UTC (permalink / raw) To: Nick Desaulniers Cc: Julien Thierry, Ard Biesheuvel, Mark Brown, Catalin Marinas, Kees Cook, Linux ARM, linux-efi, linux-hardening, LKML, Mark Rutland, Masahiro Yamada, Michal Marek, Peter Zijlstra, raphael.gault, Will Deacon, clang-built-linux, Bill Wendling On Mon, Feb 01, 2021 at 03:17:40PM -0800, Nick Desaulniers wrote: > > > > > Rather than tightly couple this feature to a particular toolchain via > > > > > plugin, it might be nice to consider what features could be spec'ed out > > > > > for toolchains to implement (perhaps via a -f flag). > > > > > > > > The problem is being able to detect switch statement jump table vectors. > > > > > > > > For a given indirect branch (due to a switch statement), what are all > > > > the corresponding jump targets? > > > > > > > > We would need the compiler to annotate that information somehow. > > > > > > Makes sense, the compiler should have this information. How is this > > > problem solved on x86? > > > > Thus far we've been able to successfully reverse engineer it on x86, > > though it hasn't been easy. > > > > There were some particulars for arm64 which made doing so impossible. > > (I don't remember the details.) > > I think the details are pertinent to finding a portable solution. The > commit message of this commit in particular doesn't document such > details, such as why such an approach is necessary or how the data is > laid out for objtool to consume it. Agreed, the commit message needs more details. > > > > > Distributions (like Android, CrOS) wont be able to use such a feature as > > > > > is. > > > > > > > > Would a Clang plugin be out of the question? > > > > > > Generally, we frown on out of tree kernel modules for a couple reasons. > > > > > > Maintaining ABI compatibility when the core kernel changes is > > > generally not instantaneous; someone has to notice the ABI has changed > > > which will be more delayed than if the module was in tree. Worse is > > > when semantics subtly change. While we must not break userspace, we > > > provide no such guarantees within the kernel proper. > > > > > > Also, it's less likely that out of tree kernel modules have been > > > reviewed by kernel developers. They may not have the same quality, > > > use the recommended interfaces, follow coding conventions, etc.. > > > > > > Oh, did I say "out of tree kernel modules?" I meant "compiler > > > plugins." But it's two different sides of the same coin to me. > > > > I thought Android already relied on OOT modules. > > Android Common Kernel does not *rely* on OOT modules or compiler > plugins. Android doesn't forbid vendors from using OOT modules, > though, just as the mainline kernel does not prevent modules from > being built out of tree, or users from insmod'ing them. It's > certainly a pragmatic approach; idealism doesn't work for all OEMs. No judgement, RHEL is similar. Linux is nothing if not pragmatic. > Personally, I lean more towards idealistic; I prefer in-tree modules, > dislike compiler plugins (for much the same reasons), and idealize > loose coupling of software components. This series looks to me like it > tightly couples arm64 live patching to objtool and GCC. > > On the earlier thread, Julien writes: > > >> I think most people interested in livepatching are using GCC built > >> kernels, but I could be mistaken (althought in the long run, both > >> compilers should be supported, and yes, I realize the objtool solution > >> currently only would support GCC). > > Google's production kernels are using livepatching and are built with > Clang. Getting similar functionality working for arm64 would be of > interest. Well, that's cool. I had no idea. I'm curious how they're generating livepatch modules? Because kpatch-build doesn't support Clang (AFAIK), and if they're not using kpatch-build then there are some traps to look out for. > > GCC plugins generally enforce the exact same GCC version for OOT > > modules. So there's no ABI to worry about. I assume Clang does the > > same? > > > > Or did I miss your point? > > I think so. It would seem that the current solution for stack > validation would require multiple different compiler plugins to work > reliably. If jump tables are an issue, I don't see why you wouldn't > pursue a more portable option like -fno-jump-tables first, then work > to claw back any performance loss from that, if relevant? Then > there's no complaint about toolchain specific implementations or tight > coupling. > > Objtool support on arm64 is interesting to me though, because it has > found bugs in LLVM codegen. That alone is extremely valuable. But not > it's not helpful if it's predicated or tightly coupled to GCC, as this > series appears to do. I agree 100%, if there are actual Clang livepatch users (which it sounds like there are) then we should target both compilers. And yes, objtool has been pretty good at finding compiler bugs, so the more coverage the better. I like the -fno-jump-tables suggestion, assuming it doesn't affect performance significantly. > The idea of rebuilding control flow from binary analysis and using > that to find codegen bugs is a really cool idea (novel, even? idk), > and I wish we had some analog for userspace binaries that could > perform similar checks. Objtool is generic in many ways -- in fact I recently heard from a PhD candidate who used it successfully on another kernel for an ORC unwinder. It could probably be used on user space without much effort. That was an early original stated goal but I definitely don't have the bandwidth or incentive to work on it. > > > FWIW, I think the approach taken by -mstack-protector-guard-reg= is a > > > useful case study. It was prototyped as a GCC extension, then added > > > to GCC proper, then added to LLVM (currently only x86, but most of the > > > machinery is in place in the compiler to get it running on arm64). My > > > recommendation is to skip the plugin part and work on a standard > > > interface for compilers to implement, with input from compiler > > > developers. > > > > I like the idea. Is there a recommended forum for such discussions? > > Just an email to GCC/Clang development lists? > > linux-toolchains@vger.kernel.org is probably a good start. Thanks, I'll write something up (maybe a more specific proposal) and post it. -- Josh ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 @ 2021-02-02 0:02 ` Josh Poimboeuf 0 siblings, 0 replies; 106+ messages in thread From: Josh Poimboeuf @ 2021-02-02 0:02 UTC (permalink / raw) To: Nick Desaulniers Cc: Mark Rutland, Bill Wendling, linux-efi, Julien Thierry, clang-built-linux, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, LKML, Michal Marek, raphael.gault, Mark Brown, linux-hardening, Will Deacon, Ard Biesheuvel, Linux ARM, Kees Cook On Mon, Feb 01, 2021 at 03:17:40PM -0800, Nick Desaulniers wrote: > > > > > Rather than tightly couple this feature to a particular toolchain via > > > > > plugin, it might be nice to consider what features could be spec'ed out > > > > > for toolchains to implement (perhaps via a -f flag). > > > > > > > > The problem is being able to detect switch statement jump table vectors. > > > > > > > > For a given indirect branch (due to a switch statement), what are all > > > > the corresponding jump targets? > > > > > > > > We would need the compiler to annotate that information somehow. > > > > > > Makes sense, the compiler should have this information. How is this > > > problem solved on x86? > > > > Thus far we've been able to successfully reverse engineer it on x86, > > though it hasn't been easy. > > > > There were some particulars for arm64 which made doing so impossible. > > (I don't remember the details.) > > I think the details are pertinent to finding a portable solution. The > commit message of this commit in particular doesn't document such > details, such as why such an approach is necessary or how the data is > laid out for objtool to consume it. Agreed, the commit message needs more details. > > > > > Distributions (like Android, CrOS) wont be able to use such a feature as > > > > > is. > > > > > > > > Would a Clang plugin be out of the question? > > > > > > Generally, we frown on out of tree kernel modules for a couple reasons. > > > > > > Maintaining ABI compatibility when the core kernel changes is > > > generally not instantaneous; someone has to notice the ABI has changed > > > which will be more delayed than if the module was in tree. Worse is > > > when semantics subtly change. While we must not break userspace, we > > > provide no such guarantees within the kernel proper. > > > > > > Also, it's less likely that out of tree kernel modules have been > > > reviewed by kernel developers. They may not have the same quality, > > > use the recommended interfaces, follow coding conventions, etc.. > > > > > > Oh, did I say "out of tree kernel modules?" I meant "compiler > > > plugins." But it's two different sides of the same coin to me. > > > > I thought Android already relied on OOT modules. > > Android Common Kernel does not *rely* on OOT modules or compiler > plugins. Android doesn't forbid vendors from using OOT modules, > though, just as the mainline kernel does not prevent modules from > being built out of tree, or users from insmod'ing them. It's > certainly a pragmatic approach; idealism doesn't work for all OEMs. No judgement, RHEL is similar. Linux is nothing if not pragmatic. > Personally, I lean more towards idealistic; I prefer in-tree modules, > dislike compiler plugins (for much the same reasons), and idealize > loose coupling of software components. This series looks to me like it > tightly couples arm64 live patching to objtool and GCC. > > On the earlier thread, Julien writes: > > >> I think most people interested in livepatching are using GCC built > >> kernels, but I could be mistaken (althought in the long run, both > >> compilers should be supported, and yes, I realize the objtool solution > >> currently only would support GCC). > > Google's production kernels are using livepatching and are built with > Clang. Getting similar functionality working for arm64 would be of > interest. Well, that's cool. I had no idea. I'm curious how they're generating livepatch modules? Because kpatch-build doesn't support Clang (AFAIK), and if they're not using kpatch-build then there are some traps to look out for. > > GCC plugins generally enforce the exact same GCC version for OOT > > modules. So there's no ABI to worry about. I assume Clang does the > > same? > > > > Or did I miss your point? > > I think so. It would seem that the current solution for stack > validation would require multiple different compiler plugins to work > reliably. If jump tables are an issue, I don't see why you wouldn't > pursue a more portable option like -fno-jump-tables first, then work > to claw back any performance loss from that, if relevant? Then > there's no complaint about toolchain specific implementations or tight > coupling. > > Objtool support on arm64 is interesting to me though, because it has > found bugs in LLVM codegen. That alone is extremely valuable. But not > it's not helpful if it's predicated or tightly coupled to GCC, as this > series appears to do. I agree 100%, if there are actual Clang livepatch users (which it sounds like there are) then we should target both compilers. And yes, objtool has been pretty good at finding compiler bugs, so the more coverage the better. I like the -fno-jump-tables suggestion, assuming it doesn't affect performance significantly. > The idea of rebuilding control flow from binary analysis and using > that to find codegen bugs is a really cool idea (novel, even? idk), > and I wish we had some analog for userspace binaries that could > perform similar checks. Objtool is generic in many ways -- in fact I recently heard from a PhD candidate who used it successfully on another kernel for an ORC unwinder. It could probably be used on user space without much effort. That was an early original stated goal but I definitely don't have the bandwidth or incentive to work on it. > > > FWIW, I think the approach taken by -mstack-protector-guard-reg= is a > > > useful case study. It was prototyped as a GCC extension, then added > > > to GCC proper, then added to LLVM (currently only x86, but most of the > > > machinery is in place in the compiler to get it running on arm64). My > > > recommendation is to skip the plugin part and work on a standard > > > interface for compilers to implement, with input from compiler > > > developers. > > > > I like the idea. Is there a recommended forum for such discussions? > > Just an email to GCC/Clang development lists? > > linux-toolchains@vger.kernel.org is probably a good start. Thanks, I'll write something up (maybe a more specific proposal) and post it. -- Josh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 2021-02-02 0:02 ` Josh Poimboeuf @ 2021-02-02 14:24 ` David Laight -1 siblings, 0 replies; 106+ messages in thread From: David Laight @ 2021-02-02 14:24 UTC (permalink / raw) To: 'Josh Poimboeuf', Nick Desaulniers Cc: Julien Thierry, Ard Biesheuvel, Mark Brown, Catalin Marinas, Kees Cook, Linux ARM, linux-efi, linux-hardening, LKML, Mark Rutland, Masahiro Yamada, Michal Marek, Peter Zijlstra, raphael.gault, Will Deacon, clang-built-linux, Bill Wendling Stirring more goop into the hole .... Requiring gcc-plugins, matching compiler versions and the same 'dwarf' format for OOT modules is probably very painful. In many cases (and this may include drivers released by some distributions) an OOT driver has two separate parts. One part is C source that is compiled when the module is built on the target system and against the installed kernel headers. Getting this to match 'just' relies on having the correct compiler (etc) installed and in $PATH. The second part is much more problematic. This is just an object file compiled by a third party. It doesn't directly depend on anything defined in the kernel headers - so can (currently) be linked into any kernel version. In the past some graphics drivers have had a third party object file. I think some of the laptop wifi drivers might as well. Now I some people think everything should be free source. But there are various commercial and practical reasons for both OOT drivers and object file 'blobs' in OOT drivers. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) ^ permalink raw reply [flat|nested] 106+ messages in thread
* RE: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 @ 2021-02-02 14:24 ` David Laight 0 siblings, 0 replies; 106+ messages in thread From: David Laight @ 2021-02-02 14:24 UTC (permalink / raw) To: 'Josh Poimboeuf', Nick Desaulniers Cc: Mark Rutland, Bill Wendling, linux-efi, Julien Thierry, clang-built-linux, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, LKML, Michal Marek, raphael.gault, Mark Brown, linux-hardening, Will Deacon, Ard Biesheuvel, Linux ARM, Kees Cook Stirring more goop into the hole .... Requiring gcc-plugins, matching compiler versions and the same 'dwarf' format for OOT modules is probably very painful. In many cases (and this may include drivers released by some distributions) an OOT driver has two separate parts. One part is C source that is compiled when the module is built on the target system and against the installed kernel headers. Getting this to match 'just' relies on having the correct compiler (etc) installed and in $PATH. The second part is much more problematic. This is just an object file compiled by a third party. It doesn't directly depend on anything defined in the kernel headers - so can (currently) be linked into any kernel version. In the past some graphics drivers have had a third party object file. I think some of the laptop wifi drivers might as well. Now I some people think everything should be free source. But there are various commercial and practical reasons for both OOT drivers and object file 'blobs' in OOT drivers. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 2021-02-02 0:02 ` Josh Poimboeuf @ 2021-02-02 22:33 ` Nick Desaulniers -1 siblings, 0 replies; 106+ messages in thread From: Nick Desaulniers @ 2021-02-02 22:33 UTC (permalink / raw) To: Josh Poimboeuf Cc: Julien Thierry, Ard Biesheuvel, Mark Brown, Catalin Marinas, Kees Cook, Linux ARM, linux-efi, linux-hardening, LKML, Mark Rutland, Masahiro Yamada, Michal Marek, Peter Zijlstra, raphael.gault, Will Deacon, clang-built-linux, Bill Wendling, swine, yonghyun On Mon, Feb 1, 2021 at 4:02 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > On Mon, Feb 01, 2021 at 03:17:40PM -0800, Nick Desaulniers wrote: > > On the earlier thread, Julien writes: > > > > >> I think most people interested in livepatching are using GCC built > > >> kernels, but I could be mistaken (althought in the long run, both > > >> compilers should be supported, and yes, I realize the objtool solution > > >> currently only would support GCC). > > > > Google's production kernels are using livepatching and are built with > > Clang. Getting similar functionality working for arm64 would be of > > interest. > > Well, that's cool. I had no idea. > > I'm curious how they're generating livepatch modules? Because > kpatch-build doesn't support Clang (AFAIK), and if they're not using > kpatch-build then there are some traps to look out for. Ok, I just met with a bunch of folks that are actively working on this. Let me intro Yonghyun Hwang <yonghyun@google.com> Pete Swain <swine@google.com> who will be the folks on point for this from Google. My understanding after some clarifications today is that Google is currently using a proprietary kernel patching mechanism that developed around a decade ago, "pre-ksplice Oracle acquisition." But we are looking to transition to kpatch, and help towards supporting arm64. Live patching is important for deploying kernel fixes faster than predetermined scheduled draining of jobs in clusters. The first steps for kpatch transition is supporting builds with Clang. Yonghyun is working on that and my hope is he will have patches for you for that soon. Curiously, the proprietary mechanism doesn't rely on stack validation. I think that such dependency was questioned on the cover letter patch's thread as well. Maybe there's "some traps to look out for" you're referring to there? I'm not privy to the details, though I would guess it has to do with ensuring kernel threads aren't executing (or planning to return through) code regions that are trying to be patched/unpatched. I am curious about frame pointers never being omitted for arm64; is frame pointer chasing is unreliable in certain contexts? The internal functionality has been used heavily in production for almost a decade, though without it being public or supporting arm64; I'm not sure precisely how they solve such issues (or how others might review such an approach). Either way, the dependencies for live patching are less important, so long as they are toolchain portable. The ability to live patch kernel images is ___important___ to Google. > > Objtool support on arm64 is interesting to me though, because it has > > found bugs in LLVM codegen. That alone is extremely valuable. But not > > it's not helpful if it's predicated or tightly coupled to GCC, as this > > series appears to do. > > I agree 100%, if there are actual Clang livepatch users (which it sounds > like there are) then we should target both compilers. Or will be. (Sorry, I didn't know we hadn't completed the transition to kpatch yet. It is "the opposite side of the house" from where I work; I literally have 8 bosses, not kidding). Though if kpatch moves to requiring GCC plugins for architectures we use extensively or would like to use more of, that's probably going to throw a wrench in multiple transition plans. (The fleet's transition to Clang is done, I'm not worried about that). > And yes, objtool has been pretty good at finding compiler bugs, so the > more coverage the better. > > The idea of rebuilding control flow from binary analysis and using > > that to find codegen bugs is a really cool idea (novel, even? idk), > > and I wish we had some analog for userspace binaries that could > > perform similar checks. > > Objtool is generic in many ways -- in fact I recently heard from a PhD > candidate who used it successfully on another kernel for an ORC > unwinder. That's pretty cool! Reuse outside the initial context is always a good sign that something was designed right. > It could probably be used on user space without much effort. That was > an early original stated goal but I definitely don't have the bandwidth > or incentive to work on it. Heh. I'm a big fan of game theory; carrot or stick, right? -- Thanks, ~Nick Desaulniers ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 @ 2021-02-02 22:33 ` Nick Desaulniers 0 siblings, 0 replies; 106+ messages in thread From: Nick Desaulniers @ 2021-02-02 22:33 UTC (permalink / raw) To: Josh Poimboeuf Cc: Mark Rutland, Bill Wendling, linux-efi, Julien Thierry, clang-built-linux, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, yonghyun, LKML, Michal Marek, raphael.gault, Mark Brown, linux-hardening, swine, Will Deacon, Ard Biesheuvel, Linux ARM, Kees Cook On Mon, Feb 1, 2021 at 4:02 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > On Mon, Feb 01, 2021 at 03:17:40PM -0800, Nick Desaulniers wrote: > > On the earlier thread, Julien writes: > > > > >> I think most people interested in livepatching are using GCC built > > >> kernels, but I could be mistaken (althought in the long run, both > > >> compilers should be supported, and yes, I realize the objtool solution > > >> currently only would support GCC). > > > > Google's production kernels are using livepatching and are built with > > Clang. Getting similar functionality working for arm64 would be of > > interest. > > Well, that's cool. I had no idea. > > I'm curious how they're generating livepatch modules? Because > kpatch-build doesn't support Clang (AFAIK), and if they're not using > kpatch-build then there are some traps to look out for. Ok, I just met with a bunch of folks that are actively working on this. Let me intro Yonghyun Hwang <yonghyun@google.com> Pete Swain <swine@google.com> who will be the folks on point for this from Google. My understanding after some clarifications today is that Google is currently using a proprietary kernel patching mechanism that developed around a decade ago, "pre-ksplice Oracle acquisition." But we are looking to transition to kpatch, and help towards supporting arm64. Live patching is important for deploying kernel fixes faster than predetermined scheduled draining of jobs in clusters. The first steps for kpatch transition is supporting builds with Clang. Yonghyun is working on that and my hope is he will have patches for you for that soon. Curiously, the proprietary mechanism doesn't rely on stack validation. I think that such dependency was questioned on the cover letter patch's thread as well. Maybe there's "some traps to look out for" you're referring to there? I'm not privy to the details, though I would guess it has to do with ensuring kernel threads aren't executing (or planning to return through) code regions that are trying to be patched/unpatched. I am curious about frame pointers never being omitted for arm64; is frame pointer chasing is unreliable in certain contexts? The internal functionality has been used heavily in production for almost a decade, though without it being public or supporting arm64; I'm not sure precisely how they solve such issues (or how others might review such an approach). Either way, the dependencies for live patching are less important, so long as they are toolchain portable. The ability to live patch kernel images is ___important___ to Google. > > Objtool support on arm64 is interesting to me though, because it has > > found bugs in LLVM codegen. That alone is extremely valuable. But not > > it's not helpful if it's predicated or tightly coupled to GCC, as this > > series appears to do. > > I agree 100%, if there are actual Clang livepatch users (which it sounds > like there are) then we should target both compilers. Or will be. (Sorry, I didn't know we hadn't completed the transition to kpatch yet. It is "the opposite side of the house" from where I work; I literally have 8 bosses, not kidding). Though if kpatch moves to requiring GCC plugins for architectures we use extensively or would like to use more of, that's probably going to throw a wrench in multiple transition plans. (The fleet's transition to Clang is done, I'm not worried about that). > And yes, objtool has been pretty good at finding compiler bugs, so the > more coverage the better. > > The idea of rebuilding control flow from binary analysis and using > > that to find codegen bugs is a really cool idea (novel, even? idk), > > and I wish we had some analog for userspace binaries that could > > perform similar checks. > > Objtool is generic in many ways -- in fact I recently heard from a PhD > candidate who used it successfully on another kernel for an ORC > unwinder. That's pretty cool! Reuse outside the initial context is always a good sign that something was designed right. > It could probably be used on user space without much effort. That was > an early original stated goal but I definitely don't have the bandwidth > or incentive to work on it. Heh. I'm a big fan of game theory; carrot or stick, right? -- Thanks, ~Nick Desaulniers _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 2021-02-02 22:33 ` Nick Desaulniers @ 2021-02-02 23:36 ` Josh Poimboeuf -1 siblings, 0 replies; 106+ messages in thread From: Josh Poimboeuf @ 2021-02-02 23:36 UTC (permalink / raw) To: Nick Desaulniers Cc: Julien Thierry, Ard Biesheuvel, Mark Brown, Catalin Marinas, Kees Cook, Linux ARM, linux-efi, linux-hardening, LKML, Mark Rutland, Masahiro Yamada, Michal Marek, Peter Zijlstra, raphael.gault, Will Deacon, clang-built-linux, Bill Wendling, swine, yonghyun, live-patching On Tue, Feb 02, 2021 at 02:33:38PM -0800, Nick Desaulniers wrote: > On Mon, Feb 1, 2021 at 4:02 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > > > On Mon, Feb 01, 2021 at 03:17:40PM -0800, Nick Desaulniers wrote: > > > On the earlier thread, Julien writes: > > > > > > >> I think most people interested in livepatching are using GCC built > > > >> kernels, but I could be mistaken (althought in the long run, both > > > >> compilers should be supported, and yes, I realize the objtool solution > > > >> currently only would support GCC). > > > > > > Google's production kernels are using livepatching and are built with > > > Clang. Getting similar functionality working for arm64 would be of > > > interest. > > > > Well, that's cool. I had no idea. > > > > I'm curious how they're generating livepatch modules? Because > > kpatch-build doesn't support Clang (AFAIK), and if they're not using > > kpatch-build then there are some traps to look out for. > > Ok, I just met with a bunch of folks that are actively working on > this. Let me intro > Yonghyun Hwang <yonghyun@google.com> > Pete Swain <swine@google.com> > who will be the folks on point for this from Google. Nice to meet you all. Adding the live-patching ML sub-thread. > My understanding after some clarifications today is that Google is > currently using a proprietary kernel patching mechanism that developed > around a decade ago, "pre-ksplice Oracle acquisition." But we are > looking to transition to kpatch, and help towards supporting arm64. > Live patching is important for deploying kernel fixes faster than > predetermined scheduled draining of jobs in clusters. > > The first steps for kpatch transition is supporting builds with Clang. > Yonghyun is working on that and my hope is he will have patches for > you for that soon. That would be great! > Curiously, the proprietary mechanism doesn't rely on stack validation. If this proprietary mechanism relies on stack traces, that could problematic. Livepatch originally made the same assumption, but it was shot down quickly: https://lwn.net/Articles/634649/ https://lwn.net/Articles/658333/ > I think that such dependency was questioned on the cover letter > patch's thread as well. Yes, though it's generally agreed that unvalidated compiler-generated unwinder metadata isn't going to be robust enough for kernel live patching. > Maybe there's "some traps to look out for" you're referring to there? The "traps" are more about how the patches are generated. If they're built with source code, like a normal kernel module, you have to be extra careful because of function ABI nastiness. kpatch-build avoids this problem. Unfortunately this still isn't documented. > I'm not privy to the details, though I would guess it has to do with > ensuring kernel threads aren't executing (or planning to return > through) code regions that are trying to be patched/unpatched. Right. There are some good details in Documentation/livepatch/livepatch.rst. > I am curious about frame pointers never being omitted for arm64; is > frame pointer chasing is unreliable in certain contexts? Yes, problematic areas are interrupts, exceptions, inline asm, hand-coded asm. A nice document was recently added in Documentation/livepatch/reliable-stacktrace.rst which covers a lot of this stuff. > The internal functionality has been used heavily in production for > almost a decade, though without it being public or supporting arm64; > I'm not sure precisely how they solve such issues (or how others might > review such an approach). Very impressive to run it in production that long. Their experience and expertise is definitely welcome. > Either way, the dependencies for live patching are less important, so > long as they are toolchain portable. The ability to live patch kernel > images is ___important___ to Google. > > > > Objtool support on arm64 is interesting to me though, because it has > > > found bugs in LLVM codegen. That alone is extremely valuable. But not > > > it's not helpful if it's predicated or tightly coupled to GCC, as this > > > series appears to do. > > > > I agree 100%, if there are actual Clang livepatch users (which it sounds > > like there are) then we should target both compilers. > > Or will be. (Sorry, I didn't know we hadn't completed the transition > to kpatch yet. It is "the opposite side of the house" from where I > work; I literally have 8 bosses, not kidding). > > Though if kpatch moves to requiring GCC plugins for architectures we > use extensively or would like to use more of, that's probably going to > throw a wrench in multiple transition plans. (The fleet's transition > to Clang is done, I'm not worried about that). Hopefully we can just forget the GCC plugin idea. It would be really nice to see some performance numbers for -fno-jump-tables so we can justify doing that instead, at least in the short-term. I'd suspect the difference isn't measurable in the real world. (In the case of GCC+retpolines, it would be a performance improvement.) > > And yes, objtool has been pretty good at finding compiler bugs, so the > > more coverage the better. > > > The idea of rebuilding control flow from binary analysis and using > > > that to find codegen bugs is a really cool idea (novel, even? idk), > > > and I wish we had some analog for userspace binaries that could > > > perform similar checks. > > > > Objtool is generic in many ways -- in fact I recently heard from a PhD > > candidate who used it successfully on another kernel for an ORC > > unwinder. > > That's pretty cool! Reuse outside the initial context is always a > good sign that something was designed right. So basically you're saying objtool is both useful and well-designed. I will quote you on that! -- Josh ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 @ 2021-02-02 23:36 ` Josh Poimboeuf 0 siblings, 0 replies; 106+ messages in thread From: Josh Poimboeuf @ 2021-02-02 23:36 UTC (permalink / raw) To: Nick Desaulniers Cc: Mark Rutland, Bill Wendling, linux-efi, Julien Thierry, clang-built-linux, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, yonghyun, LKML, Michal Marek, raphael.gault, Mark Brown, linux-hardening, swine, live-patching, Will Deacon, Ard Biesheuvel, Linux ARM, Kees Cook On Tue, Feb 02, 2021 at 02:33:38PM -0800, Nick Desaulniers wrote: > On Mon, Feb 1, 2021 at 4:02 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > > > On Mon, Feb 01, 2021 at 03:17:40PM -0800, Nick Desaulniers wrote: > > > On the earlier thread, Julien writes: > > > > > > >> I think most people interested in livepatching are using GCC built > > > >> kernels, but I could be mistaken (althought in the long run, both > > > >> compilers should be supported, and yes, I realize the objtool solution > > > >> currently only would support GCC). > > > > > > Google's production kernels are using livepatching and are built with > > > Clang. Getting similar functionality working for arm64 would be of > > > interest. > > > > Well, that's cool. I had no idea. > > > > I'm curious how they're generating livepatch modules? Because > > kpatch-build doesn't support Clang (AFAIK), and if they're not using > > kpatch-build then there are some traps to look out for. > > Ok, I just met with a bunch of folks that are actively working on > this. Let me intro > Yonghyun Hwang <yonghyun@google.com> > Pete Swain <swine@google.com> > who will be the folks on point for this from Google. Nice to meet you all. Adding the live-patching ML sub-thread. > My understanding after some clarifications today is that Google is > currently using a proprietary kernel patching mechanism that developed > around a decade ago, "pre-ksplice Oracle acquisition." But we are > looking to transition to kpatch, and help towards supporting arm64. > Live patching is important for deploying kernel fixes faster than > predetermined scheduled draining of jobs in clusters. > > The first steps for kpatch transition is supporting builds with Clang. > Yonghyun is working on that and my hope is he will have patches for > you for that soon. That would be great! > Curiously, the proprietary mechanism doesn't rely on stack validation. If this proprietary mechanism relies on stack traces, that could problematic. Livepatch originally made the same assumption, but it was shot down quickly: https://lwn.net/Articles/634649/ https://lwn.net/Articles/658333/ > I think that such dependency was questioned on the cover letter > patch's thread as well. Yes, though it's generally agreed that unvalidated compiler-generated unwinder metadata isn't going to be robust enough for kernel live patching. > Maybe there's "some traps to look out for" you're referring to there? The "traps" are more about how the patches are generated. If they're built with source code, like a normal kernel module, you have to be extra careful because of function ABI nastiness. kpatch-build avoids this problem. Unfortunately this still isn't documented. > I'm not privy to the details, though I would guess it has to do with > ensuring kernel threads aren't executing (or planning to return > through) code regions that are trying to be patched/unpatched. Right. There are some good details in Documentation/livepatch/livepatch.rst. > I am curious about frame pointers never being omitted for arm64; is > frame pointer chasing is unreliable in certain contexts? Yes, problematic areas are interrupts, exceptions, inline asm, hand-coded asm. A nice document was recently added in Documentation/livepatch/reliable-stacktrace.rst which covers a lot of this stuff. > The internal functionality has been used heavily in production for > almost a decade, though without it being public or supporting arm64; > I'm not sure precisely how they solve such issues (or how others might > review such an approach). Very impressive to run it in production that long. Their experience and expertise is definitely welcome. > Either way, the dependencies for live patching are less important, so > long as they are toolchain portable. The ability to live patch kernel > images is ___important___ to Google. > > > > Objtool support on arm64 is interesting to me though, because it has > > > found bugs in LLVM codegen. That alone is extremely valuable. But not > > > it's not helpful if it's predicated or tightly coupled to GCC, as this > > > series appears to do. > > > > I agree 100%, if there are actual Clang livepatch users (which it sounds > > like there are) then we should target both compilers. > > Or will be. (Sorry, I didn't know we hadn't completed the transition > to kpatch yet. It is "the opposite side of the house" from where I > work; I literally have 8 bosses, not kidding). > > Though if kpatch moves to requiring GCC plugins for architectures we > use extensively or would like to use more of, that's probably going to > throw a wrench in multiple transition plans. (The fleet's transition > to Clang is done, I'm not worried about that). Hopefully we can just forget the GCC plugin idea. It would be really nice to see some performance numbers for -fno-jump-tables so we can justify doing that instead, at least in the short-term. I'd suspect the difference isn't measurable in the real world. (In the case of GCC+retpolines, it would be a performance improvement.) > > And yes, objtool has been pretty good at finding compiler bugs, so the > > more coverage the better. > > > The idea of rebuilding control flow from binary analysis and using > > > that to find codegen bugs is a really cool idea (novel, even? idk), > > > and I wish we had some analog for userspace binaries that could > > > perform similar checks. > > > > Objtool is generic in many ways -- in fact I recently heard from a PhD > > candidate who used it successfully on another kernel for an ORC > > unwinder. > > That's pretty cool! Reuse outside the initial context is always a > good sign that something was designed right. So basically you're saying objtool is both useful and well-designed. I will quote you on that! -- Josh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 2021-02-02 23:36 ` Josh Poimboeuf @ 2021-02-02 23:52 ` Nick Desaulniers -1 siblings, 0 replies; 106+ messages in thread From: Nick Desaulniers @ 2021-02-02 23:52 UTC (permalink / raw) To: Josh Poimboeuf Cc: Julien Thierry, Ard Biesheuvel, Mark Brown, Catalin Marinas, Kees Cook, Linux ARM, linux-efi, linux-hardening, LKML, Mark Rutland, Masahiro Yamada, Michal Marek, Peter Zijlstra, raphael.gault, Will Deacon, clang-built-linux, Bill Wendling, Pete Swain, Yonghyun Hwang, live-patching On Tue, Feb 2, 2021 at 3:36 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > On Tue, Feb 02, 2021 at 02:33:38PM -0800, Nick Desaulniers wrote: > > On Mon, Feb 1, 2021 at 4:02 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > > > > > On Mon, Feb 01, 2021 at 03:17:40PM -0800, Nick Desaulniers wrote: > > > And yes, objtool has been pretty good at finding compiler bugs, so the > > > more coverage the better. > > > > The idea of rebuilding control flow from binary analysis and using > > > > that to find codegen bugs is a really cool idea (novel, even? idk), > > > > and I wish we had some analog for userspace binaries that could > > > > perform similar checks. > > > > > > Objtool is generic in many ways -- in fact I recently heard from a PhD > > > candidate who used it successfully on another kernel for an ORC > > > unwinder. > > > > That's pretty cool! Reuse outside the initial context is always a > > good sign that something was designed right. > > So basically you're saying objtool is both useful and well-designed. I > will quote you on that! Haha, all I'm saying is that while I'm not proud that it did find bugs in LLVM (and I do have existing bugs found by it to fix on my plate), I don't see who else or how else those would have been spotted, and I can appreciate that. I think the tools given to us are broken (by design, perhaps), so anything that can help us spot issues might help our code live longer than we do. I also think that there's room for improvement and experimentation in debug info formats, though there is currently a proliferation to support. Live patching and eBPF seem to have some functional overlap IIUC, strengths/weaknesses, and their own unique debug info formats to go with it. Supporting each one does require some level of toolchain support or coordination (or complexity, even). -- Thanks, ~Nick Desaulniers ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 @ 2021-02-02 23:52 ` Nick Desaulniers 0 siblings, 0 replies; 106+ messages in thread From: Nick Desaulniers @ 2021-02-02 23:52 UTC (permalink / raw) To: Josh Poimboeuf Cc: Mark Rutland, Bill Wendling, linux-efi, Julien Thierry, clang-built-linux, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, Yonghyun Hwang, LKML, Michal Marek, raphael.gault, Mark Brown, linux-hardening, Pete Swain, live-patching, Will Deacon, Ard Biesheuvel, Linux ARM, Kees Cook On Tue, Feb 2, 2021 at 3:36 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > On Tue, Feb 02, 2021 at 02:33:38PM -0800, Nick Desaulniers wrote: > > On Mon, Feb 1, 2021 at 4:02 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > > > > > On Mon, Feb 01, 2021 at 03:17:40PM -0800, Nick Desaulniers wrote: > > > And yes, objtool has been pretty good at finding compiler bugs, so the > > > more coverage the better. > > > > The idea of rebuilding control flow from binary analysis and using > > > > that to find codegen bugs is a really cool idea (novel, even? idk), > > > > and I wish we had some analog for userspace binaries that could > > > > perform similar checks. > > > > > > Objtool is generic in many ways -- in fact I recently heard from a PhD > > > candidate who used it successfully on another kernel for an ORC > > > unwinder. > > > > That's pretty cool! Reuse outside the initial context is always a > > good sign that something was designed right. > > So basically you're saying objtool is both useful and well-designed. I > will quote you on that! Haha, all I'm saying is that while I'm not proud that it did find bugs in LLVM (and I do have existing bugs found by it to fix on my plate), I don't see who else or how else those would have been spotted, and I can appreciate that. I think the tools given to us are broken (by design, perhaps), so anything that can help us spot issues might help our code live longer than we do. I also think that there's room for improvement and experimentation in debug info formats, though there is currently a proliferation to support. Live patching and eBPF seem to have some functional overlap IIUC, strengths/weaknesses, and their own unique debug info formats to go with it. Supporting each one does require some level of toolchain support or coordination (or complexity, even). -- Thanks, ~Nick Desaulniers _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 2021-02-01 23:17 ` Nick Desaulniers @ 2021-02-02 8:57 ` Julien Thierry -1 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-02-02 8:57 UTC (permalink / raw) To: Nick Desaulniers, Josh Poimboeuf Cc: Ard Biesheuvel, Mark Brown, Catalin Marinas, Kees Cook, Linux ARM, linux-efi, linux-hardening, LKML, Mark Rutland, Masahiro Yamada, Michal Marek, Peter Zijlstra, raphael.gault, Will Deacon, clang-built-linux, Bill Wendling On 2/2/21 12:17 AM, Nick Desaulniers wrote: > On Mon, Feb 1, 2021 at 1:44 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: >> >> On Fri, Jan 29, 2021 at 10:10:01AM -0800, Nick Desaulniers wrote: >>> On Wed, Jan 27, 2021 at 3:27 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: >>>> >>>> On Wed, Jan 27, 2021 at 02:15:57PM -0800, Nick Desaulniers wrote: >>>>>> From: Raphael Gault <raphael.gault@arm.com> >>>>>> >>>>>> This plugins comes into play before the final 2 RTL passes of GCC and >>>>>> detects switch-tables that are to be outputed in the ELF and writes >>>>>> information in an ".discard.switch_table_info" section which will be >>>>>> used by objtool. >>>>>> >>>>>> Signed-off-by: Raphael Gault <raphael.gault@arm.com> >>>>>> [J.T.: Change section name to store switch table information, >>>>>> Make plugin Kconfig be selected rather than opt-in by user, >>>>>> Add a relocation in the switch_table_info that points to >>>>>> the jump operation itself] >>>>>> Signed-off-by: Julien Thierry <jthierry@redhat.com> >>>>> >>>>> Rather than tightly couple this feature to a particular toolchain via >>>>> plugin, it might be nice to consider what features could be spec'ed out >>>>> for toolchains to implement (perhaps via a -f flag). >>>> >>>> The problem is being able to detect switch statement jump table vectors. >>>> >>>> For a given indirect branch (due to a switch statement), what are all >>>> the corresponding jump targets? >>>> >>>> We would need the compiler to annotate that information somehow. >>> >>> Makes sense, the compiler should have this information. How is this >>> problem solved on x86? >> >> Thus far we've been able to successfully reverse engineer it on x86, >> though it hasn't been easy. >> >> There were some particulars for arm64 which made doing so impossible. >> (I don't remember the details.) The main issue is that the tables for arm64 have more indirection than x86. On x86, the dispatching jump instruction fetches the target address from a contiguous array of addresses based on a given offset. So the list of potential targets of the jump is neatly organized in a table (and sure, before link time these are just relocation, but still processable). On arm64 (with GCC at least), what is stored in a table is an array of candidate offsets from the jump instruction. And because arm64 is limited to 32bit instructions, the encoding often requires multiple instructions to compute the target address: ldr<*> x_offset, [x_offsets_table, x_index, ...] // load offset adr x_dest_base, <addr> // load target branch for offset 0 add x_dest, x_target_base, x_offset, ... // compute final address br x_dest // jump Where this gets trickier is that (with GCC) the offsets stored in the table might or might not be signed constants (and this can be seen in GCC intermediate representations, but I do not believe this information is output in the final object file). And on top of that, GCC might decide to use offsets that are seen as unsigned during intermediate representation as signed offset by sign extending them in the add instruction. So, to handle this we'd have to track the different operation done with the offset, from the load to the final jump, decoding the instructions and deducing the potential target instructions from the table of offsets. But that is error prone as we don't really know how many instructions can be between the ones doing the address computation, and I remember some messy case of a jump table inside a jump table where tracking the instruction touching one or the other offset would need a lot of corner case handling. And this of course is just for GCC, I haven't looked at what it all looks like on Clang's end. > > I think the details are pertinent to finding a portable solution. The > commit message of this commit in particular doesn't document such > details, such as why such an approach is necessary or how the data is > laid out for objtool to consume it. > Sorry, I will need to make that clearer. The next patch explains it a bit [1] Basically, for simplicity, the plugin creates a new section containing tables (one per jump table) of references to the jump targets, similar to what x86 has, except that in this case this table isn't actually used by runtime code and is discarded at link time. I only chose this to minimize what needed to be changed in objtool and because the format seemed simple enough. But I'm open on some alternative, whether it's a -fjump-table-info option added to compilers with a different format to do the links. The important requirement is to be able to know all the candidate targets for a "br <reg>" instruction. [1] https://lkml.org/lkml/2021/1/20/910 Thanks, -- Julien Thierry ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 @ 2021-02-02 8:57 ` Julien Thierry 0 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-02-02 8:57 UTC (permalink / raw) To: Nick Desaulniers, Josh Poimboeuf Cc: Mark Rutland, linux-efi, Kees Cook, clang-built-linux, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, LKML, Michal Marek, raphael.gault, Mark Brown, linux-hardening, Will Deacon, Ard Biesheuvel, Linux ARM, Bill Wendling On 2/2/21 12:17 AM, Nick Desaulniers wrote: > On Mon, Feb 1, 2021 at 1:44 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: >> >> On Fri, Jan 29, 2021 at 10:10:01AM -0800, Nick Desaulniers wrote: >>> On Wed, Jan 27, 2021 at 3:27 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: >>>> >>>> On Wed, Jan 27, 2021 at 02:15:57PM -0800, Nick Desaulniers wrote: >>>>>> From: Raphael Gault <raphael.gault@arm.com> >>>>>> >>>>>> This plugins comes into play before the final 2 RTL passes of GCC and >>>>>> detects switch-tables that are to be outputed in the ELF and writes >>>>>> information in an ".discard.switch_table_info" section which will be >>>>>> used by objtool. >>>>>> >>>>>> Signed-off-by: Raphael Gault <raphael.gault@arm.com> >>>>>> [J.T.: Change section name to store switch table information, >>>>>> Make plugin Kconfig be selected rather than opt-in by user, >>>>>> Add a relocation in the switch_table_info that points to >>>>>> the jump operation itself] >>>>>> Signed-off-by: Julien Thierry <jthierry@redhat.com> >>>>> >>>>> Rather than tightly couple this feature to a particular toolchain via >>>>> plugin, it might be nice to consider what features could be spec'ed out >>>>> for toolchains to implement (perhaps via a -f flag). >>>> >>>> The problem is being able to detect switch statement jump table vectors. >>>> >>>> For a given indirect branch (due to a switch statement), what are all >>>> the corresponding jump targets? >>>> >>>> We would need the compiler to annotate that information somehow. >>> >>> Makes sense, the compiler should have this information. How is this >>> problem solved on x86? >> >> Thus far we've been able to successfully reverse engineer it on x86, >> though it hasn't been easy. >> >> There were some particulars for arm64 which made doing so impossible. >> (I don't remember the details.) The main issue is that the tables for arm64 have more indirection than x86. On x86, the dispatching jump instruction fetches the target address from a contiguous array of addresses based on a given offset. So the list of potential targets of the jump is neatly organized in a table (and sure, before link time these are just relocation, but still processable). On arm64 (with GCC at least), what is stored in a table is an array of candidate offsets from the jump instruction. And because arm64 is limited to 32bit instructions, the encoding often requires multiple instructions to compute the target address: ldr<*> x_offset, [x_offsets_table, x_index, ...] // load offset adr x_dest_base, <addr> // load target branch for offset 0 add x_dest, x_target_base, x_offset, ... // compute final address br x_dest // jump Where this gets trickier is that (with GCC) the offsets stored in the table might or might not be signed constants (and this can be seen in GCC intermediate representations, but I do not believe this information is output in the final object file). And on top of that, GCC might decide to use offsets that are seen as unsigned during intermediate representation as signed offset by sign extending them in the add instruction. So, to handle this we'd have to track the different operation done with the offset, from the load to the final jump, decoding the instructions and deducing the potential target instructions from the table of offsets. But that is error prone as we don't really know how many instructions can be between the ones doing the address computation, and I remember some messy case of a jump table inside a jump table where tracking the instruction touching one or the other offset would need a lot of corner case handling. And this of course is just for GCC, I haven't looked at what it all looks like on Clang's end. > > I think the details are pertinent to finding a portable solution. The > commit message of this commit in particular doesn't document such > details, such as why such an approach is necessary or how the data is > laid out for objtool to consume it. > Sorry, I will need to make that clearer. The next patch explains it a bit [1] Basically, for simplicity, the plugin creates a new section containing tables (one per jump table) of references to the jump targets, similar to what x86 has, except that in this case this table isn't actually used by runtime code and is discarded at link time. I only chose this to minimize what needed to be changed in objtool and because the format seemed simple enough. But I'm open on some alternative, whether it's a -fjump-table-info option added to compilers with a different format to do the links. The important requirement is to be able to know all the candidate targets for a "br <reg>" instruction. [1] https://lkml.org/lkml/2021/1/20/910 Thanks, -- Julien Thierry _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 2021-02-02 8:57 ` Julien Thierry @ 2021-02-02 23:01 ` Nick Desaulniers -1 siblings, 0 replies; 106+ messages in thread From: Nick Desaulniers @ 2021-02-02 23:01 UTC (permalink / raw) To: Julien Thierry Cc: Josh Poimboeuf, Ard Biesheuvel, Mark Brown, Catalin Marinas, Kees Cook, Linux ARM, linux-efi, linux-hardening, LKML, Mark Rutland, Masahiro Yamada, Michal Marek, Peter Zijlstra, raphael.gault, Will Deacon, clang-built-linux, Bill Wendling, swine, yonghyun On Tue, Feb 2, 2021 at 12:57 AM Julien Thierry <jthierry@redhat.com> wrote: > > > > On 2/2/21 12:17 AM, Nick Desaulniers wrote: > > On Mon, Feb 1, 2021 at 1:44 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > >> > >> On Fri, Jan 29, 2021 at 10:10:01AM -0800, Nick Desaulniers wrote: > >>> On Wed, Jan 27, 2021 at 3:27 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > >>>> > >>>> On Wed, Jan 27, 2021 at 02:15:57PM -0800, Nick Desaulniers wrote: > >>>>>> From: Raphael Gault <raphael.gault@arm.com> > >>>>>> > >>>>>> This plugins comes into play before the final 2 RTL passes of GCC and > >>>>>> detects switch-tables that are to be outputed in the ELF and writes > >>>>>> information in an ".discard.switch_table_info" section which will be > >>>>>> used by objtool. > >>>>>> > >>>>>> Signed-off-by: Raphael Gault <raphael.gault@arm.com> > >>>>>> [J.T.: Change section name to store switch table information, > >>>>>> Make plugin Kconfig be selected rather than opt-in by user, > >>>>>> Add a relocation in the switch_table_info that points to > >>>>>> the jump operation itself] > >>>>>> Signed-off-by: Julien Thierry <jthierry@redhat.com> > >>>>> > >>>>> Rather than tightly couple this feature to a particular toolchain via > >>>>> plugin, it might be nice to consider what features could be spec'ed out > >>>>> for toolchains to implement (perhaps via a -f flag). > >>>> > >>>> The problem is being able to detect switch statement jump table vectors. > >>>> > >>>> For a given indirect branch (due to a switch statement), what are all > >>>> the corresponding jump targets? > >>>> > >>>> We would need the compiler to annotate that information somehow. > >>> > >>> Makes sense, the compiler should have this information. How is this > >>> problem solved on x86? > >> > >> Thus far we've been able to successfully reverse engineer it on x86, > >> though it hasn't been easy. > >> > >> There were some particulars for arm64 which made doing so impossible. > >> (I don't remember the details.) > > The main issue is that the tables for arm64 have more indirection than x86. I wonder if PAC or BTI also make this slightly more complex? PAC at least has implications for unwinders, IIUC. > > On x86, the dispatching jump instruction fetches the target address from > a contiguous array of addresses based on a given offset. So the list of > potential targets of the jump is neatly organized in a table (and sure, > before link time these are just relocation, but still processable). > > On arm64 (with GCC at least), what is stored in a table is an array of > candidate offsets from the jump instruction. And because arm64 is > limited to 32bit instructions, the encoding often requires multiple > instructions to compute the target address: > > ldr<*> x_offset, [x_offsets_table, x_index, ...] // load offset > adr x_dest_base, <addr> // load target branch for offset 0 > add x_dest, x_target_base, x_offset, ... // compute final address > br x_dest // jump > > Where this gets trickier is that (with GCC) the offsets stored in the > table might or might not be signed constants (and this can be seen in > GCC intermediate representations, but I do not believe this information > is output in the final object file). And on top of that, GCC might > decide to use offsets that are seen as unsigned during intermediate > representation as signed offset by sign extending them in the add > instruction. > > So, to handle this we'd have to track the different operation done with > the offset, from the load to the final jump, decoding the instructions > and deducing the potential target instructions from the table of offsets. > > But that is error prone as we don't really know how many instructions > can be between the ones doing the address computation, and I remember > some messy case of a jump table inside a jump table where tracking the > instruction touching one or the other offset would need a lot of corner > case handling. > > And this of course is just for GCC, I haven't looked at what it all > looks like on Clang's end. Sure, but this is what production unwinders do, and they don't require compiler plugins, right? I don't doubt unwinders can be made simpler with changes to toolchain output; please work with your compiler vendor on making such changes rather than relying on compiler plugins to do so. > > I think the details are pertinent to finding a portable solution. The > > commit message of this commit in particular doesn't document such > > details, such as why such an approach is necessary or how the data is > > laid out for objtool to consume it. > > > > Sorry, I will need to make that clearer. The next patch explains it a > bit [1] > > Basically, for simplicity, the plugin creates a new section containing Right, this takes a focus on simplicity, at the cost of alienating a toolchain. Ard's point about 3193c0836f20 relating to -fgcse is that when presented with tricky cases to unwind, the simplest approach is taken. There it was disabling a compiler specific compiler optimization, here it's either a compiler specific compiler plugin (or disabling another compiler optimization). The pattern seems to be "Objtool isn't smart enough" ... "compiler optimization disabled" or "compiler plugin dependency." > tables (one per jump table) of references to the jump targets, similar > to what x86 has, except that in this case this table isn't actually used > by runtime code and is discarded at link time. I only chose this to > minimize what needed to be changed in objtool and because the format > seemed simple enough. > > But I'm open on some alternative, whether it's a -fjump-table-info Yes, I think we could spec out something like that. But I would appreciate revisiting open questions around stack validation (frame pointers), preventing the generation of jump tables to begin with (-fno-jump-tables) in place of making objtool more robust, or generally the need to depend on compiler plugins. > option added to compilers with a different format to do the links. The > important requirement is to be able to know all the candidate targets > for a "br <reg>" instruction. > > [1] https://lkml.org/lkml/2021/1/20/910 > > Thanks, > > -- > Julien Thierry > -- Thanks, ~Nick Desaulniers ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 @ 2021-02-02 23:01 ` Nick Desaulniers 0 siblings, 0 replies; 106+ messages in thread From: Nick Desaulniers @ 2021-02-02 23:01 UTC (permalink / raw) To: Julien Thierry Cc: Mark Rutland, swine, linux-efi, Kees Cook, clang-built-linux, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, yonghyun, LKML, Michal Marek, raphael.gault, Mark Brown, linux-hardening, Josh Poimboeuf, Will Deacon, Ard Biesheuvel, Linux ARM, Bill Wendling On Tue, Feb 2, 2021 at 12:57 AM Julien Thierry <jthierry@redhat.com> wrote: > > > > On 2/2/21 12:17 AM, Nick Desaulniers wrote: > > On Mon, Feb 1, 2021 at 1:44 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > >> > >> On Fri, Jan 29, 2021 at 10:10:01AM -0800, Nick Desaulniers wrote: > >>> On Wed, Jan 27, 2021 at 3:27 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: > >>>> > >>>> On Wed, Jan 27, 2021 at 02:15:57PM -0800, Nick Desaulniers wrote: > >>>>>> From: Raphael Gault <raphael.gault@arm.com> > >>>>>> > >>>>>> This plugins comes into play before the final 2 RTL passes of GCC and > >>>>>> detects switch-tables that are to be outputed in the ELF and writes > >>>>>> information in an ".discard.switch_table_info" section which will be > >>>>>> used by objtool. > >>>>>> > >>>>>> Signed-off-by: Raphael Gault <raphael.gault@arm.com> > >>>>>> [J.T.: Change section name to store switch table information, > >>>>>> Make plugin Kconfig be selected rather than opt-in by user, > >>>>>> Add a relocation in the switch_table_info that points to > >>>>>> the jump operation itself] > >>>>>> Signed-off-by: Julien Thierry <jthierry@redhat.com> > >>>>> > >>>>> Rather than tightly couple this feature to a particular toolchain via > >>>>> plugin, it might be nice to consider what features could be spec'ed out > >>>>> for toolchains to implement (perhaps via a -f flag). > >>>> > >>>> The problem is being able to detect switch statement jump table vectors. > >>>> > >>>> For a given indirect branch (due to a switch statement), what are all > >>>> the corresponding jump targets? > >>>> > >>>> We would need the compiler to annotate that information somehow. > >>> > >>> Makes sense, the compiler should have this information. How is this > >>> problem solved on x86? > >> > >> Thus far we've been able to successfully reverse engineer it on x86, > >> though it hasn't been easy. > >> > >> There were some particulars for arm64 which made doing so impossible. > >> (I don't remember the details.) > > The main issue is that the tables for arm64 have more indirection than x86. I wonder if PAC or BTI also make this slightly more complex? PAC at least has implications for unwinders, IIUC. > > On x86, the dispatching jump instruction fetches the target address from > a contiguous array of addresses based on a given offset. So the list of > potential targets of the jump is neatly organized in a table (and sure, > before link time these are just relocation, but still processable). > > On arm64 (with GCC at least), what is stored in a table is an array of > candidate offsets from the jump instruction. And because arm64 is > limited to 32bit instructions, the encoding often requires multiple > instructions to compute the target address: > > ldr<*> x_offset, [x_offsets_table, x_index, ...] // load offset > adr x_dest_base, <addr> // load target branch for offset 0 > add x_dest, x_target_base, x_offset, ... // compute final address > br x_dest // jump > > Where this gets trickier is that (with GCC) the offsets stored in the > table might or might not be signed constants (and this can be seen in > GCC intermediate representations, but I do not believe this information > is output in the final object file). And on top of that, GCC might > decide to use offsets that are seen as unsigned during intermediate > representation as signed offset by sign extending them in the add > instruction. > > So, to handle this we'd have to track the different operation done with > the offset, from the load to the final jump, decoding the instructions > and deducing the potential target instructions from the table of offsets. > > But that is error prone as we don't really know how many instructions > can be between the ones doing the address computation, and I remember > some messy case of a jump table inside a jump table where tracking the > instruction touching one or the other offset would need a lot of corner > case handling. > > And this of course is just for GCC, I haven't looked at what it all > looks like on Clang's end. Sure, but this is what production unwinders do, and they don't require compiler plugins, right? I don't doubt unwinders can be made simpler with changes to toolchain output; please work with your compiler vendor on making such changes rather than relying on compiler plugins to do so. > > I think the details are pertinent to finding a portable solution. The > > commit message of this commit in particular doesn't document such > > details, such as why such an approach is necessary or how the data is > > laid out for objtool to consume it. > > > > Sorry, I will need to make that clearer. The next patch explains it a > bit [1] > > Basically, for simplicity, the plugin creates a new section containing Right, this takes a focus on simplicity, at the cost of alienating a toolchain. Ard's point about 3193c0836f20 relating to -fgcse is that when presented with tricky cases to unwind, the simplest approach is taken. There it was disabling a compiler specific compiler optimization, here it's either a compiler specific compiler plugin (or disabling another compiler optimization). The pattern seems to be "Objtool isn't smart enough" ... "compiler optimization disabled" or "compiler plugin dependency." > tables (one per jump table) of references to the jump targets, similar > to what x86 has, except that in this case this table isn't actually used > by runtime code and is discarded at link time. I only chose this to > minimize what needed to be changed in objtool and because the format > seemed simple enough. > > But I'm open on some alternative, whether it's a -fjump-table-info Yes, I think we could spec out something like that. But I would appreciate revisiting open questions around stack validation (frame pointers), preventing the generation of jump tables to begin with (-fno-jump-tables) in place of making objtool more robust, or generally the need to depend on compiler plugins. > option added to compilers with a different format to do the links. The > important requirement is to be able to know all the candidate targets > for a "br <reg>" instruction. > > [1] https://lkml.org/lkml/2021/1/20/910 > > Thanks, > > -- > Julien Thierry > -- Thanks, ~Nick Desaulniers _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 2021-02-02 23:01 ` Nick Desaulniers @ 2021-02-03 0:14 ` Josh Poimboeuf -1 siblings, 0 replies; 106+ messages in thread From: Josh Poimboeuf @ 2021-02-03 0:14 UTC (permalink / raw) To: Nick Desaulniers Cc: Julien Thierry, Ard Biesheuvel, Mark Brown, Catalin Marinas, Kees Cook, Linux ARM, linux-efi, linux-hardening, LKML, Mark Rutland, Masahiro Yamada, Michal Marek, Peter Zijlstra, raphael.gault, Will Deacon, clang-built-linux, Bill Wendling, swine, yonghyun On Tue, Feb 02, 2021 at 03:01:22PM -0800, Nick Desaulniers wrote: > > >> Thus far we've been able to successfully reverse engineer it on x86, > > >> though it hasn't been easy. > > >> > > >> There were some particulars for arm64 which made doing so impossible. > > >> (I don't remember the details.) > > > > The main issue is that the tables for arm64 have more indirection than x86. > > I wonder if PAC or BTI also make this slightly more complex? PAC at > least has implications for unwinders, IIUC. What is PAC/BTI? > > On x86, the dispatching jump instruction fetches the target address from > > a contiguous array of addresses based on a given offset. So the list of > > potential targets of the jump is neatly organized in a table (and sure, > > before link time these are just relocation, but still processable). > > > > On arm64 (with GCC at least), what is stored in a table is an array of > > candidate offsets from the jump instruction. And because arm64 is > > limited to 32bit instructions, the encoding often requires multiple > > instructions to compute the target address: > > > > ldr<*> x_offset, [x_offsets_table, x_index, ...] // load offset > > adr x_dest_base, <addr> // load target branch for offset 0 > > add x_dest, x_target_base, x_offset, ... // compute final address > > br x_dest // jump > > > > Where this gets trickier is that (with GCC) the offsets stored in the > > table might or might not be signed constants (and this can be seen in > > GCC intermediate representations, but I do not believe this information > > is output in the final object file). And on top of that, GCC might > > decide to use offsets that are seen as unsigned during intermediate > > representation as signed offset by sign extending them in the add > > instruction. > > > > So, to handle this we'd have to track the different operation done with > > the offset, from the load to the final jump, decoding the instructions > > and deducing the potential target instructions from the table of offsets. > > > > But that is error prone as we don't really know how many instructions > > can be between the ones doing the address computation, and I remember > > some messy case of a jump table inside a jump table where tracking the > > instruction touching one or the other offset would need a lot of corner > > case handling. > > > > And this of course is just for GCC, I haven't looked at what it all > > looks like on Clang's end. > > Sure, but this is what production unwinders do, and they don't require > compiler plugins, right? What do you mean by "production unwinders"? Generally unwinders rely on either frame pointers or DWARF, but (without validation) those aren't robust enough for live patching in the kernel, so I'm not sure how this is relevant. > > > I think the details are pertinent to finding a portable solution. The > > > commit message of this commit in particular doesn't document such > > > details, such as why such an approach is necessary or how the data is > > > laid out for objtool to consume it. > > > > > > > Sorry, I will need to make that clearer. The next patch explains it a > > bit [1] > > > > Basically, for simplicity, the plugin creates a new section containing > > Right, this takes a focus on simplicity, at the cost of alienating a toolchain. > > Ard's point about 3193c0836f20 relating to -fgcse is that when > presented with tricky cases to unwind, the simplest approach is taken. > There it was disabling a compiler specific compiler optimization, here > it's either a compiler specific compiler plugin (or disabling another > compiler optimization). The pattern seems to be "Objtool isn't smart > enough" ... "compiler optimization disabled" or "compiler plugin > dependency." You're taking the two absolute worst case scenarios (one of which is just a patch which doesn't look like it's going to get merged anyway) and drawing a false narrative. In this case the simplest approach would have been to just give up and disable jump tables. We try as hard as possible (beyond turning objtool into a full emulator) to avoid doing that kind of thing because objtool isn't supposed to dictate kernel optimizations. Otherwise we would have disabled jump tables (even for non-retpolines) a long time ago, because that's been a serious PITA. You might not like the plugin -- I don't like it either -- but the goal was to avoid penalizing the kernel with "objtool-friendly" optimizations. That said, jump tables are such a pain for objtool (and currently impossible to deal with for arm64) that I'm completely open to just disabling them if they're shown to have negligible benefit for the kernel. -- Josh ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 @ 2021-02-03 0:14 ` Josh Poimboeuf 0 siblings, 0 replies; 106+ messages in thread From: Josh Poimboeuf @ 2021-02-03 0:14 UTC (permalink / raw) To: Nick Desaulniers Cc: Mark Rutland, Bill Wendling, linux-efi, Julien Thierry, clang-built-linux, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, yonghyun, LKML, Michal Marek, raphael.gault, Mark Brown, linux-hardening, swine, Will Deacon, Ard Biesheuvel, Linux ARM, Kees Cook On Tue, Feb 02, 2021 at 03:01:22PM -0800, Nick Desaulniers wrote: > > >> Thus far we've been able to successfully reverse engineer it on x86, > > >> though it hasn't been easy. > > >> > > >> There were some particulars for arm64 which made doing so impossible. > > >> (I don't remember the details.) > > > > The main issue is that the tables for arm64 have more indirection than x86. > > I wonder if PAC or BTI also make this slightly more complex? PAC at > least has implications for unwinders, IIUC. What is PAC/BTI? > > On x86, the dispatching jump instruction fetches the target address from > > a contiguous array of addresses based on a given offset. So the list of > > potential targets of the jump is neatly organized in a table (and sure, > > before link time these are just relocation, but still processable). > > > > On arm64 (with GCC at least), what is stored in a table is an array of > > candidate offsets from the jump instruction. And because arm64 is > > limited to 32bit instructions, the encoding often requires multiple > > instructions to compute the target address: > > > > ldr<*> x_offset, [x_offsets_table, x_index, ...] // load offset > > adr x_dest_base, <addr> // load target branch for offset 0 > > add x_dest, x_target_base, x_offset, ... // compute final address > > br x_dest // jump > > > > Where this gets trickier is that (with GCC) the offsets stored in the > > table might or might not be signed constants (and this can be seen in > > GCC intermediate representations, but I do not believe this information > > is output in the final object file). And on top of that, GCC might > > decide to use offsets that are seen as unsigned during intermediate > > representation as signed offset by sign extending them in the add > > instruction. > > > > So, to handle this we'd have to track the different operation done with > > the offset, from the load to the final jump, decoding the instructions > > and deducing the potential target instructions from the table of offsets. > > > > But that is error prone as we don't really know how many instructions > > can be between the ones doing the address computation, and I remember > > some messy case of a jump table inside a jump table where tracking the > > instruction touching one or the other offset would need a lot of corner > > case handling. > > > > And this of course is just for GCC, I haven't looked at what it all > > looks like on Clang's end. > > Sure, but this is what production unwinders do, and they don't require > compiler plugins, right? What do you mean by "production unwinders"? Generally unwinders rely on either frame pointers or DWARF, but (without validation) those aren't robust enough for live patching in the kernel, so I'm not sure how this is relevant. > > > I think the details are pertinent to finding a portable solution. The > > > commit message of this commit in particular doesn't document such > > > details, such as why such an approach is necessary or how the data is > > > laid out for objtool to consume it. > > > > > > > Sorry, I will need to make that clearer. The next patch explains it a > > bit [1] > > > > Basically, for simplicity, the plugin creates a new section containing > > Right, this takes a focus on simplicity, at the cost of alienating a toolchain. > > Ard's point about 3193c0836f20 relating to -fgcse is that when > presented with tricky cases to unwind, the simplest approach is taken. > There it was disabling a compiler specific compiler optimization, here > it's either a compiler specific compiler plugin (or disabling another > compiler optimization). The pattern seems to be "Objtool isn't smart > enough" ... "compiler optimization disabled" or "compiler plugin > dependency." You're taking the two absolute worst case scenarios (one of which is just a patch which doesn't look like it's going to get merged anyway) and drawing a false narrative. In this case the simplest approach would have been to just give up and disable jump tables. We try as hard as possible (beyond turning objtool into a full emulator) to avoid doing that kind of thing because objtool isn't supposed to dictate kernel optimizations. Otherwise we would have disabled jump tables (even for non-retpolines) a long time ago, because that's been a serious PITA. You might not like the plugin -- I don't like it either -- but the goal was to avoid penalizing the kernel with "objtool-friendly" optimizations. That said, jump tables are such a pain for objtool (and currently impossible to deal with for arm64) that I'm completely open to just disabling them if they're shown to have negligible benefit for the kernel. -- Josh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 2021-02-03 0:14 ` Josh Poimboeuf @ 2021-02-03 11:57 ` Peter Zijlstra -1 siblings, 0 replies; 106+ messages in thread From: Peter Zijlstra @ 2021-02-03 11:57 UTC (permalink / raw) To: Josh Poimboeuf Cc: Nick Desaulniers, Julien Thierry, Ard Biesheuvel, Mark Brown, Catalin Marinas, Kees Cook, Linux ARM, linux-efi, linux-hardening, LKML, Mark Rutland, Masahiro Yamada, Michal Marek, raphael.gault, Will Deacon, clang-built-linux, Bill Wendling, swine, yonghyun On Tue, Feb 02, 2021 at 06:14:14PM -0600, Josh Poimboeuf wrote: > > Sure, but this is what production unwinders do, and they don't require > > compiler plugins, right? > > What do you mean by "production unwinders"? Generally unwinders rely on > either frame pointers or DWARF, but (without validation) those aren't > robust enough for live patching in the kernel, so I'm not sure how this > is relevant. Not to mention that DWARF and consequently it's unders are horribly large, complex and above all fragile things. There's a reason ORC got invented, DWARF is simlpy unacceptable and inadequate. Now, one avenue that has been mentioned in the past, but I've not seen recently, is to have objtool use DWARF as input to help it understand the code. At least in userspace we can rely on DWARF libs. But I'm fairly sure people aren't jumping up and down for having to always build their kernel with DWARFs on, compile speed etc.. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 @ 2021-02-03 11:57 ` Peter Zijlstra 0 siblings, 0 replies; 106+ messages in thread From: Peter Zijlstra @ 2021-02-03 11:57 UTC (permalink / raw) To: Josh Poimboeuf Cc: Mark Rutland, Bill Wendling, linux-efi, Julien Thierry, clang-built-linux, Catalin Marinas, Masahiro Yamada, Nick Desaulniers, LKML, Michal Marek, raphael.gault, Mark Brown, linux-hardening, swine, yonghyun, Will Deacon, Ard Biesheuvel, Linux ARM, Kees Cook On Tue, Feb 02, 2021 at 06:14:14PM -0600, Josh Poimboeuf wrote: > > Sure, but this is what production unwinders do, and they don't require > > compiler plugins, right? > > What do you mean by "production unwinders"? Generally unwinders rely on > either frame pointers or DWARF, but (without validation) those aren't > robust enough for live patching in the kernel, so I'm not sure how this > is relevant. Not to mention that DWARF and consequently it's unders are horribly large, complex and above all fragile things. There's a reason ORC got invented, DWARF is simlpy unacceptable and inadequate. Now, one avenue that has been mentioned in the past, but I've not seen recently, is to have objtool use DWARF as input to help it understand the code. At least in userspace we can rely on DWARF libs. But I'm fairly sure people aren't jumping up and down for having to always build their kernel with DWARFs on, compile speed etc.. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 2021-02-03 0:14 ` Josh Poimboeuf @ 2021-02-03 13:04 ` Mark Brown -1 siblings, 0 replies; 106+ messages in thread From: Mark Brown @ 2021-02-03 13:04 UTC (permalink / raw) To: Josh Poimboeuf Cc: Nick Desaulniers, Julien Thierry, Ard Biesheuvel, Catalin Marinas, Kees Cook, Linux ARM, linux-efi, linux-hardening, LKML, Mark Rutland, Masahiro Yamada, Michal Marek, Peter Zijlstra, raphael.gault, Will Deacon, clang-built-linux, Bill Wendling, swine, yonghyun [-- Attachment #1: Type: text/plain, Size: 617 bytes --] On Tue, Feb 02, 2021 at 06:14:14PM -0600, Josh Poimboeuf wrote: > On Tue, Feb 02, 2021 at 03:01:22PM -0800, Nick Desaulniers wrote: > > I wonder if PAC or BTI also make this slightly more complex? PAC at > > least has implications for unwinders, IIUC. > What is PAC/BTI? PAC and BTI are ARM architecture extensions. PAC uses a tag in pointers to sign and verify them, presenting a barrier to ROP, and when BTI is active only specific instructions can be branched to. Since PAC modifies pointers when it is active the unwinder has to undo the tagging to understand what's being pointed to, that's already there. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 @ 2021-02-03 13:04 ` Mark Brown 0 siblings, 0 replies; 106+ messages in thread From: Mark Brown @ 2021-02-03 13:04 UTC (permalink / raw) To: Josh Poimboeuf Cc: Mark Rutland, Bill Wendling, linux-efi, Julien Thierry, yonghyun, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, Nick Desaulniers, LKML, clang-built-linux, raphael.gault, Michal Marek, linux-hardening, swine, Will Deacon, Ard Biesheuvel, Linux ARM, Kees Cook [-- Attachment #1.1: Type: text/plain, Size: 617 bytes --] On Tue, Feb 02, 2021 at 06:14:14PM -0600, Josh Poimboeuf wrote: > On Tue, Feb 02, 2021 at 03:01:22PM -0800, Nick Desaulniers wrote: > > I wonder if PAC or BTI also make this slightly more complex? PAC at > > least has implications for unwinders, IIUC. > What is PAC/BTI? PAC and BTI are ARM architecture extensions. PAC uses a tag in pointers to sign and verify them, presenting a barrier to ROP, and when BTI is active only specific instructions can be branched to. Since PAC modifies pointers when it is active the unwinder has to undo the tagging to understand what's being pointed to, that's already there. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 2021-02-03 0:14 ` Josh Poimboeuf @ 2021-02-03 13:58 ` Mark Rutland -1 siblings, 0 replies; 106+ messages in thread From: Mark Rutland @ 2021-02-03 13:58 UTC (permalink / raw) To: Josh Poimboeuf Cc: Nick Desaulniers, Julien Thierry, Ard Biesheuvel, Mark Brown, Catalin Marinas, Kees Cook, Linux ARM, linux-efi, linux-hardening, LKML, Masahiro Yamada, Michal Marek, Peter Zijlstra, raphael.gault, Will Deacon, clang-built-linux, Bill Wendling, swine, yonghyun On Tue, Feb 02, 2021 at 06:14:14PM -0600, Josh Poimboeuf wrote: > On Tue, Feb 02, 2021 at 03:01:22PM -0800, Nick Desaulniers wrote: > > > >> Thus far we've been able to successfully reverse engineer it on x86, > > > >> though it hasn't been easy. > > > >> > > > >> There were some particulars for arm64 which made doing so impossible. > > > >> (I don't remember the details.) > > > > > > The main issue is that the tables for arm64 have more indirection than x86. > > > > I wonder if PAC or BTI also make this slightly more complex? PAC at > > least has implications for unwinders, IIUC. > > What is PAC/BTI? PAC is "Pointer Authentication Codes". The gist is that we munge some bits in pointers when they get stored in memory (called "signing"), and undo that with a check (called "authentication") when reading from memory, in order to detect unexpected modification. There's some new instructions that may exist in function prologues and epilogues, etc. There's a basic introduction at: https://events.static.linuxfound.org/sites/events/files/slides/slides_23.pdf https://www.kernel.org/doc/html/latest/arm64/pointer-authentication.html Return address signing/authentication uses the SP as an input, so without knowing the SP something was signed against it's not possible to alter it reliably (or to check it). The arm64 unwinder ignores the PAC bits, and ftrace uses patchable-function-entry so that we don't have to do anything special to manipulate the return address. Today the ABI used by the kernel doesn't mess with the pointers used in jump tables, but that may come in future as toolchain folk are working to define an ABI that might. BTI is "Branch Target Identification", which is a bit like CET's indirect branch tracking -- indirect branches need to land on a specific instruction, or they'll raise an exception. Thanks, Mark. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 @ 2021-02-03 13:58 ` Mark Rutland 0 siblings, 0 replies; 106+ messages in thread From: Mark Rutland @ 2021-02-03 13:58 UTC (permalink / raw) To: Josh Poimboeuf Cc: swine, Bill Wendling, linux-efi, Julien Thierry, clang-built-linux, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, Nick Desaulniers, LKML, Michal Marek, raphael.gault, Mark Brown, linux-hardening, yonghyun, Will Deacon, Ard Biesheuvel, Linux ARM, Kees Cook On Tue, Feb 02, 2021 at 06:14:14PM -0600, Josh Poimboeuf wrote: > On Tue, Feb 02, 2021 at 03:01:22PM -0800, Nick Desaulniers wrote: > > > >> Thus far we've been able to successfully reverse engineer it on x86, > > > >> though it hasn't been easy. > > > >> > > > >> There were some particulars for arm64 which made doing so impossible. > > > >> (I don't remember the details.) > > > > > > The main issue is that the tables for arm64 have more indirection than x86. > > > > I wonder if PAC or BTI also make this slightly more complex? PAC at > > least has implications for unwinders, IIUC. > > What is PAC/BTI? PAC is "Pointer Authentication Codes". The gist is that we munge some bits in pointers when they get stored in memory (called "signing"), and undo that with a check (called "authentication") when reading from memory, in order to detect unexpected modification. There's some new instructions that may exist in function prologues and epilogues, etc. There's a basic introduction at: https://events.static.linuxfound.org/sites/events/files/slides/slides_23.pdf https://www.kernel.org/doc/html/latest/arm64/pointer-authentication.html Return address signing/authentication uses the SP as an input, so without knowing the SP something was signed against it's not possible to alter it reliably (or to check it). The arm64 unwinder ignores the PAC bits, and ftrace uses patchable-function-entry so that we don't have to do anything special to manipulate the return address. Today the ABI used by the kernel doesn't mess with the pointers used in jump tables, but that may come in future as toolchain folk are working to define an ABI that might. BTI is "Branch Target Identification", which is a bit like CET's indirect branch tracking -- indirect branches need to land on a specific instruction, or they'll raise an exception. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 2021-02-02 23:01 ` Nick Desaulniers @ 2021-02-03 8:11 ` Julien Thierry -1 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-02-03 8:11 UTC (permalink / raw) To: Nick Desaulniers Cc: Josh Poimboeuf, Ard Biesheuvel, Mark Brown, Catalin Marinas, Kees Cook, Linux ARM, linux-efi, linux-hardening, LKML, Mark Rutland, Masahiro Yamada, Michal Marek, Peter Zijlstra, raphael.gault, Will Deacon, clang-built-linux, Bill Wendling, swine, yonghyun On 2/3/21 12:01 AM, Nick Desaulniers wrote: > On Tue, Feb 2, 2021 at 12:57 AM Julien Thierry <jthierry@redhat.com> wrote: >> >> >> >> On 2/2/21 12:17 AM, Nick Desaulniers wrote: >>> On Mon, Feb 1, 2021 at 1:44 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: >>>> >>>> On Fri, Jan 29, 2021 at 10:10:01AM -0800, Nick Desaulniers wrote: >>>>> On Wed, Jan 27, 2021 at 3:27 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: >>>>>> >>>>>> On Wed, Jan 27, 2021 at 02:15:57PM -0800, Nick Desaulniers wrote: >>>>>>>> From: Raphael Gault <raphael.gault@arm.com> >>>>>>>> >>>>>>>> This plugins comes into play before the final 2 RTL passes of GCC and >>>>>>>> detects switch-tables that are to be outputed in the ELF and writes >>>>>>>> information in an ".discard.switch_table_info" section which will be >>>>>>>> used by objtool. >>>>>>>> >>>>>>>> Signed-off-by: Raphael Gault <raphael.gault@arm.com> >>>>>>>> [J.T.: Change section name to store switch table information, >>>>>>>> Make plugin Kconfig be selected rather than opt-in by user, >>>>>>>> Add a relocation in the switch_table_info that points to >>>>>>>> the jump operation itself] >>>>>>>> Signed-off-by: Julien Thierry <jthierry@redhat.com> >>>>>>> >>>>>>> Rather than tightly couple this feature to a particular toolchain via >>>>>>> plugin, it might be nice to consider what features could be spec'ed out >>>>>>> for toolchains to implement (perhaps via a -f flag). >>>>>> >>>>>> The problem is being able to detect switch statement jump table vectors. >>>>>> >>>>>> For a given indirect branch (due to a switch statement), what are all >>>>>> the corresponding jump targets? >>>>>> >>>>>> We would need the compiler to annotate that information somehow. >>>>> >>>>> Makes sense, the compiler should have this information. How is this >>>>> problem solved on x86? >>>> >>>> Thus far we've been able to successfully reverse engineer it on x86, >>>> though it hasn't been easy. >>>> >>>> There were some particulars for arm64 which made doing so impossible. >>>> (I don't remember the details.) >> >> The main issue is that the tables for arm64 have more indirection than x86. > > I wonder if PAC or BTI also make this slightly more complex? PAC at > least has implications for unwinders, IIUC. > >> >> On x86, the dispatching jump instruction fetches the target address from >> a contiguous array of addresses based on a given offset. So the list of >> potential targets of the jump is neatly organized in a table (and sure, >> before link time these are just relocation, but still processable). >> >> On arm64 (with GCC at least), what is stored in a table is an array of >> candidate offsets from the jump instruction. And because arm64 is >> limited to 32bit instructions, the encoding often requires multiple >> instructions to compute the target address: >> >> ldr<*> x_offset, [x_offsets_table, x_index, ...] // load offset >> adr x_dest_base, <addr> // load target branch for offset 0 >> add x_dest, x_target_base, x_offset, ... // compute final address >> br x_dest // jump >> >> Where this gets trickier is that (with GCC) the offsets stored in the >> table might or might not be signed constants (and this can be seen in >> GCC intermediate representations, but I do not believe this information >> is output in the final object file). And on top of that, GCC might >> decide to use offsets that are seen as unsigned during intermediate >> representation as signed offset by sign extending them in the add >> instruction. >> >> So, to handle this we'd have to track the different operation done with >> the offset, from the load to the final jump, decoding the instructions >> and deducing the potential target instructions from the table of offsets. >> >> But that is error prone as we don't really know how many instructions >> can be between the ones doing the address computation, and I remember >> some messy case of a jump table inside a jump table where tracking the >> instruction touching one or the other offset would need a lot of corner >> case handling. >> >> And this of course is just for GCC, I haven't looked at what it all >> looks like on Clang's end. > > Sure, but this is what production unwinders do, and they don't require > compiler plugins, right? I don't doubt unwinders can be made simpler > with changes to toolchain output; please work with your compiler > vendor on making such changes rather than relying on compiler plugins > to do so. > I think there is a small confusion. The plugin nor the data it generates is not to be used by a kernel unwinder. It's here to allow objtool to assess whether the code being checked can be unwound (?) reliably (not omitting functions). Part of this is checking that a branch/jump in a function does not end up in some code that is not related to the function without setting up a call frame. This is about static validation rather than functionality. >>> I think the details are pertinent to finding a portable solution. The >>> commit message of this commit in particular doesn't document such >>> details, such as why such an approach is necessary or how the data is >>> laid out for objtool to consume it. >>> >> >> Sorry, I will need to make that clearer. The next patch explains it a >> bit [1] >> >> Basically, for simplicity, the plugin creates a new section containing > > Right, this takes a focus on simplicity, at the cost of alienating a toolchain. > > Ard's point about 3193c0836f20 relating to -fgcse is that when > presented with tricky cases to unwind, the simplest approach is taken. > There it was disabling a compiler specific compiler optimization, here > it's either a compiler specific compiler plugin (or disabling another > compiler optimization). The pattern seems to be "Objtool isn't smart > enough" ... "compiler optimization disabled" or "compiler plugin > dependency." > >> tables (one per jump table) of references to the jump targets, similar >> to what x86 has, except that in this case this table isn't actually used >> by runtime code and is discarded at link time. I only chose this to >> minimize what needed to be changed in objtool and because the format >> seemed simple enough. >> >> But I'm open on some alternative, whether it's a -fjump-table-info > > Yes, I think we could spec out something like that. But I would > appreciate revisiting open questions around stack validation (frame > pointers), preventing the generation of jump tables to begin with > (-fno-jump-tables) in place of making objtool more robust, or > generally the need to depend on compiler plugins. > I'll give it a try at least for the arm64 side. Thanks, -- Julien Thierry ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 @ 2021-02-03 8:11 ` Julien Thierry 0 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-02-03 8:11 UTC (permalink / raw) To: Nick Desaulniers Cc: Mark Rutland, swine, linux-efi, Kees Cook, clang-built-linux, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, yonghyun, LKML, Michal Marek, raphael.gault, Mark Brown, linux-hardening, Josh Poimboeuf, Will Deacon, Ard Biesheuvel, Linux ARM, Bill Wendling On 2/3/21 12:01 AM, Nick Desaulniers wrote: > On Tue, Feb 2, 2021 at 12:57 AM Julien Thierry <jthierry@redhat.com> wrote: >> >> >> >> On 2/2/21 12:17 AM, Nick Desaulniers wrote: >>> On Mon, Feb 1, 2021 at 1:44 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: >>>> >>>> On Fri, Jan 29, 2021 at 10:10:01AM -0800, Nick Desaulniers wrote: >>>>> On Wed, Jan 27, 2021 at 3:27 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote: >>>>>> >>>>>> On Wed, Jan 27, 2021 at 02:15:57PM -0800, Nick Desaulniers wrote: >>>>>>>> From: Raphael Gault <raphael.gault@arm.com> >>>>>>>> >>>>>>>> This plugins comes into play before the final 2 RTL passes of GCC and >>>>>>>> detects switch-tables that are to be outputed in the ELF and writes >>>>>>>> information in an ".discard.switch_table_info" section which will be >>>>>>>> used by objtool. >>>>>>>> >>>>>>>> Signed-off-by: Raphael Gault <raphael.gault@arm.com> >>>>>>>> [J.T.: Change section name to store switch table information, >>>>>>>> Make plugin Kconfig be selected rather than opt-in by user, >>>>>>>> Add a relocation in the switch_table_info that points to >>>>>>>> the jump operation itself] >>>>>>>> Signed-off-by: Julien Thierry <jthierry@redhat.com> >>>>>>> >>>>>>> Rather than tightly couple this feature to a particular toolchain via >>>>>>> plugin, it might be nice to consider what features could be spec'ed out >>>>>>> for toolchains to implement (perhaps via a -f flag). >>>>>> >>>>>> The problem is being able to detect switch statement jump table vectors. >>>>>> >>>>>> For a given indirect branch (due to a switch statement), what are all >>>>>> the corresponding jump targets? >>>>>> >>>>>> We would need the compiler to annotate that information somehow. >>>>> >>>>> Makes sense, the compiler should have this information. How is this >>>>> problem solved on x86? >>>> >>>> Thus far we've been able to successfully reverse engineer it on x86, >>>> though it hasn't been easy. >>>> >>>> There were some particulars for arm64 which made doing so impossible. >>>> (I don't remember the details.) >> >> The main issue is that the tables for arm64 have more indirection than x86. > > I wonder if PAC or BTI also make this slightly more complex? PAC at > least has implications for unwinders, IIUC. > >> >> On x86, the dispatching jump instruction fetches the target address from >> a contiguous array of addresses based on a given offset. So the list of >> potential targets of the jump is neatly organized in a table (and sure, >> before link time these are just relocation, but still processable). >> >> On arm64 (with GCC at least), what is stored in a table is an array of >> candidate offsets from the jump instruction. And because arm64 is >> limited to 32bit instructions, the encoding often requires multiple >> instructions to compute the target address: >> >> ldr<*> x_offset, [x_offsets_table, x_index, ...] // load offset >> adr x_dest_base, <addr> // load target branch for offset 0 >> add x_dest, x_target_base, x_offset, ... // compute final address >> br x_dest // jump >> >> Where this gets trickier is that (with GCC) the offsets stored in the >> table might or might not be signed constants (and this can be seen in >> GCC intermediate representations, but I do not believe this information >> is output in the final object file). And on top of that, GCC might >> decide to use offsets that are seen as unsigned during intermediate >> representation as signed offset by sign extending them in the add >> instruction. >> >> So, to handle this we'd have to track the different operation done with >> the offset, from the load to the final jump, decoding the instructions >> and deducing the potential target instructions from the table of offsets. >> >> But that is error prone as we don't really know how many instructions >> can be between the ones doing the address computation, and I remember >> some messy case of a jump table inside a jump table where tracking the >> instruction touching one or the other offset would need a lot of corner >> case handling. >> >> And this of course is just for GCC, I haven't looked at what it all >> looks like on Clang's end. > > Sure, but this is what production unwinders do, and they don't require > compiler plugins, right? I don't doubt unwinders can be made simpler > with changes to toolchain output; please work with your compiler > vendor on making such changes rather than relying on compiler plugins > to do so. > I think there is a small confusion. The plugin nor the data it generates is not to be used by a kernel unwinder. It's here to allow objtool to assess whether the code being checked can be unwound (?) reliably (not omitting functions). Part of this is checking that a branch/jump in a function does not end up in some code that is not related to the function without setting up a call frame. This is about static validation rather than functionality. >>> I think the details are pertinent to finding a portable solution. The >>> commit message of this commit in particular doesn't document such >>> details, such as why such an approach is necessary or how the data is >>> laid out for objtool to consume it. >>> >> >> Sorry, I will need to make that clearer. The next patch explains it a >> bit [1] >> >> Basically, for simplicity, the plugin creates a new section containing > > Right, this takes a focus on simplicity, at the cost of alienating a toolchain. > > Ard's point about 3193c0836f20 relating to -fgcse is that when > presented with tricky cases to unwind, the simplest approach is taken. > There it was disabling a compiler specific compiler optimization, here > it's either a compiler specific compiler plugin (or disabling another > compiler optimization). The pattern seems to be "Objtool isn't smart > enough" ... "compiler optimization disabled" or "compiler plugin > dependency." > >> tables (one per jump table) of references to the jump targets, similar >> to what x86 has, except that in this case this table isn't actually used >> by runtime code and is discarded at link time. I only chose this to >> minimize what needed to be changed in objtool and because the format >> seemed simple enough. >> >> But I'm open on some alternative, whether it's a -fjump-table-info > > Yes, I think we could spec out something like that. But I would > appreciate revisiting open questions around stack validation (frame > pointers), preventing the generation of jump tables to begin with > (-fno-jump-tables) in place of making objtool more robust, or > generally the need to depend on compiler plugins. > I'll give it a try at least for the arm64 side. Thanks, -- Julien Thierry _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 2021-02-02 23:01 ` Nick Desaulniers @ 2021-02-09 16:30 ` Daniel Kiss -1 siblings, 0 replies; 106+ messages in thread From: Daniel Kiss @ 2021-02-09 16:30 UTC (permalink / raw) To: Nick Desaulniers Cc: Julien Thierry, Josh Poimboeuf, Ard Biesheuvel, Mark Brown, Catalin Marinas, Kees Cook, Linux ARM, linux-efi, linux-hardening, LKML, Mark Rutland, Masahiro Yamada, Michal Marek, Peter Zijlstra, Raphaël Gault, Will Deacon, clang-built-linux, Bill Wendling, swine, yonghyun > On 3 Feb 2021, at 00:01, Nick Desaulniers <ndesaulniers@google.com> wrote: > > I wonder if PAC or BTI also make this slightly more complex? PAC at > least has implications for unwinders, IIUC. BTI has effect on the jump target\case because a landing pad is required for each and every target. As I see that would not hurt here. The unwinder shall take care of the PAC signed return address if reads the LR from the stack. DWARF contains an entry where the LR is got signed\authenticated. I’m wondering would be simpler or possible to transform the DWARD to ORC. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 @ 2021-02-09 16:30 ` Daniel Kiss 0 siblings, 0 replies; 106+ messages in thread From: Daniel Kiss @ 2021-02-09 16:30 UTC (permalink / raw) To: Nick Desaulniers Cc: Mark Rutland, Bill Wendling, linux-efi, Julien Thierry, clang-built-linux, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, yonghyun, LKML, Michal Marek, Raphaël Gault, Mark Brown, linux-hardening, swine, Josh Poimboeuf, Will Deacon, Ard Biesheuvel, Linux ARM, Kees Cook > On 3 Feb 2021, at 00:01, Nick Desaulniers <ndesaulniers@google.com> wrote: > > I wonder if PAC or BTI also make this slightly more complex? PAC at > least has implications for unwinders, IIUC. BTI has effect on the jump target\case because a landing pad is required for each and every target. As I see that would not hurt here. The unwinder shall take care of the PAC signed return address if reads the LR from the stack. DWARF contains an entry where the LR is got signed\authenticated. I’m wondering would be simpler or possible to transform the DWARD to ORC. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* [RFC PATCH 13/17] objtool: arm64: Implement functions to add switch tables alternatives 2021-01-20 17:37 ` Julien Thierry @ 2021-01-20 17:37 ` Julien Thierry -1 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: catalin.marinas, will, ardb, masahiroy, keescook, michal.lkml, jpoimboe, peterz, mark.rutland, broonie, linux-efi, linux-hardening, Julien Thierry, Raphael Gault This patch implements the functions required to identify and add as alternatives all the possible destinations of the switch table. This implementation relies on the new plugin introduced previously which records information about the switch-table in a .discard.switch_table_information section. Signed-off-by: Raphael Gault <raphael.gault@arm.com> [J.T.: Update arch implementation to new prototypes, Update switch table information section name, Do some clean up, Use the offset sign information, Use the newly added rela to find the corresponding jump instruction] Signed-off-by: Julien Thierry <jthierry@redhat.com> --- .../objtool/arch/arm64/include/arch/special.h | 2 + tools/objtool/arch/arm64/special.c | 85 +++++++++++++++++++ 2 files changed, 87 insertions(+) diff --git a/tools/objtool/arch/arm64/include/arch/special.h b/tools/objtool/arch/arm64/include/arch/special.h index a82a9b3e51df..b96bcee308cf 100644 --- a/tools/objtool/arch/arm64/include/arch/special.h +++ b/tools/objtool/arch/arm64/include/arch/special.h @@ -3,6 +3,8 @@ #ifndef _ARM64_ARCH_SPECIAL_H #define _ARM64_ARCH_SPECIAL_H +#include <linux/types.h> + #define EX_ENTRY_SIZE 8 #define EX_ORIG_OFFSET 0 #define EX_NEW_OFFSET 4 diff --git a/tools/objtool/arch/arm64/special.c b/tools/objtool/arch/arm64/special.c index 45f283283091..396b9c5feebd 100644 --- a/tools/objtool/arch/arm64/special.c +++ b/tools/objtool/arch/arm64/special.c @@ -1,6 +1,26 @@ // SPDX-License-Identifier: GPL-2.0-or-later +#include <stdlib.h> +#include <string.h> + +#include <asm/aarch64-insn.h> + #include <objtool/special.h> +#include <objtool/warn.h> +#include <arch/special.h> + +/* + * The arm64_switch_table_detection_plugin generate an array of elements + * described by the following structure. + * Each jump table found in the compilation unit is associated with one of + * entries of the array. + */ +struct switch_table_info { + u64 padding; + u64 jump_ref; + u64 nb_entries; + u64 dest_relocations[]; +} __attribute__((__packed__)); void arch_handle_alternative(unsigned short feature, struct special_alt *alt) { @@ -14,8 +34,73 @@ bool arch_support_alt_relocation(struct special_alt *special_alt, } +/* + * Aarch64 jump tables are just arrays of offsets (of varying size/signess) + * representing the potential destination from a base address loaded by an adr + * instruction. + * + * Sadly, extracting the actual offset might require to consider multiple + * instructions and decoding them to understand what they do. To make life + * easier, the gcc plugin will generate a list of relocation entries for + * each jump table target, conforming to the format expected by + * add_jump_table(). + * + * Aarch64 branches to jump tables are composed of multiple instructions: + * + * ldr<?> x_offset, [x_offsets_table, x_index, ...] + * adr x_dest_base, <addr> + * add x_dest, x_target_base, x_offset, ... + * br x_dest + * + * The arm64_switch_table_detection_plugin will make the connection between + * the instruction setting x_offsets_table (jump_ref) and the list of + * relocations. + */ struct reloc *arch_find_switch_table(struct objtool_file *file, struct instruction *insn) { + struct switch_table_info *sti; + struct section *table_info_sec; + void *sti_sec_start; + struct reloc *text_reloc; + + table_info_sec = find_section_by_name(file->elf, + ".discard.switch_table_info"); + if (!table_info_sec) + goto try_c_jmptbl; + + sti_sec_start = table_info_sec->data->d_buf; + sti = sti_sec_start; + + while ((char *)sti - (char *)sti_sec_start < table_info_sec->len) { + struct reloc *target_reloc = find_reloc_by_dest(file->elf, + table_info_sec, + (char *)&sti->jump_ref - (char *)sti_sec_start); + + if (!target_reloc) { + WARN("Malformed switch table entry"); + return NULL; + } + + if (target_reloc->sym->sec == insn->sec && + target_reloc->addend == insn->offset) + return find_reloc_by_dest(file->elf, table_info_sec, + (char *)&sti->dest_relocations[0] - (char *)sti_sec_start); + + /* Get next jump table entry */ + sti = (struct switch_table_info *) (&sti->dest_relocations[0] + sti->nb_entries); + } + +try_c_jmptbl: + text_reloc = find_reloc_by_dest(file->elf, insn->sec, insn->offset); + if (!text_reloc || text_reloc->sym->type != STT_SECTION || + !text_reloc->sym->sec->rodata) + return NULL; + + /* Handle C jump tables */ + if (!strcmp(text_reloc->sym->sec->name, C_JUMP_TABLE_SECTION)) + return find_reloc_by_dest(file->elf, text_reloc->sym->sec, + text_reloc->addend); + return NULL; } -- 2.25.4 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 13/17] objtool: arm64: Implement functions to add switch tables alternatives @ 2021-01-20 17:37 ` Julien Thierry 0 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: mark.rutland, linux-efi, michal.lkml, keescook, peterz, catalin.marinas, masahiroy, Raphael Gault, broonie, linux-hardening, jpoimboe, will, ardb, Julien Thierry This patch implements the functions required to identify and add as alternatives all the possible destinations of the switch table. This implementation relies on the new plugin introduced previously which records information about the switch-table in a .discard.switch_table_information section. Signed-off-by: Raphael Gault <raphael.gault@arm.com> [J.T.: Update arch implementation to new prototypes, Update switch table information section name, Do some clean up, Use the offset sign information, Use the newly added rela to find the corresponding jump instruction] Signed-off-by: Julien Thierry <jthierry@redhat.com> --- .../objtool/arch/arm64/include/arch/special.h | 2 + tools/objtool/arch/arm64/special.c | 85 +++++++++++++++++++ 2 files changed, 87 insertions(+) diff --git a/tools/objtool/arch/arm64/include/arch/special.h b/tools/objtool/arch/arm64/include/arch/special.h index a82a9b3e51df..b96bcee308cf 100644 --- a/tools/objtool/arch/arm64/include/arch/special.h +++ b/tools/objtool/arch/arm64/include/arch/special.h @@ -3,6 +3,8 @@ #ifndef _ARM64_ARCH_SPECIAL_H #define _ARM64_ARCH_SPECIAL_H +#include <linux/types.h> + #define EX_ENTRY_SIZE 8 #define EX_ORIG_OFFSET 0 #define EX_NEW_OFFSET 4 diff --git a/tools/objtool/arch/arm64/special.c b/tools/objtool/arch/arm64/special.c index 45f283283091..396b9c5feebd 100644 --- a/tools/objtool/arch/arm64/special.c +++ b/tools/objtool/arch/arm64/special.c @@ -1,6 +1,26 @@ // SPDX-License-Identifier: GPL-2.0-or-later +#include <stdlib.h> +#include <string.h> + +#include <asm/aarch64-insn.h> + #include <objtool/special.h> +#include <objtool/warn.h> +#include <arch/special.h> + +/* + * The arm64_switch_table_detection_plugin generate an array of elements + * described by the following structure. + * Each jump table found in the compilation unit is associated with one of + * entries of the array. + */ +struct switch_table_info { + u64 padding; + u64 jump_ref; + u64 nb_entries; + u64 dest_relocations[]; +} __attribute__((__packed__)); void arch_handle_alternative(unsigned short feature, struct special_alt *alt) { @@ -14,8 +34,73 @@ bool arch_support_alt_relocation(struct special_alt *special_alt, } +/* + * Aarch64 jump tables are just arrays of offsets (of varying size/signess) + * representing the potential destination from a base address loaded by an adr + * instruction. + * + * Sadly, extracting the actual offset might require to consider multiple + * instructions and decoding them to understand what they do. To make life + * easier, the gcc plugin will generate a list of relocation entries for + * each jump table target, conforming to the format expected by + * add_jump_table(). + * + * Aarch64 branches to jump tables are composed of multiple instructions: + * + * ldr<?> x_offset, [x_offsets_table, x_index, ...] + * adr x_dest_base, <addr> + * add x_dest, x_target_base, x_offset, ... + * br x_dest + * + * The arm64_switch_table_detection_plugin will make the connection between + * the instruction setting x_offsets_table (jump_ref) and the list of + * relocations. + */ struct reloc *arch_find_switch_table(struct objtool_file *file, struct instruction *insn) { + struct switch_table_info *sti; + struct section *table_info_sec; + void *sti_sec_start; + struct reloc *text_reloc; + + table_info_sec = find_section_by_name(file->elf, + ".discard.switch_table_info"); + if (!table_info_sec) + goto try_c_jmptbl; + + sti_sec_start = table_info_sec->data->d_buf; + sti = sti_sec_start; + + while ((char *)sti - (char *)sti_sec_start < table_info_sec->len) { + struct reloc *target_reloc = find_reloc_by_dest(file->elf, + table_info_sec, + (char *)&sti->jump_ref - (char *)sti_sec_start); + + if (!target_reloc) { + WARN("Malformed switch table entry"); + return NULL; + } + + if (target_reloc->sym->sec == insn->sec && + target_reloc->addend == insn->offset) + return find_reloc_by_dest(file->elf, table_info_sec, + (char *)&sti->dest_relocations[0] - (char *)sti_sec_start); + + /* Get next jump table entry */ + sti = (struct switch_table_info *) (&sti->dest_relocations[0] + sti->nb_entries); + } + +try_c_jmptbl: + text_reloc = find_reloc_by_dest(file->elf, insn->sec, insn->offset); + if (!text_reloc || text_reloc->sym->type != STT_SECTION || + !text_reloc->sym->sec->rodata) + return NULL; + + /* Handle C jump tables */ + if (!strcmp(text_reloc->sym->sec->name, C_JUMP_TABLE_SECTION)) + return find_reloc_by_dest(file->elf, text_reloc->sym->sec, + text_reloc->addend); + return NULL; } -- 2.25.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 14/17] objtool: arm64: Cache section with switch table information 2021-01-20 17:37 ` Julien Thierry @ 2021-01-20 17:37 ` Julien Thierry -1 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: catalin.marinas, will, ardb, masahiroy, keescook, michal.lkml, jpoimboe, peterz, mark.rutland, broonie, linux-efi, linux-hardening, Julien Thierry Section ".discard.switch_table_info", created by the gcc plugin will be looked up for every dynamic jump in the object file while the section might not even exist. Cache the result of the first lookup. Signed-off-by: Julien Thierry <jthierry@redhat.com> --- tools/objtool/arch/arm64/special.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/tools/objtool/arch/arm64/special.c b/tools/objtool/arch/arm64/special.c index 396b9c5feebd..c9c3e0bfd581 100644 --- a/tools/objtool/arch/arm64/special.c +++ b/tools/objtool/arch/arm64/special.c @@ -33,6 +33,19 @@ bool arch_support_alt_relocation(struct special_alt *special_alt, return false; } +static struct section *get_switch_table_info_section(struct objtool_file *file) +{ + static bool first = true; + static struct section *info_section = NULL; + + if (first) { + first = false; + info_section = find_section_by_name(file->elf, + ".discard.switch_table_info"); + } + + return info_section; +} /* * Aarch64 jump tables are just arrays of offsets (of varying size/signess) @@ -64,8 +77,7 @@ struct reloc *arch_find_switch_table(struct objtool_file *file, void *sti_sec_start; struct reloc *text_reloc; - table_info_sec = find_section_by_name(file->elf, - ".discard.switch_table_info"); + table_info_sec = get_switch_table_info_section(file); if (!table_info_sec) goto try_c_jmptbl; -- 2.25.4 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 14/17] objtool: arm64: Cache section with switch table information @ 2021-01-20 17:37 ` Julien Thierry 0 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: mark.rutland, linux-efi, michal.lkml, keescook, peterz, catalin.marinas, masahiroy, broonie, linux-hardening, jpoimboe, will, ardb, Julien Thierry Section ".discard.switch_table_info", created by the gcc plugin will be looked up for every dynamic jump in the object file while the section might not even exist. Cache the result of the first lookup. Signed-off-by: Julien Thierry <jthierry@redhat.com> --- tools/objtool/arch/arm64/special.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/tools/objtool/arch/arm64/special.c b/tools/objtool/arch/arm64/special.c index 396b9c5feebd..c9c3e0bfd581 100644 --- a/tools/objtool/arch/arm64/special.c +++ b/tools/objtool/arch/arm64/special.c @@ -33,6 +33,19 @@ bool arch_support_alt_relocation(struct special_alt *special_alt, return false; } +static struct section *get_switch_table_info_section(struct objtool_file *file) +{ + static bool first = true; + static struct section *info_section = NULL; + + if (first) { + first = false; + info_section = find_section_by_name(file->elf, + ".discard.switch_table_info"); + } + + return info_section; +} /* * Aarch64 jump tables are just arrays of offsets (of varying size/signess) @@ -64,8 +77,7 @@ struct reloc *arch_find_switch_table(struct objtool_file *file, void *sti_sec_start; struct reloc *text_reloc; - table_info_sec = find_section_by_name(file->elf, - ".discard.switch_table_info"); + table_info_sec = get_switch_table_info_section(file); if (!table_info_sec) goto try_c_jmptbl; -- 2.25.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 15/17] objtool: arm64: Handle supported relocations in alternatives 2021-01-20 17:37 ` Julien Thierry @ 2021-01-20 17:37 ` Julien Thierry -1 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: catalin.marinas, will, ardb, masahiroy, keescook, michal.lkml, jpoimboe, peterz, mark.rutland, broonie, linux-efi, linux-hardening, Julien Thierry Based on get_alt_insn() in arch/arm64/kernel/alternative.c, arm64 alternative code adapts offsets for static branches and adrp instructions. Signed-off-by: Julien Thierry <jthierry@redhat.com> --- tools/objtool/arch/arm64/special.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/tools/objtool/arch/arm64/special.c b/tools/objtool/arch/arm64/special.c index c9c3e0bfd581..d47e5590ed60 100644 --- a/tools/objtool/arch/arm64/special.c +++ b/tools/objtool/arch/arm64/special.c @@ -30,7 +30,11 @@ bool arch_support_alt_relocation(struct special_alt *special_alt, struct instruction *insn, struct reloc *reloc) { - return false; + u32 opcode = *(u32 *)(insn->sec->data->d_buf + insn->offset); + + return aarch64_insn_is_branch_imm(opcode) || + aarch64_insn_is_adrp(opcode) || + !aarch64_insn_uses_literal(opcode); } static struct section *get_switch_table_info_section(struct objtool_file *file) -- 2.25.4 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 15/17] objtool: arm64: Handle supported relocations in alternatives @ 2021-01-20 17:37 ` Julien Thierry 0 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: mark.rutland, linux-efi, michal.lkml, keescook, peterz, catalin.marinas, masahiroy, broonie, linux-hardening, jpoimboe, will, ardb, Julien Thierry Based on get_alt_insn() in arch/arm64/kernel/alternative.c, arm64 alternative code adapts offsets for static branches and adrp instructions. Signed-off-by: Julien Thierry <jthierry@redhat.com> --- tools/objtool/arch/arm64/special.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/tools/objtool/arch/arm64/special.c b/tools/objtool/arch/arm64/special.c index c9c3e0bfd581..d47e5590ed60 100644 --- a/tools/objtool/arch/arm64/special.c +++ b/tools/objtool/arch/arm64/special.c @@ -30,7 +30,11 @@ bool arch_support_alt_relocation(struct special_alt *special_alt, struct instruction *insn, struct reloc *reloc) { - return false; + u32 opcode = *(u32 *)(insn->sec->data->d_buf + insn->offset); + + return aarch64_insn_is_branch_imm(opcode) || + aarch64_insn_is_adrp(opcode) || + !aarch64_insn_uses_literal(opcode); } static struct section *get_switch_table_info_section(struct objtool_file *file) -- 2.25.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 16/17] objtool: arm64: Ignore replacement section for alternative callback 2021-01-20 17:37 ` Julien Thierry @ 2021-01-20 17:37 ` Julien Thierry -1 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: catalin.marinas, will, ardb, masahiroy, keescook, michal.lkml, jpoimboe, peterz, mark.rutland, broonie, linux-efi, linux-hardening, Julien Thierry ARM64_CB_PATCH doesn't have static replacement instructions. Skip trying to validate the alternative section. Signed-off-by: Julien Thierry <jthierry@redhat.com> --- tools/objtool/arch/arm64/special.c | 12 ++++++++++++ tools/objtool/check.c | 3 +++ 2 files changed, 15 insertions(+) diff --git a/tools/objtool/arch/arm64/special.c b/tools/objtool/arch/arm64/special.c index d47e5590ed60..aff8577e71e9 100644 --- a/tools/objtool/arch/arm64/special.c +++ b/tools/objtool/arch/arm64/special.c @@ -24,6 +24,18 @@ struct switch_table_info { void arch_handle_alternative(unsigned short feature, struct special_alt *alt) { + if (alt->orig_len && !alt->new_len) { + /* + * ARM64_CB_PATCH has no alternative instruction. + * a callback is called at alternative replacement time + * to dynamically change the original instructions. + * + * ARM64_CB_PATCH is the last ARM64 feature, it's value changes + * every time a new feature is added. So the orig/alt region + * length are used to detect those alternatives + */ + alt->skip_alt = true; + } } bool arch_support_alt_relocation(struct special_alt *special_alt, diff --git a/tools/objtool/check.c b/tools/objtool/check.c index d902697a388e..8840af09f843 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -1182,6 +1182,9 @@ static int add_special_section_alts(struct objtool_file *file) continue; } + if (special_alt->skip_alt && !special_alt->new_len) + continue; + ret = handle_group_alt(file, special_alt, orig_insn, &new_insn); if (ret) -- 2.25.4 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 16/17] objtool: arm64: Ignore replacement section for alternative callback @ 2021-01-20 17:37 ` Julien Thierry 0 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:37 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: mark.rutland, linux-efi, michal.lkml, keescook, peterz, catalin.marinas, masahiroy, broonie, linux-hardening, jpoimboe, will, ardb, Julien Thierry ARM64_CB_PATCH doesn't have static replacement instructions. Skip trying to validate the alternative section. Signed-off-by: Julien Thierry <jthierry@redhat.com> --- tools/objtool/arch/arm64/special.c | 12 ++++++++++++ tools/objtool/check.c | 3 +++ 2 files changed, 15 insertions(+) diff --git a/tools/objtool/arch/arm64/special.c b/tools/objtool/arch/arm64/special.c index d47e5590ed60..aff8577e71e9 100644 --- a/tools/objtool/arch/arm64/special.c +++ b/tools/objtool/arch/arm64/special.c @@ -24,6 +24,18 @@ struct switch_table_info { void arch_handle_alternative(unsigned short feature, struct special_alt *alt) { + if (alt->orig_len && !alt->new_len) { + /* + * ARM64_CB_PATCH has no alternative instruction. + * a callback is called at alternative replacement time + * to dynamically change the original instructions. + * + * ARM64_CB_PATCH is the last ARM64 feature, it's value changes + * every time a new feature is added. So the orig/alt region + * length are used to detect those alternatives + */ + alt->skip_alt = true; + } } bool arch_support_alt_relocation(struct special_alt *special_alt, diff --git a/tools/objtool/check.c b/tools/objtool/check.c index d902697a388e..8840af09f843 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -1182,6 +1182,9 @@ static int add_special_section_alts(struct objtool_file *file) continue; } + if (special_alt->skip_alt && !special_alt->new_len) + continue; + ret = handle_group_alt(file, special_alt, orig_insn, &new_insn); if (ret) -- 2.25.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 17/17] objtool: arm64: Enable stack validation for arm64 2021-01-20 17:37 ` Julien Thierry @ 2021-01-20 17:38 ` Julien Thierry -1 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:38 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: catalin.marinas, will, ardb, masahiroy, keescook, michal.lkml, jpoimboe, peterz, mark.rutland, broonie, linux-efi, linux-hardening, Raphael Gault, Julien Thierry From: Raphael Gault <raphael.gault@arm.com> Add build option to run stack validation at compile time. Signed-off-by: Raphael Gault <raphael.gault@arm.com> Signed-off-by: Julien Thierry <jthierry@redhat.com> --- arch/arm64/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 93a320cc8e03..3f297d61b56b 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -185,6 +185,7 @@ config ARM64 select MMU_GATHER_RCU_TABLE_FREE select HAVE_RSEQ select HAVE_STACKPROTECTOR + select HAVE_STACK_VALIDATION if CC_IS_GCC select HAVE_SYSCALL_TRACEPOINTS select HAVE_KPROBES select HAVE_KRETPROBES -- 2.25.4 ^ permalink raw reply related [flat|nested] 106+ messages in thread
* [RFC PATCH 17/17] objtool: arm64: Enable stack validation for arm64 @ 2021-01-20 17:38 ` Julien Thierry 0 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-20 17:38 UTC (permalink / raw) To: linux-kernel, linux-arm-kernel Cc: mark.rutland, linux-efi, michal.lkml, keescook, peterz, catalin.marinas, masahiroy, Raphael Gault, broonie, linux-hardening, jpoimboe, will, ardb, Julien Thierry From: Raphael Gault <raphael.gault@arm.com> Add build option to run stack validation at compile time. Signed-off-by: Raphael Gault <raphael.gault@arm.com> Signed-off-by: Julien Thierry <jthierry@redhat.com> --- arch/arm64/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 93a320cc8e03..3f297d61b56b 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -185,6 +185,7 @@ config ARM64 select MMU_GATHER_RCU_TABLE_FREE select HAVE_RSEQ select HAVE_STACKPROTECTOR + select HAVE_STACK_VALIDATION if CC_IS_GCC select HAVE_SYSCALL_TRACEPOINTS select HAVE_KPROBES select HAVE_KRETPROBES -- 2.25.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 17/17] objtool: arm64: Enable stack validation for arm64 2021-01-20 17:38 ` Julien Thierry (?) @ 2021-01-21 5:39 ` kernel test robot -1 siblings, 0 replies; 106+ messages in thread From: kernel test robot @ 2021-01-21 5:39 UTC (permalink / raw) To: kbuild-all [-- Attachment #1: Type: text/plain, Size: 2931 bytes --] Hi Julien, [FYI, it's a private test report for your RFC patch.] [auto build test WARNING on next-20210120] [cannot apply to arm64/for-next/core linux/master efi/next kbuild/for-next soc/for-next arm/for-next xlnx/master kvmarm/next linus/master v5.11-rc4 v5.11-rc3 v5.11-rc2 v5.11-rc4] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Julien-Thierry/objtool-add-base-support-for-arm64/20210121-031836 base: 647060f3b592d3c8df0c85dd887557b03e6ea897 config: arm64-allyesconfig (attached as .config) compiler: aarch64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/04b2388dbd79126e4cdd6d9c2ffd6313d7f2ef62 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Julien-Thierry/objtool-add-base-support-for-arm64/20210121-031836 git checkout 04b2388dbd79126e4cdd6d9c2ffd6313d7f2ef62 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp@intel.com> All warnings (new ones prefixed by >>): >> arch/arm64/kernel/relocate_kernel.o: warning: objtool: .text+0x1000: can't decode instruction -- >> arch/arm64/kernel/head.o: warning: objtool: .head.text+0x54: can't decode instruction -- >> arch/arm64/kernel/entry.o: warning: objtool: .entry.text+0x8e0: can't find call dest symbol at .text+0x14 -- >> arch/arm64/kernel/sigreturn32.o: warning: objtool: .text+0x0: can't decode instruction -- >> arch/arm64/kernel/kuser32.o: warning: objtool: .text+0x8: can't decode instruction -- >> arch/arm64/kernel/proton-pack.o: warning: objtool: qcom_link_stack_sanitisation()+0x1c: unannotated intra-function call -- >> arch/arm64/kernel/sleep.o: warning: objtool: __cpu_suspend_enter()+0x80: call without frame pointer save/setup >> arch/arm64/kernel/sleep.o: warning: objtool: _cpu_resume()+0x64: call without frame pointer save/setup -- >> arch/arm64/mm/proc.o: warning: objtool: .idmap.text+0xd8: can't decode instruction -- >> arch/arm64/crypto/crct10dif-ce-core.o: warning: objtool: crc_t10dif_pmull_p8()+0xf0: unannotated intra-function call -- >> arch/arm64/crypto/sha256-core.o: warning: objtool: .text+0xeec: can't decode instruction -- >> arch/arm64/crypto/sha512-core.o: warning: objtool: .text+0x1048: can't decode instruction .. --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org [-- Attachment #2: config.gz --] [-- Type: application/gzip, Size: 76742 bytes --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 2021-01-20 17:37 ` Julien Thierry @ 2021-01-21 9:03 ` Ard Biesheuvel -1 siblings, 0 replies; 106+ messages in thread From: Ard Biesheuvel @ 2021-01-21 9:03 UTC (permalink / raw) To: Julien Thierry Cc: Linux Kernel Mailing List, Linux ARM, Catalin Marinas, Will Deacon, Masahiro Yamada, Kees Cook, Michal Marek, Josh Poimboeuf, Peter Zijlstra, Mark Rutland, Mark Brown, linux-efi, linux-hardening Hello Julien, On Wed, 20 Jan 2021 at 18:38, Julien Thierry <jthierry@redhat.com> wrote: > > Hi, > > This series enables objtool to start doing stack validation on arm64 > kernel builds. Could we elaborate on this point, please? 'Stack validation' means getting an accurate picture of all kernel code that will be executed at some point in the future, due to the fact that there are stack frames pointing to them. And this ability is essential in order to do live patching safely? If this is the goal, I wonder whether this is the right approach for arm64 (or for any other architecture, for that matter) Parsing/decoding the object code and even worse, relying on GCC plugins to annotate some of the idioms as they are being generated, in order to infer intent on the part of the compiler goes *way* beyond what we should be comfortable with. The whole point of this exercise is to guarantee that there are no false positives when it comes to deciding whether the kernel is in a live patchable state, and I don't see how we can ever provide such a guarantee when it is built on such a fragile foundation. If we want to ensure that the stack contents are always an accurate reflection of the real call stack, we should work with the toolchain folks to identify issues that may interfere with this, and implement controls over these behaviors that we can decide to use in the build. In the past, I have already proposed adding a 'kernel' code model to the AArch64 compiler that guarantees certain things, such as adrp/add for symbol references, and no GOT indirections for position independent code. Inhibiting optimizations that may impact our ability to infer the real call stack from the stack contents is something we might add here as well. Another thing that occurred to me is that inferring which kernel code is actually live in terms of pending function returns could be inferred much more easily from a shadow call stack, which is a thing we already implement for Clang builds. In summary, I would not be in favor of enabling objtool on arm64 at all until we have exhausted other options for providing the functionality that we need it for (given that objtool provides many other things that only x86 cares about, IIUC) -- Ard. > It relies on the previous series I sent, refactoring > the arm64 decoder [1]. > > First, the aarch64 instruction decoder needed to be made available > to code under tools/. This is done in a similar manner to x86 > instruction decoded. One limitation I encountered there is that most > of aarch64 instruction decoder is __kprobe annotated. To bypass that > it remove the kprobe include and had to add an empty __kprobe > definition, but I'd welcome a proper solution to that. > > Then instruction semantics are progressively added so objtool can track > the stack state through the execution flow. > There are a few things that needed consideration: > - Generation of constants within executable sections, these either > caused objtool to fail decoding or to wrongly decode constants > as jumps or other instructions affecting execution flow and > causing confusion. To solve this, tracking locations referenced > by instructions using literals was needed. > - Jump tables from switch statements in aarch64 don't have enough > information to link branches with the branch instruction leading to > them. For this, we use a gcc plugin to add some information to establish > those missing links in a format that is already supported by objtool > > With this, there are still some errors when building with objtool. A > number of cleanups/annotations are needed on the arm64, as well as > handling SYM_DATA objects in objtool. > > Those changes can be found on top of this branch here: > git clone https://github.com/julien-thierry/linux.git -b objtoolxarm64-latest > > But it would be nice to have some feedback on this before I start submitting everyting. > > [1] https://lkml.org/lkml/2021/1/20/791 > > Thanks, > > Julien > > --> > > Julien Thierry (15): > tools: Add some generic functions and headers > tools: arm64: Make aarch64 instruction decoder available to tools > tools: bug: Remove duplicate definition > objtool: arm64: Add base definition for arm64 backend > objtool: arm64: Decode add/sub instructions > objtool: arm64: Decode jump and call related instructions > objtool: arm64: Decode other system instructions > objtool: arm64: Decode load/store instructions > objtool: arm64: Decode LDR instructions > objtool: arm64: Accept padding in code sections > efi: libstub: Ignore relocations for .discard sections > objtool: arm64: Implement functions to add switch tables alternatives > objtool: arm64: Cache section with switch table information > objtool: arm64: Handle supported relocations in alternatives > objtool: arm64: Ignore replacement section for alternative callback > > Raphael Gault (2): > gcc-plugins: objtool: Add plugin to detect switch table on arm64 > objtool: arm64: Enable stack validation for arm64 > > arch/arm64/Kconfig | 2 + > drivers/firmware/efi/libstub/Makefile | 2 +- > scripts/Makefile.gcc-plugins | 2 + > scripts/gcc-plugins/Kconfig | 4 + > .../arm64_switch_table_detection_plugin.c | 85 + > tools/arch/arm64/include/asm/aarch64-insn.h | 551 +++++++ > tools/arch/arm64/lib/aarch64-insn.c | 1425 +++++++++++++++++ > tools/include/asm-generic/bitops/__ffs.h | 11 + > tools/include/linux/bug.h | 6 +- > tools/include/linux/kernel.h | 21 + > tools/include/linux/printk.h | 40 + > tools/objtool/Makefile | 5 + > tools/objtool/arch/arm64/Build | 8 + > tools/objtool/arch/arm64/decode.c | 471 ++++++ > .../arch/arm64/include/arch/cfi_regs.h | 14 + > tools/objtool/arch/arm64/include/arch/elf.h | 6 + > .../arch/arm64/include/arch/endianness.h | 9 + > .../objtool/arch/arm64/include/arch/special.h | 23 + > tools/objtool/arch/arm64/special.c | 134 ++ > tools/objtool/arch/x86/decode.c | 5 + > tools/objtool/check.c | 6 + > tools/objtool/include/objtool/arch.h | 3 + > tools/objtool/sync-check.sh | 5 + > 23 files changed, 2832 insertions(+), 6 deletions(-) > create mode 100644 scripts/gcc-plugins/arm64_switch_table_detection_plugin.c > create mode 100644 tools/arch/arm64/include/asm/aarch64-insn.h > create mode 100644 tools/arch/arm64/lib/aarch64-insn.c > create mode 100644 tools/include/linux/printk.h > create mode 100644 tools/objtool/arch/arm64/Build > create mode 100644 tools/objtool/arch/arm64/decode.c > create mode 100644 tools/objtool/arch/arm64/include/arch/cfi_regs.h > create mode 100644 tools/objtool/arch/arm64/include/arch/elf.h > create mode 100644 tools/objtool/arch/arm64/include/arch/endianness.h > create mode 100644 tools/objtool/arch/arm64/include/arch/special.h > create mode 100644 tools/objtool/arch/arm64/special.c > > -- > 2.25.4 > ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 @ 2021-01-21 9:03 ` Ard Biesheuvel 0 siblings, 0 replies; 106+ messages in thread From: Ard Biesheuvel @ 2021-01-21 9:03 UTC (permalink / raw) To: Julien Thierry Cc: Mark Rutland, linux-efi, Michal Marek, Kees Cook, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, Linux Kernel Mailing List, Mark Brown, linux-hardening, Josh Poimboeuf, Will Deacon, Linux ARM Hello Julien, On Wed, 20 Jan 2021 at 18:38, Julien Thierry <jthierry@redhat.com> wrote: > > Hi, > > This series enables objtool to start doing stack validation on arm64 > kernel builds. Could we elaborate on this point, please? 'Stack validation' means getting an accurate picture of all kernel code that will be executed at some point in the future, due to the fact that there are stack frames pointing to them. And this ability is essential in order to do live patching safely? If this is the goal, I wonder whether this is the right approach for arm64 (or for any other architecture, for that matter) Parsing/decoding the object code and even worse, relying on GCC plugins to annotate some of the idioms as they are being generated, in order to infer intent on the part of the compiler goes *way* beyond what we should be comfortable with. The whole point of this exercise is to guarantee that there are no false positives when it comes to deciding whether the kernel is in a live patchable state, and I don't see how we can ever provide such a guarantee when it is built on such a fragile foundation. If we want to ensure that the stack contents are always an accurate reflection of the real call stack, we should work with the toolchain folks to identify issues that may interfere with this, and implement controls over these behaviors that we can decide to use in the build. In the past, I have already proposed adding a 'kernel' code model to the AArch64 compiler that guarantees certain things, such as adrp/add for symbol references, and no GOT indirections for position independent code. Inhibiting optimizations that may impact our ability to infer the real call stack from the stack contents is something we might add here as well. Another thing that occurred to me is that inferring which kernel code is actually live in terms of pending function returns could be inferred much more easily from a shadow call stack, which is a thing we already implement for Clang builds. In summary, I would not be in favor of enabling objtool on arm64 at all until we have exhausted other options for providing the functionality that we need it for (given that objtool provides many other things that only x86 cares about, IIUC) -- Ard. > It relies on the previous series I sent, refactoring > the arm64 decoder [1]. > > First, the aarch64 instruction decoder needed to be made available > to code under tools/. This is done in a similar manner to x86 > instruction decoded. One limitation I encountered there is that most > of aarch64 instruction decoder is __kprobe annotated. To bypass that > it remove the kprobe include and had to add an empty __kprobe > definition, but I'd welcome a proper solution to that. > > Then instruction semantics are progressively added so objtool can track > the stack state through the execution flow. > There are a few things that needed consideration: > - Generation of constants within executable sections, these either > caused objtool to fail decoding or to wrongly decode constants > as jumps or other instructions affecting execution flow and > causing confusion. To solve this, tracking locations referenced > by instructions using literals was needed. > - Jump tables from switch statements in aarch64 don't have enough > information to link branches with the branch instruction leading to > them. For this, we use a gcc plugin to add some information to establish > those missing links in a format that is already supported by objtool > > With this, there are still some errors when building with objtool. A > number of cleanups/annotations are needed on the arm64, as well as > handling SYM_DATA objects in objtool. > > Those changes can be found on top of this branch here: > git clone https://github.com/julien-thierry/linux.git -b objtoolxarm64-latest > > But it would be nice to have some feedback on this before I start submitting everyting. > > [1] https://lkml.org/lkml/2021/1/20/791 > > Thanks, > > Julien > > --> > > Julien Thierry (15): > tools: Add some generic functions and headers > tools: arm64: Make aarch64 instruction decoder available to tools > tools: bug: Remove duplicate definition > objtool: arm64: Add base definition for arm64 backend > objtool: arm64: Decode add/sub instructions > objtool: arm64: Decode jump and call related instructions > objtool: arm64: Decode other system instructions > objtool: arm64: Decode load/store instructions > objtool: arm64: Decode LDR instructions > objtool: arm64: Accept padding in code sections > efi: libstub: Ignore relocations for .discard sections > objtool: arm64: Implement functions to add switch tables alternatives > objtool: arm64: Cache section with switch table information > objtool: arm64: Handle supported relocations in alternatives > objtool: arm64: Ignore replacement section for alternative callback > > Raphael Gault (2): > gcc-plugins: objtool: Add plugin to detect switch table on arm64 > objtool: arm64: Enable stack validation for arm64 > > arch/arm64/Kconfig | 2 + > drivers/firmware/efi/libstub/Makefile | 2 +- > scripts/Makefile.gcc-plugins | 2 + > scripts/gcc-plugins/Kconfig | 4 + > .../arm64_switch_table_detection_plugin.c | 85 + > tools/arch/arm64/include/asm/aarch64-insn.h | 551 +++++++ > tools/arch/arm64/lib/aarch64-insn.c | 1425 +++++++++++++++++ > tools/include/asm-generic/bitops/__ffs.h | 11 + > tools/include/linux/bug.h | 6 +- > tools/include/linux/kernel.h | 21 + > tools/include/linux/printk.h | 40 + > tools/objtool/Makefile | 5 + > tools/objtool/arch/arm64/Build | 8 + > tools/objtool/arch/arm64/decode.c | 471 ++++++ > .../arch/arm64/include/arch/cfi_regs.h | 14 + > tools/objtool/arch/arm64/include/arch/elf.h | 6 + > .../arch/arm64/include/arch/endianness.h | 9 + > .../objtool/arch/arm64/include/arch/special.h | 23 + > tools/objtool/arch/arm64/special.c | 134 ++ > tools/objtool/arch/x86/decode.c | 5 + > tools/objtool/check.c | 6 + > tools/objtool/include/objtool/arch.h | 3 + > tools/objtool/sync-check.sh | 5 + > 23 files changed, 2832 insertions(+), 6 deletions(-) > create mode 100644 scripts/gcc-plugins/arm64_switch_table_detection_plugin.c > create mode 100644 tools/arch/arm64/include/asm/aarch64-insn.h > create mode 100644 tools/arch/arm64/lib/aarch64-insn.c > create mode 100644 tools/include/linux/printk.h > create mode 100644 tools/objtool/arch/arm64/Build > create mode 100644 tools/objtool/arch/arm64/decode.c > create mode 100644 tools/objtool/arch/arm64/include/arch/cfi_regs.h > create mode 100644 tools/objtool/arch/arm64/include/arch/elf.h > create mode 100644 tools/objtool/arch/arm64/include/arch/endianness.h > create mode 100644 tools/objtool/arch/arm64/include/arch/special.h > create mode 100644 tools/objtool/arch/arm64/special.c > > -- > 2.25.4 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 2021-01-21 9:03 ` Ard Biesheuvel @ 2021-01-21 10:26 ` Julien Thierry -1 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-21 10:26 UTC (permalink / raw) To: Ard Biesheuvel Cc: Linux Kernel Mailing List, Linux ARM, Catalin Marinas, Will Deacon, Masahiro Yamada, Kees Cook, Michal Marek, Josh Poimboeuf, Peter Zijlstra, Mark Rutland, Mark Brown, linux-efi, linux-hardening Hi Ard, On 1/21/21 10:03 AM, Ard Biesheuvel wrote: > Hello Julien, > > On Wed, 20 Jan 2021 at 18:38, Julien Thierry <jthierry@redhat.com> wrote: >> >> Hi, >> >> This series enables objtool to start doing stack validation on arm64 >> kernel builds. > > Could we elaborate on this point, please? 'Stack validation' means > getting an accurate picture of all kernel code that will be executed > at some point in the future, due to the fact that there are stack > frames pointing to them. And this ability is essential in order to do > live patching safely? > > If this is the goal, I wonder whether this is the right approach for > arm64 (or for any other architecture, for that matter) > > Parsing/decoding the object code and even worse, relying on GCC > plugins to annotate some of the idioms as they are being generated, in > order to infer intent on the part of the compiler goes *way* beyond > what we should be comfortable with. The whole point of this exercise > is to guarantee that there are no false positives when it comes to > deciding whether the kernel is in a live patchable state, and I don't > see how we can ever provide such a guarantee when it is built on such > a fragile foundation. > > If we want to ensure that the stack contents are always an accurate > reflection of the real call stack, we should work with the toolchain > folks to identify issues that may interfere with this, and implement > controls over these behaviors that we can decide to use in the build. > In the past, I have already proposed adding a 'kernel' code model to > the AArch64 compiler that guarantees certain things, such as adrp/add > for symbol references, and no GOT indirections for position > independent code. Inhibiting optimizations that may impact our ability > to infer the real call stack from the stack contents is something we > might add here as well. > I'm not familiar with toolcahin code models, but would this approach be able to validate assembly code (either inline or in assembly files?) > Another thing that occurred to me is that inferring which kernel code > is actually live in terms of pending function returns could be > inferred much more easily from a shadow call stack, which is a thing > we already implement for Clang builds. > I was not familiar with the shadow call stack. If I understand correctly that would be a stack of return addresses of function currently on the call stack, is that correct? That would indeed be a simpler approach, however I guess the instrumentation has a cost. Is the instrumentation also available with GCC? And is this instrumentation efficient enough to be suitable for production builds? If we can rely on shadow call stack to implement the reliable unwinder, I guess this could be the way to go. > In summary, I would not be in favor of enabling objtool on arm64 at > all until we have exhausted other options for providing the > functionality that we need it for (given that objtool provides many > other things that only x86 cares about, IIUC) > I understand the concern and appreciate the suggestion. I guess this does need some thorough discussions for the right approach. Thanks, -- Julien Thierry ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 @ 2021-01-21 10:26 ` Julien Thierry 0 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-21 10:26 UTC (permalink / raw) To: Ard Biesheuvel Cc: Mark Rutland, linux-efi, Michal Marek, Kees Cook, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, Linux Kernel Mailing List, Mark Brown, linux-hardening, Josh Poimboeuf, Will Deacon, Linux ARM Hi Ard, On 1/21/21 10:03 AM, Ard Biesheuvel wrote: > Hello Julien, > > On Wed, 20 Jan 2021 at 18:38, Julien Thierry <jthierry@redhat.com> wrote: >> >> Hi, >> >> This series enables objtool to start doing stack validation on arm64 >> kernel builds. > > Could we elaborate on this point, please? 'Stack validation' means > getting an accurate picture of all kernel code that will be executed > at some point in the future, due to the fact that there are stack > frames pointing to them. And this ability is essential in order to do > live patching safely? > > If this is the goal, I wonder whether this is the right approach for > arm64 (or for any other architecture, for that matter) > > Parsing/decoding the object code and even worse, relying on GCC > plugins to annotate some of the idioms as they are being generated, in > order to infer intent on the part of the compiler goes *way* beyond > what we should be comfortable with. The whole point of this exercise > is to guarantee that there are no false positives when it comes to > deciding whether the kernel is in a live patchable state, and I don't > see how we can ever provide such a guarantee when it is built on such > a fragile foundation. > > If we want to ensure that the stack contents are always an accurate > reflection of the real call stack, we should work with the toolchain > folks to identify issues that may interfere with this, and implement > controls over these behaviors that we can decide to use in the build. > In the past, I have already proposed adding a 'kernel' code model to > the AArch64 compiler that guarantees certain things, such as adrp/add > for symbol references, and no GOT indirections for position > independent code. Inhibiting optimizations that may impact our ability > to infer the real call stack from the stack contents is something we > might add here as well. > I'm not familiar with toolcahin code models, but would this approach be able to validate assembly code (either inline or in assembly files?) > Another thing that occurred to me is that inferring which kernel code > is actually live in terms of pending function returns could be > inferred much more easily from a shadow call stack, which is a thing > we already implement for Clang builds. > I was not familiar with the shadow call stack. If I understand correctly that would be a stack of return addresses of function currently on the call stack, is that correct? That would indeed be a simpler approach, however I guess the instrumentation has a cost. Is the instrumentation also available with GCC? And is this instrumentation efficient enough to be suitable for production builds? If we can rely on shadow call stack to implement the reliable unwinder, I guess this could be the way to go. > In summary, I would not be in favor of enabling objtool on arm64 at > all until we have exhausted other options for providing the > functionality that we need it for (given that objtool provides many > other things that only x86 cares about, IIUC) > I understand the concern and appreciate the suggestion. I guess this does need some thorough discussions for the right approach. Thanks, -- Julien Thierry _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 2021-01-21 10:26 ` Julien Thierry @ 2021-01-21 11:08 ` Ard Biesheuvel -1 siblings, 0 replies; 106+ messages in thread From: Ard Biesheuvel @ 2021-01-21 11:08 UTC (permalink / raw) To: Julien Thierry Cc: Linux Kernel Mailing List, Linux ARM, Catalin Marinas, Will Deacon, Masahiro Yamada, Kees Cook, Michal Marek, Josh Poimboeuf, Peter Zijlstra, Mark Rutland, Mark Brown, linux-efi, linux-hardening On Thu, 21 Jan 2021 at 11:26, Julien Thierry <jthierry@redhat.com> wrote: > > Hi Ard, > > On 1/21/21 10:03 AM, Ard Biesheuvel wrote: > > Hello Julien, > > > > On Wed, 20 Jan 2021 at 18:38, Julien Thierry <jthierry@redhat.com> wrote: > >> > >> Hi, > >> > >> This series enables objtool to start doing stack validation on arm64 > >> kernel builds. > > > > Could we elaborate on this point, please? 'Stack validation' means > > getting an accurate picture of all kernel code that will be executed > > at some point in the future, due to the fact that there are stack > > frames pointing to them. And this ability is essential in order to do > > live patching safely? > > > > If this is the goal, I wonder whether this is the right approach for > > arm64 (or for any other architecture, for that matter) > > > > Parsing/decoding the object code and even worse, relying on GCC > > plugins to annotate some of the idioms as they are being generated, in > > order to infer intent on the part of the compiler goes *way* beyond > > what we should be comfortable with. The whole point of this exercise > > is to guarantee that there are no false positives when it comes to > > deciding whether the kernel is in a live patchable state, and I don't > > see how we can ever provide such a guarantee when it is built on such > > a fragile foundation. > > > > If we want to ensure that the stack contents are always an accurate > > reflection of the real call stack, we should work with the toolchain > > folks to identify issues that may interfere with this, and implement > > controls over these behaviors that we can decide to use in the build. > > In the past, I have already proposed adding a 'kernel' code model to > > the AArch64 compiler that guarantees certain things, such as adrp/add > > for symbol references, and no GOT indirections for position > > independent code. Inhibiting optimizations that may impact our ability > > to infer the real call stack from the stack contents is something we > > might add here as well. > > > > I'm not familiar with toolcahin code models, but would this approach be > able to validate assembly code (either inline or in assembly files?) > No, it would not. But those files are part of the code base, and can be reviewed and audited. > > Another thing that occurred to me is that inferring which kernel code > > is actually live in terms of pending function returns could be > > inferred much more easily from a shadow call stack, which is a thing > > we already implement for Clang builds. > > > > I was not familiar with the shadow call stack. If I understand correctly > that would be a stack of return addresses of function currently on the > call stack, is that correct? > > That would indeed be a simpler approach, however I guess the > instrumentation has a cost. Is the instrumentation also available with > GCC? And is this instrumentation efficient enough to be suitable for > production builds? > I am not aware of any plans to enable this in GCC, but the Clang implementation is definitely intended for production use (it's a CFI feature for ROP/JOP mitigation) > If we can rely on shadow call stack to implement the reliable unwinder, > I guess this could be the way to go. > > > In summary, I would not be in favor of enabling objtool on arm64 at > > all until we have exhausted other options for providing the > > functionality that we need it for (given that objtool provides many > > other things that only x86 cares about, IIUC) > > > I understand the concern and appreciate the suggestion. I guess this > does need some thorough discussions for the right approach. > Agreed. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 @ 2021-01-21 11:08 ` Ard Biesheuvel 0 siblings, 0 replies; 106+ messages in thread From: Ard Biesheuvel @ 2021-01-21 11:08 UTC (permalink / raw) To: Julien Thierry Cc: Mark Rutland, linux-efi, Michal Marek, Kees Cook, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, Linux Kernel Mailing List, Mark Brown, linux-hardening, Josh Poimboeuf, Will Deacon, Linux ARM On Thu, 21 Jan 2021 at 11:26, Julien Thierry <jthierry@redhat.com> wrote: > > Hi Ard, > > On 1/21/21 10:03 AM, Ard Biesheuvel wrote: > > Hello Julien, > > > > On Wed, 20 Jan 2021 at 18:38, Julien Thierry <jthierry@redhat.com> wrote: > >> > >> Hi, > >> > >> This series enables objtool to start doing stack validation on arm64 > >> kernel builds. > > > > Could we elaborate on this point, please? 'Stack validation' means > > getting an accurate picture of all kernel code that will be executed > > at some point in the future, due to the fact that there are stack > > frames pointing to them. And this ability is essential in order to do > > live patching safely? > > > > If this is the goal, I wonder whether this is the right approach for > > arm64 (or for any other architecture, for that matter) > > > > Parsing/decoding the object code and even worse, relying on GCC > > plugins to annotate some of the idioms as they are being generated, in > > order to infer intent on the part of the compiler goes *way* beyond > > what we should be comfortable with. The whole point of this exercise > > is to guarantee that there are no false positives when it comes to > > deciding whether the kernel is in a live patchable state, and I don't > > see how we can ever provide such a guarantee when it is built on such > > a fragile foundation. > > > > If we want to ensure that the stack contents are always an accurate > > reflection of the real call stack, we should work with the toolchain > > folks to identify issues that may interfere with this, and implement > > controls over these behaviors that we can decide to use in the build. > > In the past, I have already proposed adding a 'kernel' code model to > > the AArch64 compiler that guarantees certain things, such as adrp/add > > for symbol references, and no GOT indirections for position > > independent code. Inhibiting optimizations that may impact our ability > > to infer the real call stack from the stack contents is something we > > might add here as well. > > > > I'm not familiar with toolcahin code models, but would this approach be > able to validate assembly code (either inline or in assembly files?) > No, it would not. But those files are part of the code base, and can be reviewed and audited. > > Another thing that occurred to me is that inferring which kernel code > > is actually live in terms of pending function returns could be > > inferred much more easily from a shadow call stack, which is a thing > > we already implement for Clang builds. > > > > I was not familiar with the shadow call stack. If I understand correctly > that would be a stack of return addresses of function currently on the > call stack, is that correct? > > That would indeed be a simpler approach, however I guess the > instrumentation has a cost. Is the instrumentation also available with > GCC? And is this instrumentation efficient enough to be suitable for > production builds? > I am not aware of any plans to enable this in GCC, but the Clang implementation is definitely intended for production use (it's a CFI feature for ROP/JOP mitigation) > If we can rely on shadow call stack to implement the reliable unwinder, > I guess this could be the way to go. > > > In summary, I would not be in favor of enabling objtool on arm64 at > > all until we have exhausted other options for providing the > > functionality that we need it for (given that objtool provides many > > other things that only x86 cares about, IIUC) > > > I understand the concern and appreciate the suggestion. I guess this > does need some thorough discussions for the right approach. > Agreed. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 2021-01-21 11:08 ` Ard Biesheuvel @ 2021-01-21 11:23 ` Peter Zijlstra -1 siblings, 0 replies; 106+ messages in thread From: Peter Zijlstra @ 2021-01-21 11:23 UTC (permalink / raw) To: Ard Biesheuvel Cc: Julien Thierry, Linux Kernel Mailing List, Linux ARM, Catalin Marinas, Will Deacon, Masahiro Yamada, Kees Cook, Michal Marek, Josh Poimboeuf, Mark Rutland, Mark Brown, linux-efi, linux-hardening On Thu, Jan 21, 2021 at 12:08:23PM +0100, Ard Biesheuvel wrote: > On Thu, 21 Jan 2021 at 11:26, Julien Thierry <jthierry@redhat.com> wrote: > > I'm not familiar with toolcahin code models, but would this approach be > > able to validate assembly code (either inline or in assembly files?) > > > > No, it would not. But those files are part of the code base, and can > be reviewed and audited. x86 has a long history if failing at exactly that. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 @ 2021-01-21 11:23 ` Peter Zijlstra 0 siblings, 0 replies; 106+ messages in thread From: Peter Zijlstra @ 2021-01-21 11:23 UTC (permalink / raw) To: Ard Biesheuvel Cc: Mark Rutland, Michal Marek, Julien Thierry, linux-efi, Catalin Marinas, Masahiro Yamada, Linux Kernel Mailing List, Mark Brown, linux-hardening, Josh Poimboeuf, Will Deacon, Linux ARM, Kees Cook On Thu, Jan 21, 2021 at 12:08:23PM +0100, Ard Biesheuvel wrote: > On Thu, 21 Jan 2021 at 11:26, Julien Thierry <jthierry@redhat.com> wrote: > > I'm not familiar with toolcahin code models, but would this approach be > > able to validate assembly code (either inline or in assembly files?) > > > > No, it would not. But those files are part of the code base, and can > be reviewed and audited. x86 has a long history if failing at exactly that. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 2021-01-21 11:23 ` Peter Zijlstra @ 2021-01-21 11:48 ` Ard Biesheuvel -1 siblings, 0 replies; 106+ messages in thread From: Ard Biesheuvel @ 2021-01-21 11:48 UTC (permalink / raw) To: Peter Zijlstra Cc: Julien Thierry, Linux Kernel Mailing List, Linux ARM, Catalin Marinas, Will Deacon, Masahiro Yamada, Kees Cook, Michal Marek, Josh Poimboeuf, Mark Rutland, Mark Brown, linux-efi, linux-hardening On Thu, 21 Jan 2021 at 12:23, Peter Zijlstra <peterz@infradead.org> wrote: > > On Thu, Jan 21, 2021 at 12:08:23PM +0100, Ard Biesheuvel wrote: > > On Thu, 21 Jan 2021 at 11:26, Julien Thierry <jthierry@redhat.com> wrote: > > > > I'm not familiar with toolcahin code models, but would this approach be > > > able to validate assembly code (either inline or in assembly files?) > > > > > > > No, it would not. But those files are part of the code base, and can > > be reviewed and audited. > > x86 has a long history if failing at exactly that. That's a fair point. But on the flip side, maintaining objtool does not look like it has been a walk in the park either. What i am especially concerned about is things like 3193c0836f20, where we actually have to disable certain compiler optimizations because they interfere with objtool's ability to understand the resulting object code. Correctness and performance are challenging enough as requirements for generated code. Mind you, I am not saying it is not worth it *for x86*, where there is a lot of other stuff going on. But on arm64, we don't care about ORC, about -fomit-frame-pointer, about retpolines or about any of the other things objtool enables. On arm64, all it currently seems to provide is a way to capture the call stack accurately, and given that it needs a GCC plugin for this (which needs to be maintained as well, which is non-trivial, and also bars us from using objtool with Clang builds), my current position is simply that opening this can of worms at this point is just not worth it. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 @ 2021-01-21 11:48 ` Ard Biesheuvel 0 siblings, 0 replies; 106+ messages in thread From: Ard Biesheuvel @ 2021-01-21 11:48 UTC (permalink / raw) To: Peter Zijlstra Cc: Mark Rutland, Michal Marek, Julien Thierry, linux-efi, Catalin Marinas, Masahiro Yamada, Linux Kernel Mailing List, Mark Brown, linux-hardening, Josh Poimboeuf, Will Deacon, Linux ARM, Kees Cook On Thu, 21 Jan 2021 at 12:23, Peter Zijlstra <peterz@infradead.org> wrote: > > On Thu, Jan 21, 2021 at 12:08:23PM +0100, Ard Biesheuvel wrote: > > On Thu, 21 Jan 2021 at 11:26, Julien Thierry <jthierry@redhat.com> wrote: > > > > I'm not familiar with toolcahin code models, but would this approach be > > > able to validate assembly code (either inline or in assembly files?) > > > > > > > No, it would not. But those files are part of the code base, and can > > be reviewed and audited. > > x86 has a long history if failing at exactly that. That's a fair point. But on the flip side, maintaining objtool does not look like it has been a walk in the park either. What i am especially concerned about is things like 3193c0836f20, where we actually have to disable certain compiler optimizations because they interfere with objtool's ability to understand the resulting object code. Correctness and performance are challenging enough as requirements for generated code. Mind you, I am not saying it is not worth it *for x86*, where there is a lot of other stuff going on. But on arm64, we don't care about ORC, about -fomit-frame-pointer, about retpolines or about any of the other things objtool enables. On arm64, all it currently seems to provide is a way to capture the call stack accurately, and given that it needs a GCC plugin for this (which needs to be maintained as well, which is non-trivial, and also bars us from using objtool with Clang builds), my current position is simply that opening this can of worms at this point is just not worth it. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 2021-01-21 11:48 ` Ard Biesheuvel @ 2021-01-21 18:54 ` Josh Poimboeuf -1 siblings, 0 replies; 106+ messages in thread From: Josh Poimboeuf @ 2021-01-21 18:54 UTC (permalink / raw) To: Ard Biesheuvel Cc: Peter Zijlstra, Julien Thierry, Linux Kernel Mailing List, Linux ARM, Catalin Marinas, Will Deacon, Masahiro Yamada, Kees Cook, Michal Marek, Mark Rutland, Mark Brown, linux-efi, linux-hardening, live-patching Ard, Sorry, I was late to the party, attempting to reply to the entire thread at once. Also, adding the live-patching ML. I agree with a lot of your concerns. Reverse engineering the control flow of the compiled binary is kind of ridiculous. I was always surprised that it works. I still am! But I think it's more robust than you give it credit for. Most of the existing code just works, with (annual) tweaks for new compiler versions. In fact now it works well with both GCC and Clang, across several versions. Soon it will work with LTO. It has grown many uses beyond stack validation: ORC, static calls, retpolines validation, noinstr validation, SMAP validation. It has found a *lot* of compiler bugs. And there will probably be more use cases when we get vmlinux validation running fast enough. But there is indeed a maintenance burden. I often ask myself if it's worth it. So far the answer has been yes :-) Particularly because it has influenced many positive changes to the kernel. And it helps now that even more people are contributing and adding useful features. But you should definitely think twice before letting it loose on your arch, especially if you have some other way to ensure reliable stack metadata, and if you don't have a need for the other objtool features. Regarding your other proposals: 1) I'm doubtful we can ever rely on the toolchain to ensure reliable unwind metadata, because: a) most of the problems are in asm and inline-asm; good luck getting the toolchain to care about those. b) the toolchain is fragile; do we want to entrust the integrity of live patching to the compiler's frame pointer generation (or other unwind metadata) without having some sort of checking mechanism? 2) The shadow stack idea sounds promising -- how hard would it be to make a prototype reliable unwinder? More comments below: On Thu, Jan 21, 2021 at 12:48:43PM +0100, Ard Biesheuvel wrote: > On Thu, 21 Jan 2021 at 12:23, Peter Zijlstra <peterz@infradead.org> wrote: > > > > On Thu, Jan 21, 2021 at 12:08:23PM +0100, Ard Biesheuvel wrote: > > > On Thu, 21 Jan 2021 at 11:26, Julien Thierry <jthierry@redhat.com> wrote: > > > > > > I'm not familiar with toolcahin code models, but would this approach be > > > > able to validate assembly code (either inline or in assembly files?) > > > > > > > > > > No, it would not. But those files are part of the code base, and can > > > be reviewed and audited. > > > > x86 has a long history if failing at exactly that. > > That's a fair point. But on the flip side, maintaining objtool does > not look like it has been a walk in the park either. I think you missed Peter's point: it's not that it's *hard* for humans to continuously review/audit all asm and inline-asm; it's just not feasible to do it 100% correctly, 100% of the time. Like any other code, objtool requires maintenance, but its analysis is orders of magnitude more robust than any human. > What i am especially concerned about is things like 3193c0836f20, > where we actually have to disable certain compiler optimizations > because they interfere with objtool's ability to understand the > resulting object code. Correctness and performance are challenging > enough as requirements for generated code. Well, you managed to find the worst case scenario. I think that's the only time we ever had to do that. Please don't think that's normal, or even a generally realistic concern. Objtool tries really hard to stay out of the way. Long term we really want to prevent that type of thing with the help of annotations from compiler plugins, similar to what Julien did here. Yes, it would mean two objtool compiler plugins (GCC and Clang), but it would ease the objtool maintenance burden and risk in many ways. And prevent situations like that commit you found. It may sound fragile, but it will actually make things simpler overall: less reverse engineering of GCC switch jump tables and __noreturn functions is a good thing. > Mind you, I am not saying it is not worth it *for x86*, where there is > a lot of other stuff going on. But on arm64, we don't care about ORC, > about -fomit-frame-pointer, about retpolines or about any of the other > things objtool enables. > > On arm64, all it currently seems to provide is a way to capture the > call stack accurately, and given that it needs a GCC plugin for this > (which needs to be maintained as well, which is non-trivial, and also > bars us from using objtool with Clang builds), my current position is > simply that opening this can of worms at this point is just not worth > it. As far as GCC plugins go, it looks pretty basic to me. Also this doesn't *at all* prevent Clang from being used for live patching. If anybody actually tries running Julien's patches on a Clang-built kernel, it might just work. But if not, and the switch tables turn out to be unparseable like on GCC, we could have a Clang plugin. As I mentioned, we'll probably end up having one anyway for x86. -- Josh ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 @ 2021-01-21 18:54 ` Josh Poimboeuf 0 siblings, 0 replies; 106+ messages in thread From: Josh Poimboeuf @ 2021-01-21 18:54 UTC (permalink / raw) To: Ard Biesheuvel Cc: Mark Rutland, linux-efi, Michal Marek, Julien Thierry, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, Linux Kernel Mailing List, Mark Brown, linux-hardening, live-patching, Will Deacon, Linux ARM, Kees Cook Ard, Sorry, I was late to the party, attempting to reply to the entire thread at once. Also, adding the live-patching ML. I agree with a lot of your concerns. Reverse engineering the control flow of the compiled binary is kind of ridiculous. I was always surprised that it works. I still am! But I think it's more robust than you give it credit for. Most of the existing code just works, with (annual) tweaks for new compiler versions. In fact now it works well with both GCC and Clang, across several versions. Soon it will work with LTO. It has grown many uses beyond stack validation: ORC, static calls, retpolines validation, noinstr validation, SMAP validation. It has found a *lot* of compiler bugs. And there will probably be more use cases when we get vmlinux validation running fast enough. But there is indeed a maintenance burden. I often ask myself if it's worth it. So far the answer has been yes :-) Particularly because it has influenced many positive changes to the kernel. And it helps now that even more people are contributing and adding useful features. But you should definitely think twice before letting it loose on your arch, especially if you have some other way to ensure reliable stack metadata, and if you don't have a need for the other objtool features. Regarding your other proposals: 1) I'm doubtful we can ever rely on the toolchain to ensure reliable unwind metadata, because: a) most of the problems are in asm and inline-asm; good luck getting the toolchain to care about those. b) the toolchain is fragile; do we want to entrust the integrity of live patching to the compiler's frame pointer generation (or other unwind metadata) without having some sort of checking mechanism? 2) The shadow stack idea sounds promising -- how hard would it be to make a prototype reliable unwinder? More comments below: On Thu, Jan 21, 2021 at 12:48:43PM +0100, Ard Biesheuvel wrote: > On Thu, 21 Jan 2021 at 12:23, Peter Zijlstra <peterz@infradead.org> wrote: > > > > On Thu, Jan 21, 2021 at 12:08:23PM +0100, Ard Biesheuvel wrote: > > > On Thu, 21 Jan 2021 at 11:26, Julien Thierry <jthierry@redhat.com> wrote: > > > > > > I'm not familiar with toolcahin code models, but would this approach be > > > > able to validate assembly code (either inline or in assembly files?) > > > > > > > > > > No, it would not. But those files are part of the code base, and can > > > be reviewed and audited. > > > > x86 has a long history if failing at exactly that. > > That's a fair point. But on the flip side, maintaining objtool does > not look like it has been a walk in the park either. I think you missed Peter's point: it's not that it's *hard* for humans to continuously review/audit all asm and inline-asm; it's just not feasible to do it 100% correctly, 100% of the time. Like any other code, objtool requires maintenance, but its analysis is orders of magnitude more robust than any human. > What i am especially concerned about is things like 3193c0836f20, > where we actually have to disable certain compiler optimizations > because they interfere with objtool's ability to understand the > resulting object code. Correctness and performance are challenging > enough as requirements for generated code. Well, you managed to find the worst case scenario. I think that's the only time we ever had to do that. Please don't think that's normal, or even a generally realistic concern. Objtool tries really hard to stay out of the way. Long term we really want to prevent that type of thing with the help of annotations from compiler plugins, similar to what Julien did here. Yes, it would mean two objtool compiler plugins (GCC and Clang), but it would ease the objtool maintenance burden and risk in many ways. And prevent situations like that commit you found. It may sound fragile, but it will actually make things simpler overall: less reverse engineering of GCC switch jump tables and __noreturn functions is a good thing. > Mind you, I am not saying it is not worth it *for x86*, where there is > a lot of other stuff going on. But on arm64, we don't care about ORC, > about -fomit-frame-pointer, about retpolines or about any of the other > things objtool enables. > > On arm64, all it currently seems to provide is a way to capture the > call stack accurately, and given that it needs a GCC plugin for this > (which needs to be maintained as well, which is non-trivial, and also > bars us from using objtool with Clang builds), my current position is > simply that opening this can of worms at this point is just not worth > it. As far as GCC plugins go, it looks pretty basic to me. Also this doesn't *at all* prevent Clang from being used for live patching. If anybody actually tries running Julien's patches on a Clang-built kernel, it might just work. But if not, and the switch tables turn out to be unparseable like on GCC, we could have a Clang plugin. As I mentioned, we'll probably end up having one anyway for x86. -- Josh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 2021-01-21 18:54 ` Josh Poimboeuf @ 2021-01-22 17:43 ` Mark Brown -1 siblings, 0 replies; 106+ messages in thread From: Mark Brown @ 2021-01-22 17:43 UTC (permalink / raw) To: Josh Poimboeuf Cc: Ard Biesheuvel, Peter Zijlstra, Julien Thierry, Linux Kernel Mailing List, Linux ARM, Catalin Marinas, Will Deacon, Masahiro Yamada, Kees Cook, Michal Marek, Mark Rutland, linux-efi, linux-hardening, live-patching [-- Attachment #1: Type: text/plain, Size: 548 bytes --] On Thu, Jan 21, 2021 at 12:54:52PM -0600, Josh Poimboeuf wrote: > 2) The shadow stack idea sounds promising -- how hard would it be to > make a prototype reliable unwinder? In theory it doesn't look too hard and I can't see a particular reason not to try doing this - there's going to be edge cases but hopefully for reliable stack trace they're all in areas where we would be happy to just decide the stack isn't reliable anyway, things like nesting which allocates separate shadow stacks for each nested level for example. I'll take a look. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 @ 2021-01-22 17:43 ` Mark Brown 0 siblings, 0 replies; 106+ messages in thread From: Mark Brown @ 2021-01-22 17:43 UTC (permalink / raw) To: Josh Poimboeuf Cc: Mark Rutland, Michal Marek, Julien Thierry, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, Linux Kernel Mailing List, linux-efi, linux-hardening, live-patching, Will Deacon, Ard Biesheuvel, Linux ARM, Kees Cook [-- Attachment #1.1: Type: text/plain, Size: 548 bytes --] On Thu, Jan 21, 2021 at 12:54:52PM -0600, Josh Poimboeuf wrote: > 2) The shadow stack idea sounds promising -- how hard would it be to > make a prototype reliable unwinder? In theory it doesn't look too hard and I can't see a particular reason not to try doing this - there's going to be edge cases but hopefully for reliable stack trace they're all in areas where we would be happy to just decide the stack isn't reliable anyway, things like nesting which allocates separate shadow stacks for each nested level for example. I'll take a look. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 2021-01-22 17:43 ` Mark Brown @ 2021-01-22 17:54 ` Ard Biesheuvel -1 siblings, 0 replies; 106+ messages in thread From: Ard Biesheuvel @ 2021-01-22 17:54 UTC (permalink / raw) To: Mark Brown Cc: Josh Poimboeuf, Peter Zijlstra, Julien Thierry, Linux Kernel Mailing List, Linux ARM, Catalin Marinas, Will Deacon, Masahiro Yamada, Kees Cook, Michal Marek, Mark Rutland, linux-efi, linux-hardening, live-patching On Fri, 22 Jan 2021 at 18:44, Mark Brown <broonie@kernel.org> wrote: > > On Thu, Jan 21, 2021 at 12:54:52PM -0600, Josh Poimboeuf wrote: > > > 2) The shadow stack idea sounds promising -- how hard would it be to > > make a prototype reliable unwinder? > > In theory it doesn't look too hard and I can't see a particular reason > not to try doing this - there's going to be edge cases but hopefully for > reliable stack trace they're all in areas where we would be happy to > just decide the stack isn't reliable anyway, things like nesting which > allocates separate shadow stacks for each nested level for example. > I'll take a look. This reminds me - a while ago, I had a stab at writing a rudimentary GCC plugin that pushes/pops return addresses to a shadow call stack pointed to by x18 [0] I am by no means suggesting that we should rely on a GCC plugin for this, only that it does seem rather straight-forward for the compiler to manage a stack with return addresses like that (although the devil is probably in the details, as usual) [0] https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm64-scs-gcc ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 @ 2021-01-22 17:54 ` Ard Biesheuvel 0 siblings, 0 replies; 106+ messages in thread From: Ard Biesheuvel @ 2021-01-22 17:54 UTC (permalink / raw) To: Mark Brown Cc: Mark Rutland, Michal Marek, Julien Thierry, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, Linux Kernel Mailing List, linux-efi, linux-hardening, Josh Poimboeuf, live-patching, Will Deacon, Linux ARM, Kees Cook On Fri, 22 Jan 2021 at 18:44, Mark Brown <broonie@kernel.org> wrote: > > On Thu, Jan 21, 2021 at 12:54:52PM -0600, Josh Poimboeuf wrote: > > > 2) The shadow stack idea sounds promising -- how hard would it be to > > make a prototype reliable unwinder? > > In theory it doesn't look too hard and I can't see a particular reason > not to try doing this - there's going to be edge cases but hopefully for > reliable stack trace they're all in areas where we would be happy to > just decide the stack isn't reliable anyway, things like nesting which > allocates separate shadow stacks for each nested level for example. > I'll take a look. This reminds me - a while ago, I had a stab at writing a rudimentary GCC plugin that pushes/pops return addresses to a shadow call stack pointed to by x18 [0] I am by no means suggesting that we should rely on a GCC plugin for this, only that it does seem rather straight-forward for the compiler to manage a stack with return addresses like that (although the devil is probably in the details, as usual) [0] https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm64-scs-gcc _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 2021-01-22 17:54 ` Ard Biesheuvel @ 2021-01-28 22:10 ` Madhavan T. Venkataraman -1 siblings, 0 replies; 106+ messages in thread From: Madhavan T. Venkataraman @ 2021-01-28 22:10 UTC (permalink / raw) To: Mark Brown, Mark Rutland, Julien Thierry, Josh Poimboeuf Cc: Ard Biesheuvel, Michal Marek, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, Linux Kernel Mailing List, linux-efi, linux-hardening, live-patching, Will Deacon, Linux ARM, Kees Cook Hi, I sent this suggestion to linux-arm-kernel in response to the Reliable Stacktrace RFC from Mark Brown and Mark Rutland. I am repeating it here for two reasons: - It involves objtool. - There are many more recipients in this thread that may be interested in this topic. Please let me know if this suggestion is acceptable. If it is not, please let me know why. Thanks. Also, I apologize to all of you who have received this more than once. FP and no-FP functions ===================== I have a suggestion for objtool and the unwinder for ARM64. IIUC, objtool is responsible for walking all the code paths (except unreachable and ignored ones) and making sure that every function has proper frame pointer code (prolog, epilog, etc). If a function is found to not have it, the kernel build is failed. Is this understanding correct? If so, can we take a different approach for ARM64? Instead of failing the kernel build, can we just mark the functions as: FP Functions that have proper FP code no-FP Functions that don't May be, we can add an "FP" flag in the symbol table entry for this. Then, the unwinder can check the functions it encounters in the stack trace and inform the caller if it found any no-FP functions. The caller of the unwinder can decide what he wants to do with that information. - the caller can ignore it - the caller can print the stack trace with a warning that no-FP functions were found - if the caller is livepatch, the caller can retry until the no-FP functions disappear from the stack trace. This way, we can have live patching even when some of the functions in the kernel are no-FP. Does this make any sense? Is this acceptable? What are the pitfalls? If we can do this, the unwinder could detect cases such as: - If gcc thinks that a function is a leaf function but the function contains inline assembly code that calls another function. - If a call to a function bounces through some intermediate code such as a trampoline. - etc. For specific no-FP functions, the unwinder might be able to deduce the original caller. In these cases, the stack trace would still be reliable. For all the others, the stack trace would be considered unreliable. Compiler instead of objtool =========================== If the above suggestion is acceptable, I have another suggestion. It is a lot of work for every new architecture to add frame pointer verification support in objtool. Can we get some help from the compiler? The compiler knows which C functions it generates the FP prolog and epilog for. It can mark those functions as FP. As for assembly functions, kernel developers could manually annotate functions that have proper FP code. The compiler/assembler would mark them as FP. Only a small subset of assembly functions would even have FP prolog and epilog. Is this acceptable? What are the pitfalls? This can be implemented easily for all architectures for which the compiler generates FP code. Can this be implemented using a GCC plugin? I know squat about GCC plugins. Thanks! Madhavan ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 @ 2021-01-28 22:10 ` Madhavan T. Venkataraman 0 siblings, 0 replies; 106+ messages in thread From: Madhavan T. Venkataraman @ 2021-01-28 22:10 UTC (permalink / raw) To: Mark Brown, Mark Rutland, Julien Thierry, Josh Poimboeuf Cc: Michal Marek, Kees Cook, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, Linux Kernel Mailing List, linux-efi, linux-hardening, live-patching, Will Deacon, Ard Biesheuvel, Linux ARM Hi, I sent this suggestion to linux-arm-kernel in response to the Reliable Stacktrace RFC from Mark Brown and Mark Rutland. I am repeating it here for two reasons: - It involves objtool. - There are many more recipients in this thread that may be interested in this topic. Please let me know if this suggestion is acceptable. If it is not, please let me know why. Thanks. Also, I apologize to all of you who have received this more than once. FP and no-FP functions ===================== I have a suggestion for objtool and the unwinder for ARM64. IIUC, objtool is responsible for walking all the code paths (except unreachable and ignored ones) and making sure that every function has proper frame pointer code (prolog, epilog, etc). If a function is found to not have it, the kernel build is failed. Is this understanding correct? If so, can we take a different approach for ARM64? Instead of failing the kernel build, can we just mark the functions as: FP Functions that have proper FP code no-FP Functions that don't May be, we can add an "FP" flag in the symbol table entry for this. Then, the unwinder can check the functions it encounters in the stack trace and inform the caller if it found any no-FP functions. The caller of the unwinder can decide what he wants to do with that information. - the caller can ignore it - the caller can print the stack trace with a warning that no-FP functions were found - if the caller is livepatch, the caller can retry until the no-FP functions disappear from the stack trace. This way, we can have live patching even when some of the functions in the kernel are no-FP. Does this make any sense? Is this acceptable? What are the pitfalls? If we can do this, the unwinder could detect cases such as: - If gcc thinks that a function is a leaf function but the function contains inline assembly code that calls another function. - If a call to a function bounces through some intermediate code such as a trampoline. - etc. For specific no-FP functions, the unwinder might be able to deduce the original caller. In these cases, the stack trace would still be reliable. For all the others, the stack trace would be considered unreliable. Compiler instead of objtool =========================== If the above suggestion is acceptable, I have another suggestion. It is a lot of work for every new architecture to add frame pointer verification support in objtool. Can we get some help from the compiler? The compiler knows which C functions it generates the FP prolog and epilog for. It can mark those functions as FP. As for assembly functions, kernel developers could manually annotate functions that have proper FP code. The compiler/assembler would mark them as FP. Only a small subset of assembly functions would even have FP prolog and epilog. Is this acceptable? What are the pitfalls? This can be implemented easily for all architectures for which the compiler generates FP code. Can this be implemented using a GCC plugin? I know squat about GCC plugins. Thanks! Madhavan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 2021-01-28 22:10 ` Madhavan T. Venkataraman (?) @ 2021-01-29 15:47 ` Mark Brown -1 siblings, 0 replies; 106+ messages in thread From: Mark Brown @ 2021-01-29 15:47 UTC (permalink / raw) To: Madhavan T. Venkataraman Cc: Mark Rutland, Michal Marek, Julien Thierry, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, Linux Kernel Mailing List, linux-efi, linux-hardening, Josh Poimboeuf, live-patching, Will Deacon, Ard Biesheuvel, Linux ARM, Kees Cook [-- Attachment #1.1: Type: text/plain, Size: 712 bytes --] On Thu, Jan 28, 2021 at 04:10:51PM -0600, Madhavan T. Venkataraman wrote: > I sent this suggestion to linux-arm-kernel in response to the Reliable Stacktrace RFC from Mark Brown > and Mark Rutland. I am repeating it here for two reasons: > - It involves objtool. > - There are many more recipients in this thread that may be interested in this topic. > Please let me know if this suggestion is acceptable. If it is not, please let me know why. > Thanks. There was some feedback on the other thread raising concerns, including questions about the benefits of trusting the compiler to flag non-standard code without expectation mismatches and the utility of allowing the compiler to do so in the first place. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 2021-01-22 17:43 ` Mark Brown @ 2021-01-22 21:15 ` Madhavan T. Venkataraman -1 siblings, 0 replies; 106+ messages in thread From: Madhavan T. Venkataraman @ 2021-01-22 21:15 UTC (permalink / raw) To: Mark Brown, Josh Poimboeuf Cc: Mark Rutland, Michal Marek, Julien Thierry, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, Linux Kernel Mailing List, linux-efi, linux-hardening, live-patching, Will Deacon, Ard Biesheuvel, Linux ARM, Kees Cook On 1/22/21 11:43 AM, Mark Brown wrote: > On Thu, Jan 21, 2021 at 12:54:52PM -0600, Josh Poimboeuf wrote: > >> 2) The shadow stack idea sounds promising -- how hard would it be to >> make a prototype reliable unwinder? > > In theory it doesn't look too hard and I can't see a particular reason > not to try doing this - there's going to be edge cases but hopefully for > reliable stack trace they're all in areas where we would be happy to > just decide the stack isn't reliable anyway, things like nesting which > allocates separate shadow stacks for each nested level for example. > I'll take a look. > I am a new comer to this discussion and I am learning. Just have some questions. Pardon me if they are obvious or if they have already been asked and answered. Doesn't Clang already have support for a shadow stack implementation for ARM64? We could take a look at how Clang does it. Will there not be a significant performance hit? May be, some of it can be mitigated by using a parallel shadow stack rather than a compact one. Are there any longjmp style situations in the kernel where the stack is unwound by several frames? In these cases, the shadow stack must be unwound accordingly. Madhavan > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 @ 2021-01-22 21:15 ` Madhavan T. Venkataraman 0 siblings, 0 replies; 106+ messages in thread From: Madhavan T. Venkataraman @ 2021-01-22 21:15 UTC (permalink / raw) To: Mark Brown, Josh Poimboeuf Cc: Mark Rutland, Michal Marek, Julien Thierry, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, Linux Kernel Mailing List, linux-efi, linux-hardening, live-patching, Will Deacon, Ard Biesheuvel, Linux ARM, Kees Cook On 1/22/21 11:43 AM, Mark Brown wrote: > On Thu, Jan 21, 2021 at 12:54:52PM -0600, Josh Poimboeuf wrote: > >> 2) The shadow stack idea sounds promising -- how hard would it be to >> make a prototype reliable unwinder? > > In theory it doesn't look too hard and I can't see a particular reason > not to try doing this - there's going to be edge cases but hopefully for > reliable stack trace they're all in areas where we would be happy to > just decide the stack isn't reliable anyway, things like nesting which > allocates separate shadow stacks for each nested level for example. > I'll take a look. > I am a new comer to this discussion and I am learning. Just have some questions. Pardon me if they are obvious or if they have already been asked and answered. Doesn't Clang already have support for a shadow stack implementation for ARM64? We could take a look at how Clang does it. Will there not be a significant performance hit? May be, some of it can be mitigated by using a parallel shadow stack rather than a compact one. Are there any longjmp style situations in the kernel where the stack is unwound by several frames? In these cases, the shadow stack must be unwound accordingly. Madhavan > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 2021-01-22 21:15 ` Madhavan T. Venkataraman @ 2021-01-22 21:43 ` Ard Biesheuvel -1 siblings, 0 replies; 106+ messages in thread From: Ard Biesheuvel @ 2021-01-22 21:43 UTC (permalink / raw) To: Madhavan T. Venkataraman Cc: Mark Brown, Josh Poimboeuf, Mark Rutland, Michal Marek, Julien Thierry, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, Linux Kernel Mailing List, linux-efi, linux-hardening, live-patching, Will Deacon, Linux ARM, Kees Cook On Fri, 22 Jan 2021 at 22:15, Madhavan T. Venkataraman <madvenka@linux.microsoft.com> wrote: > > > > On 1/22/21 11:43 AM, Mark Brown wrote: > > On Thu, Jan 21, 2021 at 12:54:52PM -0600, Josh Poimboeuf wrote: > > > >> 2) The shadow stack idea sounds promising -- how hard would it be to > >> make a prototype reliable unwinder? > > > > In theory it doesn't look too hard and I can't see a particular reason > > not to try doing this - there's going to be edge cases but hopefully for > > reliable stack trace they're all in areas where we would be happy to > > just decide the stack isn't reliable anyway, things like nesting which > > allocates separate shadow stacks for each nested level for example. > > I'll take a look. > > > > I am a new comer to this discussion and I am learning. Just have some > questions. Pardon me if they are obvious or if they have already been > asked and answered. > > Doesn't Clang already have support for a shadow stack implementation for ARM64? > We could take a look at how Clang does it. > > Will there not be a significant performance hit? May be, some of it can be > mitigated by using a parallel shadow stack rather than a compact one. > > Are there any longjmp style situations in the kernel where the stack is > unwound by several frames? In these cases, the shadow stack must be unwound > accordingly. > Hello Madhavan, Let's discuss the details of shadow call stacks on a separate thread, instead of further hijacking Julien's series. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 @ 2021-01-22 21:43 ` Ard Biesheuvel 0 siblings, 0 replies; 106+ messages in thread From: Ard Biesheuvel @ 2021-01-22 21:43 UTC (permalink / raw) To: Madhavan T. Venkataraman Cc: Mark Rutland, linux-efi, Michal Marek, Julien Thierry, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, Linux Kernel Mailing List, Mark Brown, linux-hardening, Josh Poimboeuf, live-patching, Will Deacon, Linux ARM, Kees Cook On Fri, 22 Jan 2021 at 22:15, Madhavan T. Venkataraman <madvenka@linux.microsoft.com> wrote: > > > > On 1/22/21 11:43 AM, Mark Brown wrote: > > On Thu, Jan 21, 2021 at 12:54:52PM -0600, Josh Poimboeuf wrote: > > > >> 2) The shadow stack idea sounds promising -- how hard would it be to > >> make a prototype reliable unwinder? > > > > In theory it doesn't look too hard and I can't see a particular reason > > not to try doing this - there's going to be edge cases but hopefully for > > reliable stack trace they're all in areas where we would be happy to > > just decide the stack isn't reliable anyway, things like nesting which > > allocates separate shadow stacks for each nested level for example. > > I'll take a look. > > > > I am a new comer to this discussion and I am learning. Just have some > questions. Pardon me if they are obvious or if they have already been > asked and answered. > > Doesn't Clang already have support for a shadow stack implementation for ARM64? > We could take a look at how Clang does it. > > Will there not be a significant performance hit? May be, some of it can be > mitigated by using a parallel shadow stack rather than a compact one. > > Are there any longjmp style situations in the kernel where the stack is > unwound by several frames? In these cases, the shadow stack must be unwound > accordingly. > Hello Madhavan, Let's discuss the details of shadow call stacks on a separate thread, instead of further hijacking Julien's series. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 2021-01-22 21:43 ` Ard Biesheuvel @ 2021-01-22 21:44 ` Madhavan T. Venkataraman -1 siblings, 0 replies; 106+ messages in thread From: Madhavan T. Venkataraman @ 2021-01-22 21:44 UTC (permalink / raw) To: Ard Biesheuvel Cc: Mark Brown, Josh Poimboeuf, Mark Rutland, Michal Marek, Julien Thierry, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, Linux Kernel Mailing List, linux-efi, linux-hardening, live-patching, Will Deacon, Linux ARM, Kees Cook On 1/22/21 3:43 PM, Ard Biesheuvel wrote: > On Fri, 22 Jan 2021 at 22:15, Madhavan T. Venkataraman > <madvenka@linux.microsoft.com> wrote: >> >> >> >> On 1/22/21 11:43 AM, Mark Brown wrote: >>> On Thu, Jan 21, 2021 at 12:54:52PM -0600, Josh Poimboeuf wrote: >>> >>>> 2) The shadow stack idea sounds promising -- how hard would it be to >>>> make a prototype reliable unwinder? >>> >>> In theory it doesn't look too hard and I can't see a particular reason >>> not to try doing this - there's going to be edge cases but hopefully for >>> reliable stack trace they're all in areas where we would be happy to >>> just decide the stack isn't reliable anyway, things like nesting which >>> allocates separate shadow stacks for each nested level for example. >>> I'll take a look. >>> >> >> I am a new comer to this discussion and I am learning. Just have some >> questions. Pardon me if they are obvious or if they have already been >> asked and answered. >> >> Doesn't Clang already have support for a shadow stack implementation for ARM64? >> We could take a look at how Clang does it. >> >> Will there not be a significant performance hit? May be, some of it can be >> mitigated by using a parallel shadow stack rather than a compact one. >> >> Are there any longjmp style situations in the kernel where the stack is >> unwound by several frames? In these cases, the shadow stack must be unwound >> accordingly. >> > > Hello Madhavan, > > Let's discuss the details of shadow call stacks on a separate thread, > instead of further hijacking Julien's series. > OK. Sounds good. ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 @ 2021-01-22 21:44 ` Madhavan T. Venkataraman 0 siblings, 0 replies; 106+ messages in thread From: Madhavan T. Venkataraman @ 2021-01-22 21:44 UTC (permalink / raw) To: Ard Biesheuvel Cc: Mark Rutland, linux-efi, Michal Marek, Julien Thierry, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, Linux Kernel Mailing List, Mark Brown, linux-hardening, Josh Poimboeuf, live-patching, Will Deacon, Linux ARM, Kees Cook On 1/22/21 3:43 PM, Ard Biesheuvel wrote: > On Fri, 22 Jan 2021 at 22:15, Madhavan T. Venkataraman > <madvenka@linux.microsoft.com> wrote: >> >> >> >> On 1/22/21 11:43 AM, Mark Brown wrote: >>> On Thu, Jan 21, 2021 at 12:54:52PM -0600, Josh Poimboeuf wrote: >>> >>>> 2) The shadow stack idea sounds promising -- how hard would it be to >>>> make a prototype reliable unwinder? >>> >>> In theory it doesn't look too hard and I can't see a particular reason >>> not to try doing this - there's going to be edge cases but hopefully for >>> reliable stack trace they're all in areas where we would be happy to >>> just decide the stack isn't reliable anyway, things like nesting which >>> allocates separate shadow stacks for each nested level for example. >>> I'll take a look. >>> >> >> I am a new comer to this discussion and I am learning. Just have some >> questions. Pardon me if they are obvious or if they have already been >> asked and answered. >> >> Doesn't Clang already have support for a shadow stack implementation for ARM64? >> We could take a look at how Clang does it. >> >> Will there not be a significant performance hit? May be, some of it can be >> mitigated by using a parallel shadow stack rather than a compact one. >> >> Are there any longjmp style situations in the kernel where the stack is >> unwound by several frames? In these cases, the shadow stack must be unwound >> accordingly. >> > > Hello Madhavan, > > Let's discuss the details of shadow call stacks on a separate thread, > instead of further hijacking Julien's series. > OK. Sounds good. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 2021-01-22 21:43 ` Ard Biesheuvel @ 2021-01-25 21:19 ` Josh Poimboeuf -1 siblings, 0 replies; 106+ messages in thread From: Josh Poimboeuf @ 2021-01-25 21:19 UTC (permalink / raw) To: Ard Biesheuvel Cc: Madhavan T. Venkataraman, Mark Brown, Mark Rutland, Michal Marek, Julien Thierry, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, Linux Kernel Mailing List, linux-efi, linux-hardening, live-patching, Will Deacon, Linux ARM, Kees Cook On Fri, Jan 22, 2021 at 10:43:09PM +0100, Ard Biesheuvel wrote: > On Fri, 22 Jan 2021 at 22:15, Madhavan T. Venkataraman <madvenka@linux.microsoft.com> wrote: > > On 1/22/21 11:43 AM, Mark Brown wrote: > > > On Thu, Jan 21, 2021 at 12:54:52PM -0600, Josh Poimboeuf wrote: > > > > > >> 2) The shadow stack idea sounds promising -- how hard would it be to > > >> make a prototype reliable unwinder? > > > > > > In theory it doesn't look too hard and I can't see a particular reason > > > not to try doing this - there's going to be edge cases but hopefully for > > > reliable stack trace they're all in areas where we would be happy to > > > just decide the stack isn't reliable anyway, things like nesting which > > > allocates separate shadow stacks for each nested level for example. > > > I'll take a look. > > > > > > > I am a new comer to this discussion and I am learning. Just have some > > questions. Pardon me if they are obvious or if they have already been > > asked and answered. > > > > Doesn't Clang already have support for a shadow stack implementation for ARM64? > > We could take a look at how Clang does it. > > > > Will there not be a significant performance hit? May be, some of it can be > > mitigated by using a parallel shadow stack rather than a compact one. > > > > Are there any longjmp style situations in the kernel where the stack is > > unwound by several frames? In these cases, the shadow stack must be unwound > > accordingly. > > > > Hello Madhavan, > > Let's discuss the details of shadow call stacks on a separate thread, > instead of further hijacking Julien's series. It's quite relevant to this thread. There's no need to consider merging Julien's patches if you have a better approach. Why not discuss it here? I'm also interested in the answers to Madhavan's questions. -- Josh ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 @ 2021-01-25 21:19 ` Josh Poimboeuf 0 siblings, 0 replies; 106+ messages in thread From: Josh Poimboeuf @ 2021-01-25 21:19 UTC (permalink / raw) To: Ard Biesheuvel Cc: Mark Rutland, linux-efi, Michal Marek, Julien Thierry, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, Linux Kernel Mailing List, Madhavan T. Venkataraman, Mark Brown, linux-hardening, live-patching, Will Deacon, Linux ARM, Kees Cook On Fri, Jan 22, 2021 at 10:43:09PM +0100, Ard Biesheuvel wrote: > On Fri, 22 Jan 2021 at 22:15, Madhavan T. Venkataraman <madvenka@linux.microsoft.com> wrote: > > On 1/22/21 11:43 AM, Mark Brown wrote: > > > On Thu, Jan 21, 2021 at 12:54:52PM -0600, Josh Poimboeuf wrote: > > > > > >> 2) The shadow stack idea sounds promising -- how hard would it be to > > >> make a prototype reliable unwinder? > > > > > > In theory it doesn't look too hard and I can't see a particular reason > > > not to try doing this - there's going to be edge cases but hopefully for > > > reliable stack trace they're all in areas where we would be happy to > > > just decide the stack isn't reliable anyway, things like nesting which > > > allocates separate shadow stacks for each nested level for example. > > > I'll take a look. > > > > > > > I am a new comer to this discussion and I am learning. Just have some > > questions. Pardon me if they are obvious or if they have already been > > asked and answered. > > > > Doesn't Clang already have support for a shadow stack implementation for ARM64? > > We could take a look at how Clang does it. > > > > Will there not be a significant performance hit? May be, some of it can be > > mitigated by using a parallel shadow stack rather than a compact one. > > > > Are there any longjmp style situations in the kernel where the stack is > > unwound by several frames? In these cases, the shadow stack must be unwound > > accordingly. > > > > Hello Madhavan, > > Let's discuss the details of shadow call stacks on a separate thread, > instead of further hijacking Julien's series. It's quite relevant to this thread. There's no need to consider merging Julien's patches if you have a better approach. Why not discuss it here? I'm also interested in the answers to Madhavan's questions. -- Josh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 2021-01-22 17:43 ` Mark Brown @ 2021-01-22 21:16 ` Madhavan T. Venkataraman -1 siblings, 0 replies; 106+ messages in thread From: Madhavan T. Venkataraman @ 2021-01-22 21:16 UTC (permalink / raw) To: Mark Brown, Josh Poimboeuf Cc: Mark Rutland, Michal Marek, Julien Thierry, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, Linux Kernel Mailing List, linux-efi, linux-hardening, live-patching, Will Deacon, Ard Biesheuvel, Linux ARM, Kees Cook On 1/22/21 11:43 AM, Mark Brown wrote: > On Thu, Jan 21, 2021 at 12:54:52PM -0600, Josh Poimboeuf wrote: > >> 2) The shadow stack idea sounds promising -- how hard would it be to >> make a prototype reliable unwinder? > > In theory it doesn't look too hard and I can't see a particular reason > not to try doing this - there's going to be edge cases but hopefully for > reliable stack trace they're all in areas where we would be happy to > just decide the stack isn't reliable anyway, things like nesting which > allocates separate shadow stacks for each nested level for example. > I'll take a look. > I am a new comer to this discussion and I am learning. Just have some questions. Pardon me if they are obvious or if they have already been asked and answered. Doesn't Clang already have support for a shadow stack implementation for ARM64? We could take a look at how Clang does it. Will there not be a significant performance hit? May be, some of it can be mitigated by using a parallel shadow stack rather than a compact one. Are there any longjmp style situations in the kernel where the stack is unwound by several frames? In these cases, the shadow stack must be unwound accordingly. Madhavan > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 @ 2021-01-22 21:16 ` Madhavan T. Venkataraman 0 siblings, 0 replies; 106+ messages in thread From: Madhavan T. Venkataraman @ 2021-01-22 21:16 UTC (permalink / raw) To: Mark Brown, Josh Poimboeuf Cc: Mark Rutland, Michal Marek, Julien Thierry, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, Linux Kernel Mailing List, linux-efi, linux-hardening, live-patching, Will Deacon, Ard Biesheuvel, Linux ARM, Kees Cook On 1/22/21 11:43 AM, Mark Brown wrote: > On Thu, Jan 21, 2021 at 12:54:52PM -0600, Josh Poimboeuf wrote: > >> 2) The shadow stack idea sounds promising -- how hard would it be to >> make a prototype reliable unwinder? > > In theory it doesn't look too hard and I can't see a particular reason > not to try doing this - there's going to be edge cases but hopefully for > reliable stack trace they're all in areas where we would be happy to > just decide the stack isn't reliable anyway, things like nesting which > allocates separate shadow stacks for each nested level for example. > I'll take a look. > I am a new comer to this discussion and I am learning. Just have some questions. Pardon me if they are obvious or if they have already been asked and answered. Doesn't Clang already have support for a shadow stack implementation for ARM64? We could take a look at how Clang does it. Will there not be a significant performance hit? May be, some of it can be mitigated by using a parallel shadow stack rather than a compact one. Are there any longjmp style situations in the kernel where the stack is unwound by several frames? In these cases, the shadow stack must be unwound accordingly. Madhavan > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 2021-01-21 11:08 ` Ard Biesheuvel @ 2021-01-21 13:23 ` Julien Thierry -1 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-21 13:23 UTC (permalink / raw) To: Ard Biesheuvel Cc: Linux Kernel Mailing List, Linux ARM, Catalin Marinas, Will Deacon, Masahiro Yamada, Kees Cook, Michal Marek, Josh Poimboeuf, Peter Zijlstra, Mark Rutland, Mark Brown, linux-efi, linux-hardening On 1/21/21 12:08 PM, Ard Biesheuvel wrote: > On Thu, 21 Jan 2021 at 11:26, Julien Thierry <jthierry@redhat.com> wrote: >> >> Hi Ard, >> >> On 1/21/21 10:03 AM, Ard Biesheuvel wrote: >>> Hello Julien, >>> >>> On Wed, 20 Jan 2021 at 18:38, Julien Thierry <jthierry@redhat.com> wrote: >>>> >>>> Hi, >>>> >>>> This series enables objtool to start doing stack validation on arm64 >>>> kernel builds. >>> >>> Could we elaborate on this point, please? 'Stack validation' means >>> getting an accurate picture of all kernel code that will be executed >>> at some point in the future, due to the fact that there are stack >>> frames pointing to them. And this ability is essential in order to do >>> live patching safely? >>> >>> If this is the goal, I wonder whether this is the right approach for >>> arm64 (or for any other architecture, for that matter) >>> >>> Parsing/decoding the object code and even worse, relying on GCC >>> plugins to annotate some of the idioms as they are being generated, in >>> order to infer intent on the part of the compiler goes *way* beyond >>> what we should be comfortable with. The whole point of this exercise >>> is to guarantee that there are no false positives when it comes to >>> deciding whether the kernel is in a live patchable state, and I don't >>> see how we can ever provide such a guarantee when it is built on such >>> a fragile foundation. >>> >>> If we want to ensure that the stack contents are always an accurate >>> reflection of the real call stack, we should work with the toolchain >>> folks to identify issues that may interfere with this, and implement >>> controls over these behaviors that we can decide to use in the build. >>> In the past, I have already proposed adding a 'kernel' code model to >>> the AArch64 compiler that guarantees certain things, such as adrp/add >>> for symbol references, and no GOT indirections for position >>> independent code. Inhibiting optimizations that may impact our ability >>> to infer the real call stack from the stack contents is something we >>> might add here as well. >>> >> >> I'm not familiar with toolcahin code models, but would this approach be >> able to validate assembly code (either inline or in assembly files?) >> > > No, it would not. But those files are part of the code base, and can > be reviewed and audited. > That means that every actor maintaining their own stable version of the kernel have to do their own audit when they do backports (assuming the audit would be done for upstream) to be able to provide a safe livepatching feature in their kernel. >>> Another thing that occurred to me is that inferring which kernel code >>> is actually live in terms of pending function returns could be >>> inferred much more easily from a shadow call stack, which is a thing >>> we already implement for Clang builds. >>> >> >> I was not familiar with the shadow call stack. If I understand correctly >> that would be a stack of return addresses of function currently on the >> call stack, is that correct? >> >> That would indeed be a simpler approach, however I guess the >> instrumentation has a cost. Is the instrumentation also available with >> GCC? And is this instrumentation efficient enough to be suitable for >> production builds? >> > > I am not aware of any plans to enable this in GCC, but the Clang > implementation is definitely intended for production use (it's a CFI > feature for ROP/JOP mitigation) > I think most people interested in livepatching are using GCC built kernels, but I could be mistaken (althought in the long run, both compilers should be supported, and yes, I realize the objtool solution currently only would support GCC). I don't know how feasible it will be to get it into GCC if people decide to go with that. Also, now that I think about it, it will probably come with similar limitations as stackframes where the unwinder would need to know when/where the shadow call stack is unavailable for some reason and the stack trace is not reliable. (it might be a bit simpler to audit than stack frame setting and maybe have less limitations, but I guess there will still be cases where we can't rely on it) -- Julien Thierry ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 @ 2021-01-21 13:23 ` Julien Thierry 0 siblings, 0 replies; 106+ messages in thread From: Julien Thierry @ 2021-01-21 13:23 UTC (permalink / raw) To: Ard Biesheuvel Cc: Mark Rutland, linux-efi, Michal Marek, Kees Cook, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, Linux Kernel Mailing List, Mark Brown, linux-hardening, Josh Poimboeuf, Will Deacon, Linux ARM On 1/21/21 12:08 PM, Ard Biesheuvel wrote: > On Thu, 21 Jan 2021 at 11:26, Julien Thierry <jthierry@redhat.com> wrote: >> >> Hi Ard, >> >> On 1/21/21 10:03 AM, Ard Biesheuvel wrote: >>> Hello Julien, >>> >>> On Wed, 20 Jan 2021 at 18:38, Julien Thierry <jthierry@redhat.com> wrote: >>>> >>>> Hi, >>>> >>>> This series enables objtool to start doing stack validation on arm64 >>>> kernel builds. >>> >>> Could we elaborate on this point, please? 'Stack validation' means >>> getting an accurate picture of all kernel code that will be executed >>> at some point in the future, due to the fact that there are stack >>> frames pointing to them. And this ability is essential in order to do >>> live patching safely? >>> >>> If this is the goal, I wonder whether this is the right approach for >>> arm64 (or for any other architecture, for that matter) >>> >>> Parsing/decoding the object code and even worse, relying on GCC >>> plugins to annotate some of the idioms as they are being generated, in >>> order to infer intent on the part of the compiler goes *way* beyond >>> what we should be comfortable with. The whole point of this exercise >>> is to guarantee that there are no false positives when it comes to >>> deciding whether the kernel is in a live patchable state, and I don't >>> see how we can ever provide such a guarantee when it is built on such >>> a fragile foundation. >>> >>> If we want to ensure that the stack contents are always an accurate >>> reflection of the real call stack, we should work with the toolchain >>> folks to identify issues that may interfere with this, and implement >>> controls over these behaviors that we can decide to use in the build. >>> In the past, I have already proposed adding a 'kernel' code model to >>> the AArch64 compiler that guarantees certain things, such as adrp/add >>> for symbol references, and no GOT indirections for position >>> independent code. Inhibiting optimizations that may impact our ability >>> to infer the real call stack from the stack contents is something we >>> might add here as well. >>> >> >> I'm not familiar with toolcahin code models, but would this approach be >> able to validate assembly code (either inline or in assembly files?) >> > > No, it would not. But those files are part of the code base, and can > be reviewed and audited. > That means that every actor maintaining their own stable version of the kernel have to do their own audit when they do backports (assuming the audit would be done for upstream) to be able to provide a safe livepatching feature in their kernel. >>> Another thing that occurred to me is that inferring which kernel code >>> is actually live in terms of pending function returns could be >>> inferred much more easily from a shadow call stack, which is a thing >>> we already implement for Clang builds. >>> >> >> I was not familiar with the shadow call stack. If I understand correctly >> that would be a stack of return addresses of function currently on the >> call stack, is that correct? >> >> That would indeed be a simpler approach, however I guess the >> instrumentation has a cost. Is the instrumentation also available with >> GCC? And is this instrumentation efficient enough to be suitable for >> production builds? >> > > I am not aware of any plans to enable this in GCC, but the Clang > implementation is definitely intended for production use (it's a CFI > feature for ROP/JOP mitigation) > I think most people interested in livepatching are using GCC built kernels, but I could be mistaken (althought in the long run, both compilers should be supported, and yes, I realize the objtool solution currently only would support GCC). I don't know how feasible it will be to get it into GCC if people decide to go with that. Also, now that I think about it, it will probably come with similar limitations as stackframes where the unwinder would need to know when/where the shadow call stack is unavailable for some reason and the stack trace is not reliable. (it might be a bit simpler to audit than stack frame setting and maybe have less limitations, but I guess there will still be cases where we can't rely on it) -- Julien Thierry _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 2021-01-21 13:23 ` Julien Thierry @ 2021-01-21 14:23 ` Mark Brown -1 siblings, 0 replies; 106+ messages in thread From: Mark Brown @ 2021-01-21 14:23 UTC (permalink / raw) To: Julien Thierry Cc: Ard Biesheuvel, Linux Kernel Mailing List, Linux ARM, Catalin Marinas, Will Deacon, Masahiro Yamada, Kees Cook, Michal Marek, Josh Poimboeuf, Peter Zijlstra, Mark Rutland, linux-efi, linux-hardening [-- Attachment #1: Type: text/plain, Size: 669 bytes --] On Thu, Jan 21, 2021 at 02:23:53PM +0100, Julien Thierry wrote: > On 1/21/21 12:08 PM, Ard Biesheuvel wrote: > > I am not aware of any plans to enable this in GCC, but the Clang > > implementation is definitely intended for production use (it's a CFI > > feature for ROP/JOP mitigation) > I think most people interested in livepatching are using GCC built kernels, > but I could be mistaken (althought in the long run, both compilers should be > supported, and yes, I realize the objtool solution currently only would > support GCC). There definitely seem to be some users interested in both livepatch and clang built kernels so it might come up relatively quickly. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [RFC PATCH 00/17] objtool: add base support for arm64 @ 2021-01-21 14:23 ` Mark Brown 0 siblings, 0 replies; 106+ messages in thread From: Mark Brown @ 2021-01-21 14:23 UTC (permalink / raw) To: Julien Thierry Cc: Mark Rutland, Michal Marek, Kees Cook, Peter Zijlstra, Catalin Marinas, Masahiro Yamada, Linux Kernel Mailing List, linux-efi, linux-hardening, Josh Poimboeuf, Will Deacon, Ard Biesheuvel, Linux ARM [-- Attachment #1.1: Type: text/plain, Size: 669 bytes --] On Thu, Jan 21, 2021 at 02:23:53PM +0100, Julien Thierry wrote: > On 1/21/21 12:08 PM, Ard Biesheuvel wrote: > > I am not aware of any plans to enable this in GCC, but the Clang > > implementation is definitely intended for production use (it's a CFI > > feature for ROP/JOP mitigation) > I think most people interested in livepatching are using GCC built kernels, > but I could be mistaken (althought in the long run, both compilers should be > supported, and yes, I realize the objtool solution currently only would > support GCC). There definitely seem to be some users interested in both livepatch and clang built kernels so it might come up relatively quickly. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 106+ messages in thread
end of thread, other threads:[~2021-02-09 16:32 UTC | newest] Thread overview: 106+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-01-20 17:37 [RFC PATCH 00/17] objtool: add base support for arm64 Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 01/17] tools: Add some generic functions and headers Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 02/17] tools: arm64: Make aarch64 instruction decoder available to tools Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 03/17] tools: bug: Remove duplicate definition Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 04/17] objtool: arm64: Add base definition for arm64 backend Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 05/17] objtool: arm64: Decode add/sub instructions Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 06/17] objtool: arm64: Decode jump and call related instructions Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 07/17] objtool: arm64: Decode other system instructions Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 08/17] objtool: arm64: Decode load/store instructions Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 09/17] objtool: arm64: Decode LDR instructions Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 10/17] objtool: arm64: Accept padding in code sections Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 11/17] efi: libstub: Ignore relocations for .discard sections Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 12/17] gcc-plugins: objtool: Add plugin to detect switch table on arm64 Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-27 22:15 ` Nick Desaulniers 2021-01-27 22:15 ` Nick Desaulniers 2021-01-27 23:26 ` Josh Poimboeuf 2021-01-27 23:26 ` Josh Poimboeuf 2021-01-29 18:10 ` Nick Desaulniers 2021-01-29 18:10 ` Nick Desaulniers 2021-02-01 21:44 ` Josh Poimboeuf 2021-02-01 21:44 ` Josh Poimboeuf 2021-02-01 23:17 ` Nick Desaulniers 2021-02-01 23:17 ` Nick Desaulniers 2021-02-02 0:02 ` Josh Poimboeuf 2021-02-02 0:02 ` Josh Poimboeuf 2021-02-02 14:24 ` David Laight 2021-02-02 14:24 ` David Laight 2021-02-02 22:33 ` Nick Desaulniers 2021-02-02 22:33 ` Nick Desaulniers 2021-02-02 23:36 ` Josh Poimboeuf 2021-02-02 23:36 ` Josh Poimboeuf 2021-02-02 23:52 ` Nick Desaulniers 2021-02-02 23:52 ` Nick Desaulniers 2021-02-02 8:57 ` Julien Thierry 2021-02-02 8:57 ` Julien Thierry 2021-02-02 23:01 ` Nick Desaulniers 2021-02-02 23:01 ` Nick Desaulniers 2021-02-03 0:14 ` Josh Poimboeuf 2021-02-03 0:14 ` Josh Poimboeuf 2021-02-03 11:57 ` Peter Zijlstra 2021-02-03 11:57 ` Peter Zijlstra 2021-02-03 13:04 ` Mark Brown 2021-02-03 13:04 ` Mark Brown 2021-02-03 13:58 ` Mark Rutland 2021-02-03 13:58 ` Mark Rutland 2021-02-03 8:11 ` Julien Thierry 2021-02-03 8:11 ` Julien Thierry 2021-02-09 16:30 ` Daniel Kiss 2021-02-09 16:30 ` Daniel Kiss 2021-01-20 17:37 ` [RFC PATCH 13/17] objtool: arm64: Implement functions to add switch tables alternatives Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 14/17] objtool: arm64: Cache section with switch table information Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 15/17] objtool: arm64: Handle supported relocations in alternatives Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:37 ` [RFC PATCH 16/17] objtool: arm64: Ignore replacement section for alternative callback Julien Thierry 2021-01-20 17:37 ` Julien Thierry 2021-01-20 17:38 ` [RFC PATCH 17/17] objtool: arm64: Enable stack validation for arm64 Julien Thierry 2021-01-20 17:38 ` Julien Thierry 2021-01-21 5:39 ` kernel test robot 2021-01-21 9:03 ` [RFC PATCH 00/17] objtool: add base support " Ard Biesheuvel 2021-01-21 9:03 ` Ard Biesheuvel 2021-01-21 10:26 ` Julien Thierry 2021-01-21 10:26 ` Julien Thierry 2021-01-21 11:08 ` Ard Biesheuvel 2021-01-21 11:08 ` Ard Biesheuvel 2021-01-21 11:23 ` Peter Zijlstra 2021-01-21 11:23 ` Peter Zijlstra 2021-01-21 11:48 ` Ard Biesheuvel 2021-01-21 11:48 ` Ard Biesheuvel 2021-01-21 18:54 ` Josh Poimboeuf 2021-01-21 18:54 ` Josh Poimboeuf 2021-01-22 17:43 ` Mark Brown 2021-01-22 17:43 ` Mark Brown 2021-01-22 17:54 ` Ard Biesheuvel 2021-01-22 17:54 ` Ard Biesheuvel 2021-01-28 22:10 ` Madhavan T. Venkataraman 2021-01-28 22:10 ` Madhavan T. Venkataraman 2021-01-29 15:47 ` Mark Brown 2021-01-22 21:15 ` Madhavan T. Venkataraman 2021-01-22 21:15 ` Madhavan T. Venkataraman 2021-01-22 21:43 ` Ard Biesheuvel 2021-01-22 21:43 ` Ard Biesheuvel 2021-01-22 21:44 ` Madhavan T. Venkataraman 2021-01-22 21:44 ` Madhavan T. Venkataraman 2021-01-25 21:19 ` Josh Poimboeuf 2021-01-25 21:19 ` Josh Poimboeuf 2021-01-22 21:16 ` Madhavan T. Venkataraman 2021-01-22 21:16 ` Madhavan T. Venkataraman 2021-01-21 13:23 ` Julien Thierry 2021-01-21 13:23 ` Julien Thierry 2021-01-21 14:23 ` Mark Brown 2021-01-21 14:23 ` Mark Brown
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.