All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC PATCH v2 00/21] KCFI support
@ 2022-05-13 20:21 ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

KCFI is a proposed forward-edge control-flow integrity scheme for
Clang, which is more suitable for kernel use than the existing CFI
scheme used by CONFIG_CFI_CLANG. KCFI doesn't require LTO, doesn't
alter function references to point to a jump table, and won't break
function address equality. The latest LLVM patch is here:

  https://reviews.llvm.org/D119296

This RFC series replaces the current arm64 CFI implementation with
KCFI and adds support for x86_64.

KCFI requires assembly functions that are indirectly called from C
code to be annotated with type identifiers. As type information is
only available in C, the compiler emits expected type identifiers into
the symbol table, so they can be referenced from assembly without
having to hardcode type hashes. Patch 7 adds helper macros for
annotating functions, and patches 9 and 17 add annotations.

In case of a type mismatch, KCFI always traps. To support error
handling, the compiler generates a .kcfi_traps section for x86_64,
which contains the locations of each trap, and for arm64, encodes
the necessary register information to the ESR. Patches 10 and 20 add
arch-specific error handlers.

To test this series, you'll need to compile your own Clang toolchain
with the patches linked above. You can also find the complete source
tree here:

  https://github.com/samitolvanen/llvm-project/commits/kcfi-rfc-v2

This series is also available in GitHub:

  https://github.com/samitolvanen/linux/commits/kcfi-rfc-v2

Sami Tolvanen (21):
  efi/libstub: Filter out CC_FLAGS_CFI
  arm64/vdso: Filter out CC_FLAGS_CFI
  kallsyms: Ignore __kcfi_typeid_
  cfi: Remove CONFIG_CFI_CLANG_SHADOW
  cfi: Drop __CFI_ADDRESSABLE
  cfi: Switch to -fsanitize=kcfi
  cfi: Add type helper macros
  psci: Fix the function type for psci_initcall_t
  arm64: Add types to indirect called assembly functions
  arm64: Add CFI error handling
  arm64: Drop unneeded __nocfi attributes
  treewide: Drop function_nocfi
  treewide: Drop WARN_ON_FUNCTION_MISMATCH
  treewide: Drop __cficanonical
  objtool: Don't warn about __cfi_ preambles falling through
  x86/tools/relocs: Ignore __kcfi_typeid_ relocations
  x86: Add types to indirectly called assembly functions
  x86/purgatory: Disable CFI
  x86/vdso: Disable CFI
  x86: Add support for CONFIG_CFI_CLANG
  init: Drop __nocfi from __init

 Makefile                                  |  13 +-
 arch/Kconfig                              |  21 +-
 arch/arm64/crypto/ghash-ce-core.S         |   5 +-
 arch/arm64/crypto/sm3-ce-core.S           |   3 +-
 arch/arm64/include/asm/brk-imm.h          |   6 +
 arch/arm64/include/asm/compiler.h         |  16 -
 arch/arm64/include/asm/ftrace.h           |   2 +-
 arch/arm64/include/asm/mmu_context.h      |   4 +-
 arch/arm64/kernel/acpi_parking_protocol.c |   2 +-
 arch/arm64/kernel/alternative.c           |   2 +-
 arch/arm64/kernel/cpu-reset.S             |   5 +-
 arch/arm64/kernel/cpufeature.c            |   4 +-
 arch/arm64/kernel/ftrace.c                |   2 +-
 arch/arm64/kernel/machine_kexec.c         |   2 +-
 arch/arm64/kernel/psci.c                  |   2 +-
 arch/arm64/kernel/smp_spin_table.c        |   2 +-
 arch/arm64/kernel/traps.c                 |  46 ++-
 arch/arm64/kernel/vdso/Makefile           |   3 +-
 arch/arm64/mm/proc.S                      |   5 +-
 arch/x86/Kconfig                          |   2 +
 arch/x86/crypto/blowfish-x86_64-asm_64.S  |   5 +-
 arch/x86/entry/vdso/Makefile              |   3 +-
 arch/x86/include/asm/linkage.h            |  12 +
 arch/x86/kernel/traps.c                   |  60 +++-
 arch/x86/lib/memcpy_64.S                  |   3 +-
 arch/x86/purgatory/Makefile               |   4 +
 arch/x86/tools/relocs.c                   |   1 +
 drivers/firmware/efi/libstub/Makefile     |   2 +
 drivers/firmware/psci/psci.c              |   6 +-
 drivers/misc/lkdtm/usercopy.c             |   2 +-
 include/asm-generic/bug.h                 |  16 -
 include/asm-generic/vmlinux.lds.h         |  37 +--
 include/linux/cfi.h                       |  65 ++--
 include/linux/cfi_types.h                 |  57 ++++
 include/linux/compiler-clang.h            |   6 +-
 include/linux/compiler.h                  |  16 +-
 include/linux/compiler_types.h            |   4 -
 include/linux/init.h                      |   6 +-
 include/linux/module.h                    |  10 +-
 include/linux/pci.h                       |   4 +-
 kernel/cfi.c                              | 343 ++++------------------
 kernel/kthread.c                          |   3 +-
 kernel/module.c                           |  49 +---
 kernel/workqueue.c                        |   2 +-
 scripts/kallsyms.c                        |   1 +
 scripts/module.lds.S                      |  23 +-
 tools/objtool/check.c                     |   4 +
 47 files changed, 357 insertions(+), 534 deletions(-)
 create mode 100644 include/linux/cfi_types.h

-- 
2.36.0.550.gb090851708-goog


^ permalink raw reply	[flat|nested] 174+ messages in thread

* [RFC PATCH v2 00/21] KCFI support
@ 2022-05-13 20:21 ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

KCFI is a proposed forward-edge control-flow integrity scheme for
Clang, which is more suitable for kernel use than the existing CFI
scheme used by CONFIG_CFI_CLANG. KCFI doesn't require LTO, doesn't
alter function references to point to a jump table, and won't break
function address equality. The latest LLVM patch is here:

  https://reviews.llvm.org/D119296

This RFC series replaces the current arm64 CFI implementation with
KCFI and adds support for x86_64.

KCFI requires assembly functions that are indirectly called from C
code to be annotated with type identifiers. As type information is
only available in C, the compiler emits expected type identifiers into
the symbol table, so they can be referenced from assembly without
having to hardcode type hashes. Patch 7 adds helper macros for
annotating functions, and patches 9 and 17 add annotations.

In case of a type mismatch, KCFI always traps. To support error
handling, the compiler generates a .kcfi_traps section for x86_64,
which contains the locations of each trap, and for arm64, encodes
the necessary register information to the ESR. Patches 10 and 20 add
arch-specific error handlers.

To test this series, you'll need to compile your own Clang toolchain
with the patches linked above. You can also find the complete source
tree here:

  https://github.com/samitolvanen/llvm-project/commits/kcfi-rfc-v2

This series is also available in GitHub:

  https://github.com/samitolvanen/linux/commits/kcfi-rfc-v2

Sami Tolvanen (21):
  efi/libstub: Filter out CC_FLAGS_CFI
  arm64/vdso: Filter out CC_FLAGS_CFI
  kallsyms: Ignore __kcfi_typeid_
  cfi: Remove CONFIG_CFI_CLANG_SHADOW
  cfi: Drop __CFI_ADDRESSABLE
  cfi: Switch to -fsanitize=kcfi
  cfi: Add type helper macros
  psci: Fix the function type for psci_initcall_t
  arm64: Add types to indirect called assembly functions
  arm64: Add CFI error handling
  arm64: Drop unneeded __nocfi attributes
  treewide: Drop function_nocfi
  treewide: Drop WARN_ON_FUNCTION_MISMATCH
  treewide: Drop __cficanonical
  objtool: Don't warn about __cfi_ preambles falling through
  x86/tools/relocs: Ignore __kcfi_typeid_ relocations
  x86: Add types to indirectly called assembly functions
  x86/purgatory: Disable CFI
  x86/vdso: Disable CFI
  x86: Add support for CONFIG_CFI_CLANG
  init: Drop __nocfi from __init

 Makefile                                  |  13 +-
 arch/Kconfig                              |  21 +-
 arch/arm64/crypto/ghash-ce-core.S         |   5 +-
 arch/arm64/crypto/sm3-ce-core.S           |   3 +-
 arch/arm64/include/asm/brk-imm.h          |   6 +
 arch/arm64/include/asm/compiler.h         |  16 -
 arch/arm64/include/asm/ftrace.h           |   2 +-
 arch/arm64/include/asm/mmu_context.h      |   4 +-
 arch/arm64/kernel/acpi_parking_protocol.c |   2 +-
 arch/arm64/kernel/alternative.c           |   2 +-
 arch/arm64/kernel/cpu-reset.S             |   5 +-
 arch/arm64/kernel/cpufeature.c            |   4 +-
 arch/arm64/kernel/ftrace.c                |   2 +-
 arch/arm64/kernel/machine_kexec.c         |   2 +-
 arch/arm64/kernel/psci.c                  |   2 +-
 arch/arm64/kernel/smp_spin_table.c        |   2 +-
 arch/arm64/kernel/traps.c                 |  46 ++-
 arch/arm64/kernel/vdso/Makefile           |   3 +-
 arch/arm64/mm/proc.S                      |   5 +-
 arch/x86/Kconfig                          |   2 +
 arch/x86/crypto/blowfish-x86_64-asm_64.S  |   5 +-
 arch/x86/entry/vdso/Makefile              |   3 +-
 arch/x86/include/asm/linkage.h            |  12 +
 arch/x86/kernel/traps.c                   |  60 +++-
 arch/x86/lib/memcpy_64.S                  |   3 +-
 arch/x86/purgatory/Makefile               |   4 +
 arch/x86/tools/relocs.c                   |   1 +
 drivers/firmware/efi/libstub/Makefile     |   2 +
 drivers/firmware/psci/psci.c              |   6 +-
 drivers/misc/lkdtm/usercopy.c             |   2 +-
 include/asm-generic/bug.h                 |  16 -
 include/asm-generic/vmlinux.lds.h         |  37 +--
 include/linux/cfi.h                       |  65 ++--
 include/linux/cfi_types.h                 |  57 ++++
 include/linux/compiler-clang.h            |   6 +-
 include/linux/compiler.h                  |  16 +-
 include/linux/compiler_types.h            |   4 -
 include/linux/init.h                      |   6 +-
 include/linux/module.h                    |  10 +-
 include/linux/pci.h                       |   4 +-
 kernel/cfi.c                              | 343 ++++------------------
 kernel/kthread.c                          |   3 +-
 kernel/module.c                           |  49 +---
 kernel/workqueue.c                        |   2 +-
 scripts/kallsyms.c                        |   1 +
 scripts/module.lds.S                      |  23 +-
 tools/objtool/check.c                     |   4 +
 47 files changed, 357 insertions(+), 534 deletions(-)
 create mode 100644 include/linux/cfi_types.h

-- 
2.36.0.550.gb090851708-goog


_______________________________________________
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] 174+ messages in thread

* [RFC PATCH v2 01/21] efi/libstub: Filter out CC_FLAGS_CFI
  2022-05-13 20:21 ` Sami Tolvanen
@ 2022-05-13 20:21   ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

Explicitly filter out CC_FLAGS_CFI in preparation for the flags being
removed from CC_FLAGS_LTO.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 drivers/firmware/efi/libstub/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
index d0537573501e..234fb2910622 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -39,6 +39,8 @@ KBUILD_CFLAGS			:= $(cflags-y) -Os -DDISABLE_BRANCH_PROFILING \
 
 # remove SCS flags from all objects in this directory
 KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_SCS), $(KBUILD_CFLAGS))
+# disable CFI
+KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_CFI), $(KBUILD_CFLAGS))
 # disable LTO
 KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_LTO), $(KBUILD_CFLAGS))
 
-- 
2.36.0.550.gb090851708-goog


^ permalink raw reply	[flat|nested] 174+ messages in thread

* [RFC PATCH v2 01/21] efi/libstub: Filter out CC_FLAGS_CFI
@ 2022-05-13 20:21   ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

Explicitly filter out CC_FLAGS_CFI in preparation for the flags being
removed from CC_FLAGS_LTO.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 drivers/firmware/efi/libstub/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
index d0537573501e..234fb2910622 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -39,6 +39,8 @@ KBUILD_CFLAGS			:= $(cflags-y) -Os -DDISABLE_BRANCH_PROFILING \
 
 # remove SCS flags from all objects in this directory
 KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_SCS), $(KBUILD_CFLAGS))
+# disable CFI
+KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_CFI), $(KBUILD_CFLAGS))
 # disable LTO
 KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_LTO), $(KBUILD_CFLAGS))
 
-- 
2.36.0.550.gb090851708-goog


_______________________________________________
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] 174+ messages in thread

* [RFC PATCH v2 02/21] arm64/vdso: Filter out CC_FLAGS_CFI
  2022-05-13 20:21 ` Sami Tolvanen
@ 2022-05-13 20:21   ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

Explicitly filter out CC_FLAGS_CFI in preparation for the flags being
removed from CC_FLAGS_LTO.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/arm64/kernel/vdso/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
index 172452f79e46..6c26e0a76a06 100644
--- a/arch/arm64/kernel/vdso/Makefile
+++ b/arch/arm64/kernel/vdso/Makefile
@@ -33,7 +33,8 @@ ccflags-y += -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO
 # the CFLAGS of vgettimeofday.c to make possible to build the
 # kernel with CONFIG_WERROR enabled.
 CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os $(CC_FLAGS_SCS) $(GCC_PLUGINS_CFLAGS) \
-				$(CC_FLAGS_LTO) -Wmissing-prototypes -Wmissing-declarations
+				$(CC_FLAGS_LTO) $(CC_FLAGS_CFI) \
+				-Wmissing-prototypes -Wmissing-declarations
 KASAN_SANITIZE			:= n
 KCSAN_SANITIZE			:= n
 UBSAN_SANITIZE			:= n
-- 
2.36.0.550.gb090851708-goog


^ permalink raw reply	[flat|nested] 174+ messages in thread

* [RFC PATCH v2 02/21] arm64/vdso: Filter out CC_FLAGS_CFI
@ 2022-05-13 20:21   ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

Explicitly filter out CC_FLAGS_CFI in preparation for the flags being
removed from CC_FLAGS_LTO.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/arm64/kernel/vdso/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
index 172452f79e46..6c26e0a76a06 100644
--- a/arch/arm64/kernel/vdso/Makefile
+++ b/arch/arm64/kernel/vdso/Makefile
@@ -33,7 +33,8 @@ ccflags-y += -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO
 # the CFLAGS of vgettimeofday.c to make possible to build the
 # kernel with CONFIG_WERROR enabled.
 CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os $(CC_FLAGS_SCS) $(GCC_PLUGINS_CFLAGS) \
-				$(CC_FLAGS_LTO) -Wmissing-prototypes -Wmissing-declarations
+				$(CC_FLAGS_LTO) $(CC_FLAGS_CFI) \
+				-Wmissing-prototypes -Wmissing-declarations
 KASAN_SANITIZE			:= n
 KCSAN_SANITIZE			:= n
 UBSAN_SANITIZE			:= n
-- 
2.36.0.550.gb090851708-goog


_______________________________________________
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] 174+ messages in thread

* [RFC PATCH v2 03/21] kallsyms: Ignore __kcfi_typeid_
  2022-05-13 20:21 ` Sami Tolvanen
@ 2022-05-13 20:21   ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

The compiler generates CFI type identifier symbols for annotating
assembly functions at link time. Ignore them in kallsyms.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 scripts/kallsyms.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index 8caabddf817c..eebd02e4b832 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -118,6 +118,7 @@ static bool is_ignored_symbol(const char *name, char type)
 		"__ThumbV7PILongThunk_",
 		"__LA25Thunk_",		/* mips lld */
 		"__microLA25Thunk_",
+		"__kcfi_typeid_",	/* CFI type identifiers */
 		NULL
 	};
 
-- 
2.36.0.550.gb090851708-goog


^ permalink raw reply	[flat|nested] 174+ messages in thread

* [RFC PATCH v2 03/21] kallsyms: Ignore __kcfi_typeid_
@ 2022-05-13 20:21   ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

The compiler generates CFI type identifier symbols for annotating
assembly functions at link time. Ignore them in kallsyms.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 scripts/kallsyms.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index 8caabddf817c..eebd02e4b832 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -118,6 +118,7 @@ static bool is_ignored_symbol(const char *name, char type)
 		"__ThumbV7PILongThunk_",
 		"__LA25Thunk_",		/* mips lld */
 		"__microLA25Thunk_",
+		"__kcfi_typeid_",	/* CFI type identifiers */
 		NULL
 	};
 
-- 
2.36.0.550.gb090851708-goog


_______________________________________________
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] 174+ messages in thread

* [RFC PATCH v2 04/21] cfi: Remove CONFIG_CFI_CLANG_SHADOW
  2022-05-13 20:21 ` Sami Tolvanen
@ 2022-05-13 20:21   ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

In preparation to switching to -fsanitize=kcfi, remove support for the
CFI module shadow that will no longer be needed.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/Kconfig        |  10 --
 include/linux/cfi.h |  12 ---
 kernel/cfi.c        | 237 +-------------------------------------------
 kernel/module.c     |  15 ---
 4 files changed, 1 insertion(+), 273 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index 31c4fdc4a4ba..625db6376726 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -739,16 +739,6 @@ config CFI_CLANG
 
 	    https://clang.llvm.org/docs/ControlFlowIntegrity.html
 
-config CFI_CLANG_SHADOW
-	bool "Use CFI shadow to speed up cross-module checks"
-	default y
-	depends on CFI_CLANG && MODULES
-	help
-	  If you select this option, the kernel builds a fast look-up table of
-	  CFI check functions in loaded modules to reduce performance overhead.
-
-	  If unsure, say Y.
-
 config CFI_PERMISSIVE
 	bool "Use CFI in permissive mode"
 	depends on CFI_CLANG
diff --git a/include/linux/cfi.h b/include/linux/cfi.h
index c6dfc1ed0626..4ab51c067007 100644
--- a/include/linux/cfi.h
+++ b/include/linux/cfi.h
@@ -20,18 +20,6 @@ extern void __cfi_check(uint64_t id, void *ptr, void *diag);
 #define __CFI_ADDRESSABLE(fn, __attr) \
 	const void *__cfi_jt_ ## fn __visible __attr = (void *)&fn
 
-#ifdef CONFIG_CFI_CLANG_SHADOW
-
-extern void cfi_module_add(struct module *mod, unsigned long base_addr);
-extern void cfi_module_remove(struct module *mod, unsigned long base_addr);
-
-#else
-
-static inline void cfi_module_add(struct module *mod, unsigned long base_addr) {}
-static inline void cfi_module_remove(struct module *mod, unsigned long base_addr) {}
-
-#endif /* CONFIG_CFI_CLANG_SHADOW */
-
 #else /* !CONFIG_CFI_CLANG */
 
 #ifdef CONFIG_X86_KERNEL_IBT
diff --git a/kernel/cfi.c b/kernel/cfi.c
index 9594cfd1cf2c..2cc0d01ea980 100644
--- a/kernel/cfi.c
+++ b/kernel/cfi.c
@@ -32,237 +32,6 @@ static inline void handle_cfi_failure(void *ptr)
 }
 
 #ifdef CONFIG_MODULES
-#ifdef CONFIG_CFI_CLANG_SHADOW
-/*
- * Index type. A 16-bit index can address at most (2^16)-2 pages (taking
- * into account SHADOW_INVALID), i.e. ~256M with 4k pages.
- */
-typedef u16 shadow_t;
-#define SHADOW_INVALID		((shadow_t)~0UL)
-
-struct cfi_shadow {
-	/* Page index for the beginning of the shadow */
-	unsigned long base;
-	/* An array of __cfi_check locations (as indices to the shadow) */
-	shadow_t shadow[1];
-} __packed;
-
-/*
- * The shadow covers ~128M from the beginning of the module region. If
- * the region is larger, we fall back to __module_address for the rest.
- */
-#define __SHADOW_RANGE		(_UL(SZ_128M) >> PAGE_SHIFT)
-
-/* The in-memory size of struct cfi_shadow, always at least one page */
-#define __SHADOW_PAGES		((__SHADOW_RANGE * sizeof(shadow_t)) >> PAGE_SHIFT)
-#define SHADOW_PAGES		max(1UL, __SHADOW_PAGES)
-#define SHADOW_SIZE		(SHADOW_PAGES << PAGE_SHIFT)
-
-/* The actual size of the shadow array, minus metadata */
-#define SHADOW_ARR_SIZE		(SHADOW_SIZE - offsetof(struct cfi_shadow, shadow))
-#define SHADOW_ARR_SLOTS	(SHADOW_ARR_SIZE / sizeof(shadow_t))
-
-static DEFINE_MUTEX(shadow_update_lock);
-static struct cfi_shadow __rcu *cfi_shadow __read_mostly;
-
-/* Returns the index in the shadow for the given address */
-static inline int ptr_to_shadow(const struct cfi_shadow *s, unsigned long ptr)
-{
-	unsigned long index;
-	unsigned long page = ptr >> PAGE_SHIFT;
-
-	if (unlikely(page < s->base))
-		return -1; /* Outside of module area */
-
-	index = page - s->base;
-
-	if (index >= SHADOW_ARR_SLOTS)
-		return -1; /* Cannot be addressed with shadow */
-
-	return (int)index;
-}
-
-/* Returns the page address for an index in the shadow */
-static inline unsigned long shadow_to_ptr(const struct cfi_shadow *s,
-	int index)
-{
-	if (unlikely(index < 0 || index >= SHADOW_ARR_SLOTS))
-		return 0;
-
-	return (s->base + index) << PAGE_SHIFT;
-}
-
-/* Returns the __cfi_check function address for the given shadow location */
-static inline unsigned long shadow_to_check_fn(const struct cfi_shadow *s,
-	int index)
-{
-	if (unlikely(index < 0 || index >= SHADOW_ARR_SLOTS))
-		return 0;
-
-	if (unlikely(s->shadow[index] == SHADOW_INVALID))
-		return 0;
-
-	/* __cfi_check is always page aligned */
-	return (s->base + s->shadow[index]) << PAGE_SHIFT;
-}
-
-static void prepare_next_shadow(const struct cfi_shadow __rcu *prev,
-		struct cfi_shadow *next)
-{
-	int i, index, check;
-
-	/* Mark everything invalid */
-	memset(next->shadow, 0xFF, SHADOW_ARR_SIZE);
-
-	if (!prev)
-		return; /* No previous shadow */
-
-	/* If the base address didn't change, an update is not needed */
-	if (prev->base == next->base) {
-		memcpy(next->shadow, prev->shadow, SHADOW_ARR_SIZE);
-		return;
-	}
-
-	/* Convert the previous shadow to the new address range */
-	for (i = 0; i < SHADOW_ARR_SLOTS; ++i) {
-		if (prev->shadow[i] == SHADOW_INVALID)
-			continue;
-
-		index = ptr_to_shadow(next, shadow_to_ptr(prev, i));
-		if (index < 0)
-			continue;
-
-		check = ptr_to_shadow(next,
-				shadow_to_check_fn(prev, prev->shadow[i]));
-		if (check < 0)
-			continue;
-
-		next->shadow[index] = (shadow_t)check;
-	}
-}
-
-static void add_module_to_shadow(struct cfi_shadow *s, struct module *mod,
-			unsigned long min_addr, unsigned long max_addr)
-{
-	int check_index;
-	unsigned long check = (unsigned long)mod->cfi_check;
-	unsigned long ptr;
-
-	if (unlikely(!PAGE_ALIGNED(check))) {
-		pr_warn("cfi: not using shadow for module %s\n", mod->name);
-		return;
-	}
-
-	check_index = ptr_to_shadow(s, check);
-	if (check_index < 0)
-		return; /* Module not addressable with shadow */
-
-	/* For each page, store the check function index in the shadow */
-	for (ptr = min_addr; ptr <= max_addr; ptr += PAGE_SIZE) {
-		int index = ptr_to_shadow(s, ptr);
-
-		if (index >= 0) {
-			/* Each page must only contain one module */
-			WARN_ON_ONCE(s->shadow[index] != SHADOW_INVALID);
-			s->shadow[index] = (shadow_t)check_index;
-		}
-	}
-}
-
-static void remove_module_from_shadow(struct cfi_shadow *s, struct module *mod,
-		unsigned long min_addr, unsigned long max_addr)
-{
-	unsigned long ptr;
-
-	for (ptr = min_addr; ptr <= max_addr; ptr += PAGE_SIZE) {
-		int index = ptr_to_shadow(s, ptr);
-
-		if (index >= 0)
-			s->shadow[index] = SHADOW_INVALID;
-	}
-}
-
-typedef void (*update_shadow_fn)(struct cfi_shadow *, struct module *,
-			unsigned long min_addr, unsigned long max_addr);
-
-static void update_shadow(struct module *mod, unsigned long base_addr,
-		update_shadow_fn fn)
-{
-	struct cfi_shadow *prev;
-	struct cfi_shadow *next;
-	unsigned long min_addr, max_addr;
-
-	next = vmalloc(SHADOW_SIZE);
-
-	mutex_lock(&shadow_update_lock);
-	prev = rcu_dereference_protected(cfi_shadow,
-					 mutex_is_locked(&shadow_update_lock));
-
-	if (next) {
-		next->base = base_addr >> PAGE_SHIFT;
-		prepare_next_shadow(prev, next);
-
-		min_addr = (unsigned long)mod->core_layout.base;
-		max_addr = min_addr + mod->core_layout.text_size;
-		fn(next, mod, min_addr & PAGE_MASK, max_addr & PAGE_MASK);
-
-		set_memory_ro((unsigned long)next, SHADOW_PAGES);
-	}
-
-	rcu_assign_pointer(cfi_shadow, next);
-	mutex_unlock(&shadow_update_lock);
-	synchronize_rcu();
-
-	if (prev) {
-		set_memory_rw((unsigned long)prev, SHADOW_PAGES);
-		vfree(prev);
-	}
-}
-
-void cfi_module_add(struct module *mod, unsigned long base_addr)
-{
-	update_shadow(mod, base_addr, add_module_to_shadow);
-}
-
-void cfi_module_remove(struct module *mod, unsigned long base_addr)
-{
-	update_shadow(mod, base_addr, remove_module_from_shadow);
-}
-
-static inline cfi_check_fn ptr_to_check_fn(const struct cfi_shadow __rcu *s,
-	unsigned long ptr)
-{
-	int index;
-
-	if (unlikely(!s))
-		return NULL; /* No shadow available */
-
-	index = ptr_to_shadow(s, ptr);
-	if (index < 0)
-		return NULL; /* Cannot be addressed with shadow */
-
-	return (cfi_check_fn)shadow_to_check_fn(s, index);
-}
-
-static inline cfi_check_fn find_shadow_check_fn(unsigned long ptr)
-{
-	cfi_check_fn fn;
-
-	rcu_read_lock_sched_notrace();
-	fn = ptr_to_check_fn(rcu_dereference_sched(cfi_shadow), ptr);
-	rcu_read_unlock_sched_notrace();
-
-	return fn;
-}
-
-#else /* !CONFIG_CFI_CLANG_SHADOW */
-
-static inline cfi_check_fn find_shadow_check_fn(unsigned long ptr)
-{
-	return NULL;
-}
-
-#endif /* CONFIG_CFI_CLANG_SHADOW */
 
 static inline cfi_check_fn find_module_check_fn(unsigned long ptr)
 {
@@ -291,11 +60,7 @@ static inline cfi_check_fn find_check_fn(unsigned long ptr)
 	 * up if necessary.
 	 */
 	RCU_NONIDLE({
-		if (IS_ENABLED(CONFIG_CFI_CLANG_SHADOW))
-			fn = find_shadow_check_fn(ptr);
-
-		if (!fn)
-			fn = find_module_check_fn(ptr);
+		fn = find_module_check_fn(ptr);
 	});
 
 	return fn;
diff --git a/kernel/module.c b/kernel/module.c
index 6cea788fd965..296fe02323e9 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2151,8 +2151,6 @@ void __weak module_arch_freeing_init(struct module *mod)
 {
 }
 
-static void cfi_cleanup(struct module *mod);
-
 /* Free a module, remove from lists, etc. */
 static void free_module(struct module *mod)
 {
@@ -2194,9 +2192,6 @@ static void free_module(struct module *mod)
 	synchronize_rcu();
 	mutex_unlock(&module_mutex);
 
-	/* Clean up CFI for the module. */
-	cfi_cleanup(mod);
-
 	/* This may be empty, but that's OK */
 	module_arch_freeing_init(mod);
 	module_memfree(mod->init_layout.base);
@@ -4141,7 +4136,6 @@ static int load_module(struct load_info *info, const char __user *uargs,
 	synchronize_rcu();
 	kfree(mod->args);
  free_arch_cleanup:
-	cfi_cleanup(mod);
 	module_arch_cleanup(mod);
  free_modinfo:
 	free_modinfo(mod);
@@ -4530,15 +4524,6 @@ static void cfi_init(struct module *mod)
 	if (exit)
 		mod->exit = *exit;
 #endif
-
-	cfi_module_add(mod, module_addr_min);
-#endif
-}
-
-static void cfi_cleanup(struct module *mod)
-{
-#ifdef CONFIG_CFI_CLANG
-	cfi_module_remove(mod, module_addr_min);
 #endif
 }
 
-- 
2.36.0.550.gb090851708-goog


^ permalink raw reply	[flat|nested] 174+ messages in thread

* [RFC PATCH v2 04/21] cfi: Remove CONFIG_CFI_CLANG_SHADOW
@ 2022-05-13 20:21   ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

In preparation to switching to -fsanitize=kcfi, remove support for the
CFI module shadow that will no longer be needed.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/Kconfig        |  10 --
 include/linux/cfi.h |  12 ---
 kernel/cfi.c        | 237 +-------------------------------------------
 kernel/module.c     |  15 ---
 4 files changed, 1 insertion(+), 273 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index 31c4fdc4a4ba..625db6376726 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -739,16 +739,6 @@ config CFI_CLANG
 
 	    https://clang.llvm.org/docs/ControlFlowIntegrity.html
 
-config CFI_CLANG_SHADOW
-	bool "Use CFI shadow to speed up cross-module checks"
-	default y
-	depends on CFI_CLANG && MODULES
-	help
-	  If you select this option, the kernel builds a fast look-up table of
-	  CFI check functions in loaded modules to reduce performance overhead.
-
-	  If unsure, say Y.
-
 config CFI_PERMISSIVE
 	bool "Use CFI in permissive mode"
 	depends on CFI_CLANG
diff --git a/include/linux/cfi.h b/include/linux/cfi.h
index c6dfc1ed0626..4ab51c067007 100644
--- a/include/linux/cfi.h
+++ b/include/linux/cfi.h
@@ -20,18 +20,6 @@ extern void __cfi_check(uint64_t id, void *ptr, void *diag);
 #define __CFI_ADDRESSABLE(fn, __attr) \
 	const void *__cfi_jt_ ## fn __visible __attr = (void *)&fn
 
-#ifdef CONFIG_CFI_CLANG_SHADOW
-
-extern void cfi_module_add(struct module *mod, unsigned long base_addr);
-extern void cfi_module_remove(struct module *mod, unsigned long base_addr);
-
-#else
-
-static inline void cfi_module_add(struct module *mod, unsigned long base_addr) {}
-static inline void cfi_module_remove(struct module *mod, unsigned long base_addr) {}
-
-#endif /* CONFIG_CFI_CLANG_SHADOW */
-
 #else /* !CONFIG_CFI_CLANG */
 
 #ifdef CONFIG_X86_KERNEL_IBT
diff --git a/kernel/cfi.c b/kernel/cfi.c
index 9594cfd1cf2c..2cc0d01ea980 100644
--- a/kernel/cfi.c
+++ b/kernel/cfi.c
@@ -32,237 +32,6 @@ static inline void handle_cfi_failure(void *ptr)
 }
 
 #ifdef CONFIG_MODULES
-#ifdef CONFIG_CFI_CLANG_SHADOW
-/*
- * Index type. A 16-bit index can address at most (2^16)-2 pages (taking
- * into account SHADOW_INVALID), i.e. ~256M with 4k pages.
- */
-typedef u16 shadow_t;
-#define SHADOW_INVALID		((shadow_t)~0UL)
-
-struct cfi_shadow {
-	/* Page index for the beginning of the shadow */
-	unsigned long base;
-	/* An array of __cfi_check locations (as indices to the shadow) */
-	shadow_t shadow[1];
-} __packed;
-
-/*
- * The shadow covers ~128M from the beginning of the module region. If
- * the region is larger, we fall back to __module_address for the rest.
- */
-#define __SHADOW_RANGE		(_UL(SZ_128M) >> PAGE_SHIFT)
-
-/* The in-memory size of struct cfi_shadow, always at least one page */
-#define __SHADOW_PAGES		((__SHADOW_RANGE * sizeof(shadow_t)) >> PAGE_SHIFT)
-#define SHADOW_PAGES		max(1UL, __SHADOW_PAGES)
-#define SHADOW_SIZE		(SHADOW_PAGES << PAGE_SHIFT)
-
-/* The actual size of the shadow array, minus metadata */
-#define SHADOW_ARR_SIZE		(SHADOW_SIZE - offsetof(struct cfi_shadow, shadow))
-#define SHADOW_ARR_SLOTS	(SHADOW_ARR_SIZE / sizeof(shadow_t))
-
-static DEFINE_MUTEX(shadow_update_lock);
-static struct cfi_shadow __rcu *cfi_shadow __read_mostly;
-
-/* Returns the index in the shadow for the given address */
-static inline int ptr_to_shadow(const struct cfi_shadow *s, unsigned long ptr)
-{
-	unsigned long index;
-	unsigned long page = ptr >> PAGE_SHIFT;
-
-	if (unlikely(page < s->base))
-		return -1; /* Outside of module area */
-
-	index = page - s->base;
-
-	if (index >= SHADOW_ARR_SLOTS)
-		return -1; /* Cannot be addressed with shadow */
-
-	return (int)index;
-}
-
-/* Returns the page address for an index in the shadow */
-static inline unsigned long shadow_to_ptr(const struct cfi_shadow *s,
-	int index)
-{
-	if (unlikely(index < 0 || index >= SHADOW_ARR_SLOTS))
-		return 0;
-
-	return (s->base + index) << PAGE_SHIFT;
-}
-
-/* Returns the __cfi_check function address for the given shadow location */
-static inline unsigned long shadow_to_check_fn(const struct cfi_shadow *s,
-	int index)
-{
-	if (unlikely(index < 0 || index >= SHADOW_ARR_SLOTS))
-		return 0;
-
-	if (unlikely(s->shadow[index] == SHADOW_INVALID))
-		return 0;
-
-	/* __cfi_check is always page aligned */
-	return (s->base + s->shadow[index]) << PAGE_SHIFT;
-}
-
-static void prepare_next_shadow(const struct cfi_shadow __rcu *prev,
-		struct cfi_shadow *next)
-{
-	int i, index, check;
-
-	/* Mark everything invalid */
-	memset(next->shadow, 0xFF, SHADOW_ARR_SIZE);
-
-	if (!prev)
-		return; /* No previous shadow */
-
-	/* If the base address didn't change, an update is not needed */
-	if (prev->base == next->base) {
-		memcpy(next->shadow, prev->shadow, SHADOW_ARR_SIZE);
-		return;
-	}
-
-	/* Convert the previous shadow to the new address range */
-	for (i = 0; i < SHADOW_ARR_SLOTS; ++i) {
-		if (prev->shadow[i] == SHADOW_INVALID)
-			continue;
-
-		index = ptr_to_shadow(next, shadow_to_ptr(prev, i));
-		if (index < 0)
-			continue;
-
-		check = ptr_to_shadow(next,
-				shadow_to_check_fn(prev, prev->shadow[i]));
-		if (check < 0)
-			continue;
-
-		next->shadow[index] = (shadow_t)check;
-	}
-}
-
-static void add_module_to_shadow(struct cfi_shadow *s, struct module *mod,
-			unsigned long min_addr, unsigned long max_addr)
-{
-	int check_index;
-	unsigned long check = (unsigned long)mod->cfi_check;
-	unsigned long ptr;
-
-	if (unlikely(!PAGE_ALIGNED(check))) {
-		pr_warn("cfi: not using shadow for module %s\n", mod->name);
-		return;
-	}
-
-	check_index = ptr_to_shadow(s, check);
-	if (check_index < 0)
-		return; /* Module not addressable with shadow */
-
-	/* For each page, store the check function index in the shadow */
-	for (ptr = min_addr; ptr <= max_addr; ptr += PAGE_SIZE) {
-		int index = ptr_to_shadow(s, ptr);
-
-		if (index >= 0) {
-			/* Each page must only contain one module */
-			WARN_ON_ONCE(s->shadow[index] != SHADOW_INVALID);
-			s->shadow[index] = (shadow_t)check_index;
-		}
-	}
-}
-
-static void remove_module_from_shadow(struct cfi_shadow *s, struct module *mod,
-		unsigned long min_addr, unsigned long max_addr)
-{
-	unsigned long ptr;
-
-	for (ptr = min_addr; ptr <= max_addr; ptr += PAGE_SIZE) {
-		int index = ptr_to_shadow(s, ptr);
-
-		if (index >= 0)
-			s->shadow[index] = SHADOW_INVALID;
-	}
-}
-
-typedef void (*update_shadow_fn)(struct cfi_shadow *, struct module *,
-			unsigned long min_addr, unsigned long max_addr);
-
-static void update_shadow(struct module *mod, unsigned long base_addr,
-		update_shadow_fn fn)
-{
-	struct cfi_shadow *prev;
-	struct cfi_shadow *next;
-	unsigned long min_addr, max_addr;
-
-	next = vmalloc(SHADOW_SIZE);
-
-	mutex_lock(&shadow_update_lock);
-	prev = rcu_dereference_protected(cfi_shadow,
-					 mutex_is_locked(&shadow_update_lock));
-
-	if (next) {
-		next->base = base_addr >> PAGE_SHIFT;
-		prepare_next_shadow(prev, next);
-
-		min_addr = (unsigned long)mod->core_layout.base;
-		max_addr = min_addr + mod->core_layout.text_size;
-		fn(next, mod, min_addr & PAGE_MASK, max_addr & PAGE_MASK);
-
-		set_memory_ro((unsigned long)next, SHADOW_PAGES);
-	}
-
-	rcu_assign_pointer(cfi_shadow, next);
-	mutex_unlock(&shadow_update_lock);
-	synchronize_rcu();
-
-	if (prev) {
-		set_memory_rw((unsigned long)prev, SHADOW_PAGES);
-		vfree(prev);
-	}
-}
-
-void cfi_module_add(struct module *mod, unsigned long base_addr)
-{
-	update_shadow(mod, base_addr, add_module_to_shadow);
-}
-
-void cfi_module_remove(struct module *mod, unsigned long base_addr)
-{
-	update_shadow(mod, base_addr, remove_module_from_shadow);
-}
-
-static inline cfi_check_fn ptr_to_check_fn(const struct cfi_shadow __rcu *s,
-	unsigned long ptr)
-{
-	int index;
-
-	if (unlikely(!s))
-		return NULL; /* No shadow available */
-
-	index = ptr_to_shadow(s, ptr);
-	if (index < 0)
-		return NULL; /* Cannot be addressed with shadow */
-
-	return (cfi_check_fn)shadow_to_check_fn(s, index);
-}
-
-static inline cfi_check_fn find_shadow_check_fn(unsigned long ptr)
-{
-	cfi_check_fn fn;
-
-	rcu_read_lock_sched_notrace();
-	fn = ptr_to_check_fn(rcu_dereference_sched(cfi_shadow), ptr);
-	rcu_read_unlock_sched_notrace();
-
-	return fn;
-}
-
-#else /* !CONFIG_CFI_CLANG_SHADOW */
-
-static inline cfi_check_fn find_shadow_check_fn(unsigned long ptr)
-{
-	return NULL;
-}
-
-#endif /* CONFIG_CFI_CLANG_SHADOW */
 
 static inline cfi_check_fn find_module_check_fn(unsigned long ptr)
 {
@@ -291,11 +60,7 @@ static inline cfi_check_fn find_check_fn(unsigned long ptr)
 	 * up if necessary.
 	 */
 	RCU_NONIDLE({
-		if (IS_ENABLED(CONFIG_CFI_CLANG_SHADOW))
-			fn = find_shadow_check_fn(ptr);
-
-		if (!fn)
-			fn = find_module_check_fn(ptr);
+		fn = find_module_check_fn(ptr);
 	});
 
 	return fn;
diff --git a/kernel/module.c b/kernel/module.c
index 6cea788fd965..296fe02323e9 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2151,8 +2151,6 @@ void __weak module_arch_freeing_init(struct module *mod)
 {
 }
 
-static void cfi_cleanup(struct module *mod);
-
 /* Free a module, remove from lists, etc. */
 static void free_module(struct module *mod)
 {
@@ -2194,9 +2192,6 @@ static void free_module(struct module *mod)
 	synchronize_rcu();
 	mutex_unlock(&module_mutex);
 
-	/* Clean up CFI for the module. */
-	cfi_cleanup(mod);
-
 	/* This may be empty, but that's OK */
 	module_arch_freeing_init(mod);
 	module_memfree(mod->init_layout.base);
@@ -4141,7 +4136,6 @@ static int load_module(struct load_info *info, const char __user *uargs,
 	synchronize_rcu();
 	kfree(mod->args);
  free_arch_cleanup:
-	cfi_cleanup(mod);
 	module_arch_cleanup(mod);
  free_modinfo:
 	free_modinfo(mod);
@@ -4530,15 +4524,6 @@ static void cfi_init(struct module *mod)
 	if (exit)
 		mod->exit = *exit;
 #endif
-
-	cfi_module_add(mod, module_addr_min);
-#endif
-}
-
-static void cfi_cleanup(struct module *mod)
-{
-#ifdef CONFIG_CFI_CLANG
-	cfi_module_remove(mod, module_addr_min);
 #endif
 }
 
-- 
2.36.0.550.gb090851708-goog


_______________________________________________
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] 174+ messages in thread

* [RFC PATCH v2 05/21] cfi: Drop __CFI_ADDRESSABLE
  2022-05-13 20:21 ` Sami Tolvanen
@ 2022-05-13 20:21   ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

The __CFI_ADDRESSABLE macro is used for init_module and cleanup_module
to ensure we have the address of the CFI jump table, and with
CONFIG_X86_KERNEL_IBT to ensure LTO won't optimize away the symbols.
As __CFI_ADDRESSABLE is no longer necessary with -fsanitize=kcfi, add
a more flexible version of the __ADDRESSABLE macro and always ensure
these symbols won't be dropped.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 include/linux/cfi.h      | 20 --------------------
 include/linux/compiler.h |  6 ++++--
 include/linux/module.h   |  4 ++--
 3 files changed, 6 insertions(+), 24 deletions(-)

diff --git a/include/linux/cfi.h b/include/linux/cfi.h
index 4ab51c067007..2cdbc0fbd0ab 100644
--- a/include/linux/cfi.h
+++ b/include/linux/cfi.h
@@ -13,26 +13,6 @@ typedef void (*cfi_check_fn)(uint64_t id, void *ptr, void *diag);
 /* Compiler-generated function in each module, and the kernel */
 extern void __cfi_check(uint64_t id, void *ptr, void *diag);
 
-/*
- * Force the compiler to generate a CFI jump table entry for a function
- * and store the jump table address to __cfi_jt_<function>.
- */
-#define __CFI_ADDRESSABLE(fn, __attr) \
-	const void *__cfi_jt_ ## fn __visible __attr = (void *)&fn
-
-#else /* !CONFIG_CFI_CLANG */
-
-#ifdef CONFIG_X86_KERNEL_IBT
-
-#define __CFI_ADDRESSABLE(fn, __attr) \
-	const void *__cfi_jt_ ## fn __visible __attr = (void *)&fn
-
-#endif /* CONFIG_X86_KERNEL_IBT */
-
 #endif /* CONFIG_CFI_CLANG */
 
-#ifndef __CFI_ADDRESSABLE
-#define __CFI_ADDRESSABLE(fn, __attr)
-#endif
-
 #endif /* _LINUX_CFI_H */
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 219aa5ddbc73..9303f5fe5d89 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -221,9 +221,11 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
  * otherwise, or eliminated entirely due to lack of references that are
  * visible to the compiler.
  */
-#define __ADDRESSABLE(sym) \
-	static void * __section(".discard.addressable") __used \
+#define ___ADDRESSABLE(sym, __attrs) \
+	static void * __used __attrs \
 		__UNIQUE_ID(__PASTE(__addressable_,sym)) = (void *)&sym;
+#define __ADDRESSABLE(sym) \
+	___ADDRESSABLE(sym, __section(".discard.addressable"))
 
 /**
  * offset_to_ptr - convert a relative memory offset to an absolute pointer
diff --git a/include/linux/module.h b/include/linux/module.h
index 1e135fd5c076..87857275c047 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -132,7 +132,7 @@ extern void cleanup_module(void);
 	{ return initfn; }					\
 	int init_module(void) __copy(initfn)			\
 		__attribute__((alias(#initfn)));		\
-	__CFI_ADDRESSABLE(init_module, __initdata);
+	___ADDRESSABLE(init_module, __initdata);
 
 /* This is only required if you want to be unloadable. */
 #define module_exit(exitfn)					\
@@ -140,7 +140,7 @@ extern void cleanup_module(void);
 	{ return exitfn; }					\
 	void cleanup_module(void) __copy(exitfn)		\
 		__attribute__((alias(#exitfn)));		\
-	__CFI_ADDRESSABLE(cleanup_module, __exitdata);
+	___ADDRESSABLE(cleanup_module, __exitdata);
 
 #endif
 
-- 
2.36.0.550.gb090851708-goog


^ permalink raw reply	[flat|nested] 174+ messages in thread

* [RFC PATCH v2 05/21] cfi: Drop __CFI_ADDRESSABLE
@ 2022-05-13 20:21   ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

The __CFI_ADDRESSABLE macro is used for init_module and cleanup_module
to ensure we have the address of the CFI jump table, and with
CONFIG_X86_KERNEL_IBT to ensure LTO won't optimize away the symbols.
As __CFI_ADDRESSABLE is no longer necessary with -fsanitize=kcfi, add
a more flexible version of the __ADDRESSABLE macro and always ensure
these symbols won't be dropped.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 include/linux/cfi.h      | 20 --------------------
 include/linux/compiler.h |  6 ++++--
 include/linux/module.h   |  4 ++--
 3 files changed, 6 insertions(+), 24 deletions(-)

diff --git a/include/linux/cfi.h b/include/linux/cfi.h
index 4ab51c067007..2cdbc0fbd0ab 100644
--- a/include/linux/cfi.h
+++ b/include/linux/cfi.h
@@ -13,26 +13,6 @@ typedef void (*cfi_check_fn)(uint64_t id, void *ptr, void *diag);
 /* Compiler-generated function in each module, and the kernel */
 extern void __cfi_check(uint64_t id, void *ptr, void *diag);
 
-/*
- * Force the compiler to generate a CFI jump table entry for a function
- * and store the jump table address to __cfi_jt_<function>.
- */
-#define __CFI_ADDRESSABLE(fn, __attr) \
-	const void *__cfi_jt_ ## fn __visible __attr = (void *)&fn
-
-#else /* !CONFIG_CFI_CLANG */
-
-#ifdef CONFIG_X86_KERNEL_IBT
-
-#define __CFI_ADDRESSABLE(fn, __attr) \
-	const void *__cfi_jt_ ## fn __visible __attr = (void *)&fn
-
-#endif /* CONFIG_X86_KERNEL_IBT */
-
 #endif /* CONFIG_CFI_CLANG */
 
-#ifndef __CFI_ADDRESSABLE
-#define __CFI_ADDRESSABLE(fn, __attr)
-#endif
-
 #endif /* _LINUX_CFI_H */
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 219aa5ddbc73..9303f5fe5d89 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -221,9 +221,11 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
  * otherwise, or eliminated entirely due to lack of references that are
  * visible to the compiler.
  */
-#define __ADDRESSABLE(sym) \
-	static void * __section(".discard.addressable") __used \
+#define ___ADDRESSABLE(sym, __attrs) \
+	static void * __used __attrs \
 		__UNIQUE_ID(__PASTE(__addressable_,sym)) = (void *)&sym;
+#define __ADDRESSABLE(sym) \
+	___ADDRESSABLE(sym, __section(".discard.addressable"))
 
 /**
  * offset_to_ptr - convert a relative memory offset to an absolute pointer
diff --git a/include/linux/module.h b/include/linux/module.h
index 1e135fd5c076..87857275c047 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -132,7 +132,7 @@ extern void cleanup_module(void);
 	{ return initfn; }					\
 	int init_module(void) __copy(initfn)			\
 		__attribute__((alias(#initfn)));		\
-	__CFI_ADDRESSABLE(init_module, __initdata);
+	___ADDRESSABLE(init_module, __initdata);
 
 /* This is only required if you want to be unloadable. */
 #define module_exit(exitfn)					\
@@ -140,7 +140,7 @@ extern void cleanup_module(void);
 	{ return exitfn; }					\
 	void cleanup_module(void) __copy(exitfn)		\
 		__attribute__((alias(#exitfn)));		\
-	__CFI_ADDRESSABLE(cleanup_module, __exitdata);
+	___ADDRESSABLE(cleanup_module, __exitdata);
 
 #endif
 
-- 
2.36.0.550.gb090851708-goog


_______________________________________________
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] 174+ messages in thread

* [RFC PATCH v2 06/21] cfi: Switch to -fsanitize=kcfi
  2022-05-13 20:21 ` Sami Tolvanen
@ 2022-05-13 20:21   ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

Switch from Clang's original forward-edge control-flow integrity
implementation to -fsanitize=kcfi, which is better suited for the
kernel, as it doesn't require LTO, doesn't use a jump table that
requires altering function references, and won't break cross-module
function address equality.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 Makefile                          |  13 +--
 arch/Kconfig                      |  11 ++-
 include/asm-generic/vmlinux.lds.h |  37 ++++-----
 include/linux/cfi.h               |  35 +++++++--
 include/linux/compiler-clang.h    |   6 +-
 include/linux/module.h            |   6 +-
 kernel/cfi.c                      | 126 ++++++++++++++----------------
 kernel/module.c                   |  34 +-------
 scripts/module.lds.S              |  23 +-----
 9 files changed, 128 insertions(+), 163 deletions(-)

diff --git a/Makefile b/Makefile
index 2284d1ca2503..8439551954f1 100644
--- a/Makefile
+++ b/Makefile
@@ -915,18 +915,7 @@ export CC_FLAGS_LTO
 endif
 
 ifdef CONFIG_CFI_CLANG
-CC_FLAGS_CFI	:= -fsanitize=cfi \
-		   -fsanitize-cfi-cross-dso \
-		   -fno-sanitize-cfi-canonical-jump-tables \
-		   -fno-sanitize-trap=cfi \
-		   -fno-sanitize-blacklist
-
-ifdef CONFIG_CFI_PERMISSIVE
-CC_FLAGS_CFI	+= -fsanitize-recover=cfi
-endif
-
-# If LTO flags are filtered out, we must also filter out CFI.
-CC_FLAGS_LTO	+= $(CC_FLAGS_CFI)
+CC_FLAGS_CFI	:= -fsanitize=kcfi
 KBUILD_CFLAGS	+= $(CC_FLAGS_CFI)
 export CC_FLAGS_CFI
 endif
diff --git a/arch/Kconfig b/arch/Kconfig
index 625db6376726..f179170cb422 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -720,14 +720,13 @@ config ARCH_SUPPORTS_CFI_CLANG
 	  An architecture should select this option if it can support Clang's
 	  Control-Flow Integrity (CFI) checking.
 
+config ARCH_USES_CFI_TRAPS
+	bool
+
 config CFI_CLANG
 	bool "Use Clang's Control Flow Integrity (CFI)"
-	depends on LTO_CLANG && ARCH_SUPPORTS_CFI_CLANG
-	# Clang >= 12:
-	# - https://bugs.llvm.org/show_bug.cgi?id=46258
-	# - https://bugs.llvm.org/show_bug.cgi?id=47479
-	depends on CLANG_VERSION >= 120000
-	select KALLSYMS
+	depends on ARCH_SUPPORTS_CFI_CLANG
+	depends on $(cc-option,-fsanitize=kcfi)
 	help
 	  This option enables Clang’s forward-edge Control Flow Integrity
 	  (CFI) checking, where the compiler injects a runtime check to each
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 69138e9db787..fcb3c7146a43 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -421,6 +421,22 @@
 	__end_ro_after_init = .;
 #endif
 
+/*
+ * .kcfi_traps contains a list KCFI trap locations.
+ */
+#ifndef KCFI_TRAPS
+#ifdef CONFIG_ARCH_USES_CFI_TRAPS
+#define KCFI_TRAPS							\
+	__kcfi_traps : AT(ADDR(__kcfi_traps) - LOAD_OFFSET) {		\
+		__start___kcfi_traps = .;				\
+		KEEP(*(.kcfi_traps))					\
+		__stop___kcfi_traps = .;				\
+	}
+#else
+#define KCFI_TRAPS
+#endif
+#endif
+
 /*
  * Read only Data
  */
@@ -529,6 +545,8 @@
 		__stop___modver = .;					\
 	}								\
 									\
+	KCFI_TRAPS							\
+									\
 	RO_EXCEPTION_TABLE						\
 	NOTES								\
 	BTF								\
@@ -537,21 +555,6 @@
 	__end_rodata = .;
 
 
-/*
- * .text..L.cfi.jumptable.* contain Control-Flow Integrity (CFI)
- * jump table entries.
- */
-#ifdef CONFIG_CFI_CLANG
-#define TEXT_CFI_JT							\
-		. = ALIGN(PMD_SIZE);					\
-		__cfi_jt_start = .;					\
-		*(.text..L.cfi.jumptable .text..L.cfi.jumptable.*)	\
-		. = ALIGN(PMD_SIZE);					\
-		__cfi_jt_end = .;
-#else
-#define TEXT_CFI_JT
-#endif
-
 /*
  * Non-instrumentable text section
  */
@@ -579,7 +582,6 @@
 		*(.text..refcount)					\
 		*(.ref.text)						\
 		*(.text.asan.* .text.tsan.*)				\
-		TEXT_CFI_JT						\
 	MEM_KEEP(init.text*)						\
 	MEM_KEEP(exit.text*)						\
 
@@ -1008,8 +1010,7 @@
  * keep any .init_array.* sections.
  * https://bugs.llvm.org/show_bug.cgi?id=46478
  */
-#if defined(CONFIG_GCOV_KERNEL) || defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KCSAN) || \
-	defined(CONFIG_CFI_CLANG)
+#if defined(CONFIG_GCOV_KERNEL) || defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KCSAN)
 # ifdef CONFIG_CONSTRUCTORS
 #  define SANITIZER_DISCARDS						\
 	*(.eh_frame)
diff --git a/include/linux/cfi.h b/include/linux/cfi.h
index 2cdbc0fbd0ab..655b8b10ac3d 100644
--- a/include/linux/cfi.h
+++ b/include/linux/cfi.h
@@ -2,17 +2,42 @@
 /*
  * Clang Control Flow Integrity (CFI) support.
  *
- * Copyright (C) 2021 Google LLC
+ * Copyright (C) 2022 Google LLC
  */
 #ifndef _LINUX_CFI_H
 #define _LINUX_CFI_H
 
+#include <linux/bug.h>
+#include <linux/module.h>
+
 #ifdef CONFIG_CFI_CLANG
-typedef void (*cfi_check_fn)(uint64_t id, void *ptr, void *diag);
+enum bug_trap_type report_cfi_failure(struct pt_regs *regs, unsigned long addr,
+				      unsigned long target, unsigned long type);
+#else
+static inline enum bug_trap_type report_cfi_failure(struct pt_regs *regs,
+						    unsigned long addr,
+						    unsigned long target,
+						    unsigned long type)
+{
+	return BUG_TRAP_TYPE_NONE;
+}
+#endif /* CONFIG_CFI_CLANG */
 
-/* Compiler-generated function in each module, and the kernel */
-extern void __cfi_check(uint64_t id, void *ptr, void *diag);
+#ifdef CONFIG_ARCH_USES_CFI_TRAPS
+bool is_cfi_trap(unsigned long addr);
+#else
+static inline bool is_cfi_trap(unsigned long addr) { return false; }
+#endif /* CONFIG_ARCH_USES_CFI_TRAPS */
 
-#endif /* CONFIG_CFI_CLANG */
+#ifdef CONFIG_MODULES
+#ifdef CONFIG_ARCH_USES_CFI_TRAPS
+void module_cfi_finalize(const Elf_Ehdr *hdr, const Elf_Shdr *sechdrs,
+			 struct module *mod);
+#else
+static inline void module_cfi_finalize(const Elf_Ehdr *hdr,
+				       const Elf_Shdr *sechdrs,
+				       struct module *mod) {}
+#endif /* CONFIG_ARCH_USES_CFI_TRAPS */
+#endif /* CONFIG_MODULES */
 
 #endif /* _LINUX_CFI_H */
diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
index babb1347148c..42e55579d649 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -66,8 +66,10 @@
 # define __noscs	__attribute__((__no_sanitize__("shadow-call-stack")))
 #endif
 
-#define __nocfi		__attribute__((__no_sanitize__("cfi")))
-#define __cficanonical	__attribute__((__cfi_canonical_jump_table__))
+#if __has_feature(kcfi)
+/* Disable CFI checking inside a function. */
+#define __nocfi		__attribute__((__no_sanitize__("kcfi")))
+#endif
 
 /*
  * Turn individual warnings and errors on and off locally, depending
diff --git a/include/linux/module.h b/include/linux/module.h
index 87857275c047..3b485834be74 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -27,7 +27,6 @@
 #include <linux/tracepoint-defs.h>
 #include <linux/srcu.h>
 #include <linux/static_call_types.h>
-#include <linux/cfi.h>
 
 #include <linux/percpu.h>
 #include <asm/module.h>
@@ -388,8 +387,9 @@ struct module {
 	const s32 *crcs;
 	unsigned int num_syms;
 
-#ifdef CONFIG_CFI_CLANG
-	cfi_check_fn cfi_check;
+#ifdef CONFIG_ARCH_USES_CFI_TRAPS
+	unsigned long *kcfi_traps;
+	unsigned long *kcfi_traps_end;
 #endif
 
 	/* Kernel parameters. */
diff --git a/kernel/cfi.c b/kernel/cfi.c
index 2cc0d01ea980..456d5eac082a 100644
--- a/kernel/cfi.c
+++ b/kernel/cfi.c
@@ -1,94 +1,86 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Clang Control Flow Integrity (CFI) error and slowpath handling.
+ * Clang Control Flow Integrity (CFI) error handling.
  *
- * Copyright (C) 2021 Google LLC
+ * Copyright (C) 2022 Google LLC
  */
 
-#include <linux/hardirq.h>
-#include <linux/kallsyms.h>
-#include <linux/module.h>
-#include <linux/mutex.h>
-#include <linux/printk.h>
-#include <linux/ratelimit.h>
-#include <linux/rcupdate.h>
-#include <linux/vmalloc.h>
-#include <asm/cacheflush.h>
-#include <asm/set_memory.h>
-
-/* Compiler-defined handler names */
-#ifdef CONFIG_CFI_PERMISSIVE
-#define cfi_failure_handler	__ubsan_handle_cfi_check_fail
-#else
-#define cfi_failure_handler	__ubsan_handle_cfi_check_fail_abort
-#endif
-
-static inline void handle_cfi_failure(void *ptr)
-{
-	if (IS_ENABLED(CONFIG_CFI_PERMISSIVE))
-		WARN_RATELIMIT(1, "CFI failure (target: %pS):\n", ptr);
-	else
-		panic("CFI failure (target: %pS)\n", ptr);
-}
-
-#ifdef CONFIG_MODULES
+#include <linux/cfi.h>
 
-static inline cfi_check_fn find_module_check_fn(unsigned long ptr)
+enum bug_trap_type report_cfi_failure(struct pt_regs *regs, unsigned long addr,
+				      unsigned long target, unsigned long type)
 {
-	cfi_check_fn fn = NULL;
-	struct module *mod;
+	pr_err("CFI failure at %pS (target: %pS; expected type: 0x%08x)\n",
+	       (void *)addr, (void *)target, (u32)type);
 
-	rcu_read_lock_sched_notrace();
-	mod = __module_address(ptr);
-	if (mod)
-		fn = mod->cfi_check;
-	rcu_read_unlock_sched_notrace();
+	if (IS_ENABLED(CONFIG_CFI_PERMISSIVE)) {
+		__warn(NULL, 0, (void *)addr, 0, regs, NULL);
+		return BUG_TRAP_TYPE_WARN;
+	}
 
-	return fn;
+	return BUG_TRAP_TYPE_BUG;
 }
 
-static inline cfi_check_fn find_check_fn(unsigned long ptr)
+#ifdef CONFIG_ARCH_USES_CFI_TRAPS
+#ifdef CONFIG_MODULES
+/* Populates `kcfi_trap(_end)?` fields in `struct module`. */
+void module_cfi_finalize(const Elf_Ehdr *hdr, const Elf_Shdr *sechdrs,
+			 struct module *mod)
 {
-	cfi_check_fn fn = NULL;
+	char *secstrings;
+	unsigned int i;
 
-	if (is_kernel_text(ptr))
-		return __cfi_check;
+	mod->kcfi_traps = NULL;
+	mod->kcfi_traps_end = NULL;
 
-	/*
-	 * Indirect call checks can happen when RCU is not watching. Both
-	 * the shadow and __module_address use RCU, so we need to wake it
-	 * up if necessary.
-	 */
-	RCU_NONIDLE({
-		fn = find_module_check_fn(ptr);
-	});
+	secstrings = (char *)hdr + sechdrs[hdr->e_shstrndx].sh_offset;
 
-	return fn;
+	for (i = 1; i < hdr->e_shnum; i++) {
+		if (strcmp(secstrings + sechdrs[i].sh_name, "__kcfi_traps"))
+			continue;
+
+		mod->kcfi_traps = (unsigned long *)sechdrs[i].sh_addr;
+		mod->kcfi_traps_end = (unsigned long *)(sechdrs[i].sh_addr +
+							sechdrs[i].sh_size);
+		break;
+	}
 }
 
-void __cfi_slowpath_diag(uint64_t id, void *ptr, void *diag)
+static bool is_module_cfi_trap(unsigned long addr)
 {
-	cfi_check_fn fn = find_check_fn((unsigned long)ptr);
+	bool found = false;
+	struct module *mod;
+	unsigned long *p;
 
-	if (likely(fn))
-		fn(id, ptr, diag);
-	else /* Don't allow unchecked modules */
-		handle_cfi_failure(ptr);
-}
-EXPORT_SYMBOL(__cfi_slowpath_diag);
+	rcu_read_lock_sched_notrace();
 
-#else /* !CONFIG_MODULES */
+	mod = __module_address(addr);
+	if (mod)
+		for (p = mod->kcfi_traps; !found && p < mod->kcfi_traps_end; ++p)
+			found = (*p == addr);
+
+	rcu_read_unlock_sched_notrace();
 
-void __cfi_slowpath_diag(uint64_t id, void *ptr, void *diag)
+	return found;
+}
+#else /* CONFIG_MODULES */
+static inline bool is_module_cfi_trap(unsigned long addr)
 {
-	handle_cfi_failure(ptr); /* No modules */
+	return false;
 }
-EXPORT_SYMBOL(__cfi_slowpath_diag);
-
 #endif /* CONFIG_MODULES */
 
-void cfi_failure_handler(void *data, void *ptr, void *vtable)
+extern unsigned long __start___kcfi_traps[];
+extern unsigned long __stop___kcfi_traps[];
+
+bool is_cfi_trap(unsigned long addr)
 {
-	handle_cfi_failure(ptr);
+	unsigned long *p;
+
+	for (p = __start___kcfi_traps; p < __stop___kcfi_traps; ++p)
+		if (*p == addr)
+			return true;
+
+	return is_module_cfi_trap(addr);
 }
-EXPORT_SYMBOL(cfi_failure_handler);
+#endif /* CONFIG_ARCH_USES_CFI_TRAPS */
diff --git a/kernel/module.c b/kernel/module.c
index 296fe02323e9..411ae8c358e6 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -57,6 +57,7 @@
 #include <linux/bsearch.h>
 #include <linux/dynamic_debug.h>
 #include <linux/audit.h>
+#include <linux/cfi.h>
 #include <uapi/linux/module.h>
 #include "module-internal.h"
 
@@ -3871,8 +3872,9 @@ static int complete_formation(struct module *mod, struct load_info *info)
 	if (err < 0)
 		goto out;
 
-	/* This relies on module_mutex for list integrity. */
+	/* These rely on module_mutex for list integrity. */
 	module_bug_finalize(info->hdr, info->sechdrs, mod);
+	module_cfi_finalize(info->hdr, info->sechdrs, mod);
 
 	module_enable_ro(mod, false);
 	module_enable_nx(mod);
@@ -3928,8 +3930,6 @@ static int unknown_module_param_cb(char *param, char *val, const char *modname,
 	return 0;
 }
 
-static void cfi_init(struct module *mod);
-
 /*
  * Allocate and load the module: note that size of section 0 is always
  * zero, and we rely on this for optional sections.
@@ -4059,9 +4059,6 @@ static int load_module(struct load_info *info, const char __user *uargs,
 
 	flush_module_icache(mod);
 
-	/* Setup CFI for the module. */
-	cfi_init(mod);
-
 	/* Now copy in args */
 	mod->args = strndup_user(uargs, ~0UL >> 1);
 	if (IS_ERR(mod->args)) {
@@ -4502,31 +4499,6 @@ int module_kallsyms_on_each_symbol(int (*fn)(void *, const char *,
 #endif /* CONFIG_LIVEPATCH */
 #endif /* CONFIG_KALLSYMS */
 
-static void cfi_init(struct module *mod)
-{
-#ifdef CONFIG_CFI_CLANG
-	initcall_t *init;
-	exitcall_t *exit;
-
-	rcu_read_lock_sched();
-	mod->cfi_check = (cfi_check_fn)
-		find_kallsyms_symbol_value(mod, "__cfi_check");
-	init = (initcall_t *)
-		find_kallsyms_symbol_value(mod, "__cfi_jt_init_module");
-	exit = (exitcall_t *)
-		find_kallsyms_symbol_value(mod, "__cfi_jt_cleanup_module");
-	rcu_read_unlock_sched();
-
-	/* Fix init/exit functions to point to the CFI jump table */
-	if (init)
-		mod->init = *init;
-#ifdef CONFIG_MODULE_UNLOAD
-	if (exit)
-		mod->exit = *exit;
-#endif
-#endif
-}
-
 /* Maximum number of characters written by module_flags() */
 #define MODULE_FLAGS_BUF_SIZE (TAINT_FLAGS_COUNT + 4)
 
diff --git a/scripts/module.lds.S b/scripts/module.lds.S
index 1d0e1e4dc3d2..0708896139cc 100644
--- a/scripts/module.lds.S
+++ b/scripts/module.lds.S
@@ -3,20 +3,10 @@
  * Archs are free to supply their own linker scripts.  ld will
  * combine them automatically.
  */
-#ifdef CONFIG_CFI_CLANG
-# include <asm/page.h>
-# define ALIGN_CFI 		ALIGN(PAGE_SIZE)
-# define SANITIZER_DISCARDS	*(.eh_frame)
-#else
-# define ALIGN_CFI
-# define SANITIZER_DISCARDS
-#endif
-
 SECTIONS {
 	/DISCARD/ : {
 		*(.discard)
 		*(.discard.*)
-		SANITIZER_DISCARDS
 	}
 
 	__ksymtab		0 : { *(SORT(___ksymtab+*)) }
@@ -31,6 +21,10 @@ SECTIONS {
 
 	__patchable_function_entries : { *(__patchable_function_entries) }
 
+#ifdef CONFIG_ARCH_USES_CFI_TRAPS
+	__kcfi_traps 		: { KEEP(*(.kcfi_traps)) }
+#endif
+
 #ifdef CONFIG_LTO_CLANG
 	/*
 	 * With CONFIG_LTO_CLANG, LLD always enables -fdata-sections and
@@ -51,15 +45,6 @@ SECTIONS {
 		*(.rodata .rodata.[0-9a-zA-Z_]*)
 		*(.rodata..L*)
 	}
-
-	/*
-	 * With CONFIG_CFI_CLANG, we assume __cfi_check is at the beginning
-	 * of the .text section, and is aligned to PAGE_SIZE.
-	 */
-	.text : ALIGN_CFI {
-		*(.text.__cfi_check)
-		*(.text .text.[0-9a-zA-Z_]* .text..L.cfi*)
-	}
 #endif
 }
 
-- 
2.36.0.550.gb090851708-goog


^ permalink raw reply	[flat|nested] 174+ messages in thread

* [RFC PATCH v2 06/21] cfi: Switch to -fsanitize=kcfi
@ 2022-05-13 20:21   ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

Switch from Clang's original forward-edge control-flow integrity
implementation to -fsanitize=kcfi, which is better suited for the
kernel, as it doesn't require LTO, doesn't use a jump table that
requires altering function references, and won't break cross-module
function address equality.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 Makefile                          |  13 +--
 arch/Kconfig                      |  11 ++-
 include/asm-generic/vmlinux.lds.h |  37 ++++-----
 include/linux/cfi.h               |  35 +++++++--
 include/linux/compiler-clang.h    |   6 +-
 include/linux/module.h            |   6 +-
 kernel/cfi.c                      | 126 ++++++++++++++----------------
 kernel/module.c                   |  34 +-------
 scripts/module.lds.S              |  23 +-----
 9 files changed, 128 insertions(+), 163 deletions(-)

diff --git a/Makefile b/Makefile
index 2284d1ca2503..8439551954f1 100644
--- a/Makefile
+++ b/Makefile
@@ -915,18 +915,7 @@ export CC_FLAGS_LTO
 endif
 
 ifdef CONFIG_CFI_CLANG
-CC_FLAGS_CFI	:= -fsanitize=cfi \
-		   -fsanitize-cfi-cross-dso \
-		   -fno-sanitize-cfi-canonical-jump-tables \
-		   -fno-sanitize-trap=cfi \
-		   -fno-sanitize-blacklist
-
-ifdef CONFIG_CFI_PERMISSIVE
-CC_FLAGS_CFI	+= -fsanitize-recover=cfi
-endif
-
-# If LTO flags are filtered out, we must also filter out CFI.
-CC_FLAGS_LTO	+= $(CC_FLAGS_CFI)
+CC_FLAGS_CFI	:= -fsanitize=kcfi
 KBUILD_CFLAGS	+= $(CC_FLAGS_CFI)
 export CC_FLAGS_CFI
 endif
diff --git a/arch/Kconfig b/arch/Kconfig
index 625db6376726..f179170cb422 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -720,14 +720,13 @@ config ARCH_SUPPORTS_CFI_CLANG
 	  An architecture should select this option if it can support Clang's
 	  Control-Flow Integrity (CFI) checking.
 
+config ARCH_USES_CFI_TRAPS
+	bool
+
 config CFI_CLANG
 	bool "Use Clang's Control Flow Integrity (CFI)"
-	depends on LTO_CLANG && ARCH_SUPPORTS_CFI_CLANG
-	# Clang >= 12:
-	# - https://bugs.llvm.org/show_bug.cgi?id=46258
-	# - https://bugs.llvm.org/show_bug.cgi?id=47479
-	depends on CLANG_VERSION >= 120000
-	select KALLSYMS
+	depends on ARCH_SUPPORTS_CFI_CLANG
+	depends on $(cc-option,-fsanitize=kcfi)
 	help
 	  This option enables Clang’s forward-edge Control Flow Integrity
 	  (CFI) checking, where the compiler injects a runtime check to each
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 69138e9db787..fcb3c7146a43 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -421,6 +421,22 @@
 	__end_ro_after_init = .;
 #endif
 
+/*
+ * .kcfi_traps contains a list KCFI trap locations.
+ */
+#ifndef KCFI_TRAPS
+#ifdef CONFIG_ARCH_USES_CFI_TRAPS
+#define KCFI_TRAPS							\
+	__kcfi_traps : AT(ADDR(__kcfi_traps) - LOAD_OFFSET) {		\
+		__start___kcfi_traps = .;				\
+		KEEP(*(.kcfi_traps))					\
+		__stop___kcfi_traps = .;				\
+	}
+#else
+#define KCFI_TRAPS
+#endif
+#endif
+
 /*
  * Read only Data
  */
@@ -529,6 +545,8 @@
 		__stop___modver = .;					\
 	}								\
 									\
+	KCFI_TRAPS							\
+									\
 	RO_EXCEPTION_TABLE						\
 	NOTES								\
 	BTF								\
@@ -537,21 +555,6 @@
 	__end_rodata = .;
 
 
-/*
- * .text..L.cfi.jumptable.* contain Control-Flow Integrity (CFI)
- * jump table entries.
- */
-#ifdef CONFIG_CFI_CLANG
-#define TEXT_CFI_JT							\
-		. = ALIGN(PMD_SIZE);					\
-		__cfi_jt_start = .;					\
-		*(.text..L.cfi.jumptable .text..L.cfi.jumptable.*)	\
-		. = ALIGN(PMD_SIZE);					\
-		__cfi_jt_end = .;
-#else
-#define TEXT_CFI_JT
-#endif
-
 /*
  * Non-instrumentable text section
  */
@@ -579,7 +582,6 @@
 		*(.text..refcount)					\
 		*(.ref.text)						\
 		*(.text.asan.* .text.tsan.*)				\
-		TEXT_CFI_JT						\
 	MEM_KEEP(init.text*)						\
 	MEM_KEEP(exit.text*)						\
 
@@ -1008,8 +1010,7 @@
  * keep any .init_array.* sections.
  * https://bugs.llvm.org/show_bug.cgi?id=46478
  */
-#if defined(CONFIG_GCOV_KERNEL) || defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KCSAN) || \
-	defined(CONFIG_CFI_CLANG)
+#if defined(CONFIG_GCOV_KERNEL) || defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KCSAN)
 # ifdef CONFIG_CONSTRUCTORS
 #  define SANITIZER_DISCARDS						\
 	*(.eh_frame)
diff --git a/include/linux/cfi.h b/include/linux/cfi.h
index 2cdbc0fbd0ab..655b8b10ac3d 100644
--- a/include/linux/cfi.h
+++ b/include/linux/cfi.h
@@ -2,17 +2,42 @@
 /*
  * Clang Control Flow Integrity (CFI) support.
  *
- * Copyright (C) 2021 Google LLC
+ * Copyright (C) 2022 Google LLC
  */
 #ifndef _LINUX_CFI_H
 #define _LINUX_CFI_H
 
+#include <linux/bug.h>
+#include <linux/module.h>
+
 #ifdef CONFIG_CFI_CLANG
-typedef void (*cfi_check_fn)(uint64_t id, void *ptr, void *diag);
+enum bug_trap_type report_cfi_failure(struct pt_regs *regs, unsigned long addr,
+				      unsigned long target, unsigned long type);
+#else
+static inline enum bug_trap_type report_cfi_failure(struct pt_regs *regs,
+						    unsigned long addr,
+						    unsigned long target,
+						    unsigned long type)
+{
+	return BUG_TRAP_TYPE_NONE;
+}
+#endif /* CONFIG_CFI_CLANG */
 
-/* Compiler-generated function in each module, and the kernel */
-extern void __cfi_check(uint64_t id, void *ptr, void *diag);
+#ifdef CONFIG_ARCH_USES_CFI_TRAPS
+bool is_cfi_trap(unsigned long addr);
+#else
+static inline bool is_cfi_trap(unsigned long addr) { return false; }
+#endif /* CONFIG_ARCH_USES_CFI_TRAPS */
 
-#endif /* CONFIG_CFI_CLANG */
+#ifdef CONFIG_MODULES
+#ifdef CONFIG_ARCH_USES_CFI_TRAPS
+void module_cfi_finalize(const Elf_Ehdr *hdr, const Elf_Shdr *sechdrs,
+			 struct module *mod);
+#else
+static inline void module_cfi_finalize(const Elf_Ehdr *hdr,
+				       const Elf_Shdr *sechdrs,
+				       struct module *mod) {}
+#endif /* CONFIG_ARCH_USES_CFI_TRAPS */
+#endif /* CONFIG_MODULES */
 
 #endif /* _LINUX_CFI_H */
diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
index babb1347148c..42e55579d649 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -66,8 +66,10 @@
 # define __noscs	__attribute__((__no_sanitize__("shadow-call-stack")))
 #endif
 
-#define __nocfi		__attribute__((__no_sanitize__("cfi")))
-#define __cficanonical	__attribute__((__cfi_canonical_jump_table__))
+#if __has_feature(kcfi)
+/* Disable CFI checking inside a function. */
+#define __nocfi		__attribute__((__no_sanitize__("kcfi")))
+#endif
 
 /*
  * Turn individual warnings and errors on and off locally, depending
diff --git a/include/linux/module.h b/include/linux/module.h
index 87857275c047..3b485834be74 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -27,7 +27,6 @@
 #include <linux/tracepoint-defs.h>
 #include <linux/srcu.h>
 #include <linux/static_call_types.h>
-#include <linux/cfi.h>
 
 #include <linux/percpu.h>
 #include <asm/module.h>
@@ -388,8 +387,9 @@ struct module {
 	const s32 *crcs;
 	unsigned int num_syms;
 
-#ifdef CONFIG_CFI_CLANG
-	cfi_check_fn cfi_check;
+#ifdef CONFIG_ARCH_USES_CFI_TRAPS
+	unsigned long *kcfi_traps;
+	unsigned long *kcfi_traps_end;
 #endif
 
 	/* Kernel parameters. */
diff --git a/kernel/cfi.c b/kernel/cfi.c
index 2cc0d01ea980..456d5eac082a 100644
--- a/kernel/cfi.c
+++ b/kernel/cfi.c
@@ -1,94 +1,86 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Clang Control Flow Integrity (CFI) error and slowpath handling.
+ * Clang Control Flow Integrity (CFI) error handling.
  *
- * Copyright (C) 2021 Google LLC
+ * Copyright (C) 2022 Google LLC
  */
 
-#include <linux/hardirq.h>
-#include <linux/kallsyms.h>
-#include <linux/module.h>
-#include <linux/mutex.h>
-#include <linux/printk.h>
-#include <linux/ratelimit.h>
-#include <linux/rcupdate.h>
-#include <linux/vmalloc.h>
-#include <asm/cacheflush.h>
-#include <asm/set_memory.h>
-
-/* Compiler-defined handler names */
-#ifdef CONFIG_CFI_PERMISSIVE
-#define cfi_failure_handler	__ubsan_handle_cfi_check_fail
-#else
-#define cfi_failure_handler	__ubsan_handle_cfi_check_fail_abort
-#endif
-
-static inline void handle_cfi_failure(void *ptr)
-{
-	if (IS_ENABLED(CONFIG_CFI_PERMISSIVE))
-		WARN_RATELIMIT(1, "CFI failure (target: %pS):\n", ptr);
-	else
-		panic("CFI failure (target: %pS)\n", ptr);
-}
-
-#ifdef CONFIG_MODULES
+#include <linux/cfi.h>
 
-static inline cfi_check_fn find_module_check_fn(unsigned long ptr)
+enum bug_trap_type report_cfi_failure(struct pt_regs *regs, unsigned long addr,
+				      unsigned long target, unsigned long type)
 {
-	cfi_check_fn fn = NULL;
-	struct module *mod;
+	pr_err("CFI failure at %pS (target: %pS; expected type: 0x%08x)\n",
+	       (void *)addr, (void *)target, (u32)type);
 
-	rcu_read_lock_sched_notrace();
-	mod = __module_address(ptr);
-	if (mod)
-		fn = mod->cfi_check;
-	rcu_read_unlock_sched_notrace();
+	if (IS_ENABLED(CONFIG_CFI_PERMISSIVE)) {
+		__warn(NULL, 0, (void *)addr, 0, regs, NULL);
+		return BUG_TRAP_TYPE_WARN;
+	}
 
-	return fn;
+	return BUG_TRAP_TYPE_BUG;
 }
 
-static inline cfi_check_fn find_check_fn(unsigned long ptr)
+#ifdef CONFIG_ARCH_USES_CFI_TRAPS
+#ifdef CONFIG_MODULES
+/* Populates `kcfi_trap(_end)?` fields in `struct module`. */
+void module_cfi_finalize(const Elf_Ehdr *hdr, const Elf_Shdr *sechdrs,
+			 struct module *mod)
 {
-	cfi_check_fn fn = NULL;
+	char *secstrings;
+	unsigned int i;
 
-	if (is_kernel_text(ptr))
-		return __cfi_check;
+	mod->kcfi_traps = NULL;
+	mod->kcfi_traps_end = NULL;
 
-	/*
-	 * Indirect call checks can happen when RCU is not watching. Both
-	 * the shadow and __module_address use RCU, so we need to wake it
-	 * up if necessary.
-	 */
-	RCU_NONIDLE({
-		fn = find_module_check_fn(ptr);
-	});
+	secstrings = (char *)hdr + sechdrs[hdr->e_shstrndx].sh_offset;
 
-	return fn;
+	for (i = 1; i < hdr->e_shnum; i++) {
+		if (strcmp(secstrings + sechdrs[i].sh_name, "__kcfi_traps"))
+			continue;
+
+		mod->kcfi_traps = (unsigned long *)sechdrs[i].sh_addr;
+		mod->kcfi_traps_end = (unsigned long *)(sechdrs[i].sh_addr +
+							sechdrs[i].sh_size);
+		break;
+	}
 }
 
-void __cfi_slowpath_diag(uint64_t id, void *ptr, void *diag)
+static bool is_module_cfi_trap(unsigned long addr)
 {
-	cfi_check_fn fn = find_check_fn((unsigned long)ptr);
+	bool found = false;
+	struct module *mod;
+	unsigned long *p;
 
-	if (likely(fn))
-		fn(id, ptr, diag);
-	else /* Don't allow unchecked modules */
-		handle_cfi_failure(ptr);
-}
-EXPORT_SYMBOL(__cfi_slowpath_diag);
+	rcu_read_lock_sched_notrace();
 
-#else /* !CONFIG_MODULES */
+	mod = __module_address(addr);
+	if (mod)
+		for (p = mod->kcfi_traps; !found && p < mod->kcfi_traps_end; ++p)
+			found = (*p == addr);
+
+	rcu_read_unlock_sched_notrace();
 
-void __cfi_slowpath_diag(uint64_t id, void *ptr, void *diag)
+	return found;
+}
+#else /* CONFIG_MODULES */
+static inline bool is_module_cfi_trap(unsigned long addr)
 {
-	handle_cfi_failure(ptr); /* No modules */
+	return false;
 }
-EXPORT_SYMBOL(__cfi_slowpath_diag);
-
 #endif /* CONFIG_MODULES */
 
-void cfi_failure_handler(void *data, void *ptr, void *vtable)
+extern unsigned long __start___kcfi_traps[];
+extern unsigned long __stop___kcfi_traps[];
+
+bool is_cfi_trap(unsigned long addr)
 {
-	handle_cfi_failure(ptr);
+	unsigned long *p;
+
+	for (p = __start___kcfi_traps; p < __stop___kcfi_traps; ++p)
+		if (*p == addr)
+			return true;
+
+	return is_module_cfi_trap(addr);
 }
-EXPORT_SYMBOL(cfi_failure_handler);
+#endif /* CONFIG_ARCH_USES_CFI_TRAPS */
diff --git a/kernel/module.c b/kernel/module.c
index 296fe02323e9..411ae8c358e6 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -57,6 +57,7 @@
 #include <linux/bsearch.h>
 #include <linux/dynamic_debug.h>
 #include <linux/audit.h>
+#include <linux/cfi.h>
 #include <uapi/linux/module.h>
 #include "module-internal.h"
 
@@ -3871,8 +3872,9 @@ static int complete_formation(struct module *mod, struct load_info *info)
 	if (err < 0)
 		goto out;
 
-	/* This relies on module_mutex for list integrity. */
+	/* These rely on module_mutex for list integrity. */
 	module_bug_finalize(info->hdr, info->sechdrs, mod);
+	module_cfi_finalize(info->hdr, info->sechdrs, mod);
 
 	module_enable_ro(mod, false);
 	module_enable_nx(mod);
@@ -3928,8 +3930,6 @@ static int unknown_module_param_cb(char *param, char *val, const char *modname,
 	return 0;
 }
 
-static void cfi_init(struct module *mod);
-
 /*
  * Allocate and load the module: note that size of section 0 is always
  * zero, and we rely on this for optional sections.
@@ -4059,9 +4059,6 @@ static int load_module(struct load_info *info, const char __user *uargs,
 
 	flush_module_icache(mod);
 
-	/* Setup CFI for the module. */
-	cfi_init(mod);
-
 	/* Now copy in args */
 	mod->args = strndup_user(uargs, ~0UL >> 1);
 	if (IS_ERR(mod->args)) {
@@ -4502,31 +4499,6 @@ int module_kallsyms_on_each_symbol(int (*fn)(void *, const char *,
 #endif /* CONFIG_LIVEPATCH */
 #endif /* CONFIG_KALLSYMS */
 
-static void cfi_init(struct module *mod)
-{
-#ifdef CONFIG_CFI_CLANG
-	initcall_t *init;
-	exitcall_t *exit;
-
-	rcu_read_lock_sched();
-	mod->cfi_check = (cfi_check_fn)
-		find_kallsyms_symbol_value(mod, "__cfi_check");
-	init = (initcall_t *)
-		find_kallsyms_symbol_value(mod, "__cfi_jt_init_module");
-	exit = (exitcall_t *)
-		find_kallsyms_symbol_value(mod, "__cfi_jt_cleanup_module");
-	rcu_read_unlock_sched();
-
-	/* Fix init/exit functions to point to the CFI jump table */
-	if (init)
-		mod->init = *init;
-#ifdef CONFIG_MODULE_UNLOAD
-	if (exit)
-		mod->exit = *exit;
-#endif
-#endif
-}
-
 /* Maximum number of characters written by module_flags() */
 #define MODULE_FLAGS_BUF_SIZE (TAINT_FLAGS_COUNT + 4)
 
diff --git a/scripts/module.lds.S b/scripts/module.lds.S
index 1d0e1e4dc3d2..0708896139cc 100644
--- a/scripts/module.lds.S
+++ b/scripts/module.lds.S
@@ -3,20 +3,10 @@
  * Archs are free to supply their own linker scripts.  ld will
  * combine them automatically.
  */
-#ifdef CONFIG_CFI_CLANG
-# include <asm/page.h>
-# define ALIGN_CFI 		ALIGN(PAGE_SIZE)
-# define SANITIZER_DISCARDS	*(.eh_frame)
-#else
-# define ALIGN_CFI
-# define SANITIZER_DISCARDS
-#endif
-
 SECTIONS {
 	/DISCARD/ : {
 		*(.discard)
 		*(.discard.*)
-		SANITIZER_DISCARDS
 	}
 
 	__ksymtab		0 : { *(SORT(___ksymtab+*)) }
@@ -31,6 +21,10 @@ SECTIONS {
 
 	__patchable_function_entries : { *(__patchable_function_entries) }
 
+#ifdef CONFIG_ARCH_USES_CFI_TRAPS
+	__kcfi_traps 		: { KEEP(*(.kcfi_traps)) }
+#endif
+
 #ifdef CONFIG_LTO_CLANG
 	/*
 	 * With CONFIG_LTO_CLANG, LLD always enables -fdata-sections and
@@ -51,15 +45,6 @@ SECTIONS {
 		*(.rodata .rodata.[0-9a-zA-Z_]*)
 		*(.rodata..L*)
 	}
-
-	/*
-	 * With CONFIG_CFI_CLANG, we assume __cfi_check is at the beginning
-	 * of the .text section, and is aligned to PAGE_SIZE.
-	 */
-	.text : ALIGN_CFI {
-		*(.text.__cfi_check)
-		*(.text .text.[0-9a-zA-Z_]* .text..L.cfi*)
-	}
 #endif
 }
 
-- 
2.36.0.550.gb090851708-goog


_______________________________________________
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] 174+ messages in thread

* [RFC PATCH v2 07/21] cfi: Add type helper macros
  2022-05-13 20:21 ` Sami Tolvanen
@ 2022-05-13 20:21   ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

With CONFIG_CFI_CLANG, assembly functions called indirectly
from C code must be annotated with type identifiers to pass CFI
checking. The compiler emits a __kcfi_typeid_<function> symbol for
each address-taken function declaration in C, which contains the
expected type identifier. Add typed versions of SYM_FUNC_START and
SYM_FUNC_START_ALIAS, which emit the type identifier before the
function.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 include/linux/cfi_types.h | 57 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 57 insertions(+)
 create mode 100644 include/linux/cfi_types.h

diff --git a/include/linux/cfi_types.h b/include/linux/cfi_types.h
new file mode 100644
index 000000000000..dd16e755a197
--- /dev/null
+++ b/include/linux/cfi_types.h
@@ -0,0 +1,57 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Clang Control Flow Integrity (CFI) type definitions.
+ */
+#ifndef _LINUX_CFI_TYPES_H
+#define _LINUX_CFI_TYPES_H
+
+#ifdef CONFIG_CFI_CLANG
+#include <linux/linkage.h>
+
+#ifdef __ASSEMBLY__
+/*
+ * Use the __kcfi_typeid_<function> type identifier symbol to
+ * annotate indirectly called assembly functions. The compiler emits
+ * these symbols for all address-taken function declarations in C
+ * code.
+ */
+#ifndef __CFI_TYPE
+#define __CFI_TYPE(name)				\
+	.4byte __kcfi_typeid_##name
+#endif
+
+#define SYM_TYPED_ENTRY(name, fname, linkage, align...)	\
+	linkage(name) ASM_NL				\
+	align ASM_NL					\
+	__CFI_TYPE(fname) ASM_NL			\
+	name:
+
+#define __SYM_TYPED_FUNC_START_ALIAS(name, fname) \
+	SYM_TYPED_ENTRY(name, fname, SYM_L_GLOBAL, SYM_A_ALIGN)
+
+#define __SYM_TYPED_FUNC_START(name, fname) \
+	SYM_TYPED_ENTRY(name, fname, SYM_L_GLOBAL, SYM_A_ALIGN)
+
+#endif /* __ASSEMBLY__ */
+
+#else /* CONFIG_CFI_CLANG */
+
+#ifdef __ASSEMBLY__
+#define __SYM_TYPED_FUNC_START_ALIAS(name, fname) \
+	SYM_FUNC_START_ALIAS(name)
+
+#define __SYM_TYPED_FUNC_START(name, fname) \
+	SYM_FUNC_START(name)
+#endif /* __ASSEMBLY__ */
+
+#endif /* CONFIG_CFI_CLANG */
+
+#ifdef __ASSEMBLY__
+#define SYM_TYPED_FUNC_START_ALIAS(name) \
+	__SYM_TYPED_FUNC_START_ALIAS(name, name)
+
+#define SYM_TYPED_FUNC_START(name) \
+	__SYM_TYPED_FUNC_START(name, name)
+#endif /* __ASSEMBLY__ */
+
+#endif /* _LINUX_CFI_TYPES_H */
-- 
2.36.0.550.gb090851708-goog


^ permalink raw reply	[flat|nested] 174+ messages in thread

* [RFC PATCH v2 07/21] cfi: Add type helper macros
@ 2022-05-13 20:21   ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

With CONFIG_CFI_CLANG, assembly functions called indirectly
from C code must be annotated with type identifiers to pass CFI
checking. The compiler emits a __kcfi_typeid_<function> symbol for
each address-taken function declaration in C, which contains the
expected type identifier. Add typed versions of SYM_FUNC_START and
SYM_FUNC_START_ALIAS, which emit the type identifier before the
function.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 include/linux/cfi_types.h | 57 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 57 insertions(+)
 create mode 100644 include/linux/cfi_types.h

diff --git a/include/linux/cfi_types.h b/include/linux/cfi_types.h
new file mode 100644
index 000000000000..dd16e755a197
--- /dev/null
+++ b/include/linux/cfi_types.h
@@ -0,0 +1,57 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Clang Control Flow Integrity (CFI) type definitions.
+ */
+#ifndef _LINUX_CFI_TYPES_H
+#define _LINUX_CFI_TYPES_H
+
+#ifdef CONFIG_CFI_CLANG
+#include <linux/linkage.h>
+
+#ifdef __ASSEMBLY__
+/*
+ * Use the __kcfi_typeid_<function> type identifier symbol to
+ * annotate indirectly called assembly functions. The compiler emits
+ * these symbols for all address-taken function declarations in C
+ * code.
+ */
+#ifndef __CFI_TYPE
+#define __CFI_TYPE(name)				\
+	.4byte __kcfi_typeid_##name
+#endif
+
+#define SYM_TYPED_ENTRY(name, fname, linkage, align...)	\
+	linkage(name) ASM_NL				\
+	align ASM_NL					\
+	__CFI_TYPE(fname) ASM_NL			\
+	name:
+
+#define __SYM_TYPED_FUNC_START_ALIAS(name, fname) \
+	SYM_TYPED_ENTRY(name, fname, SYM_L_GLOBAL, SYM_A_ALIGN)
+
+#define __SYM_TYPED_FUNC_START(name, fname) \
+	SYM_TYPED_ENTRY(name, fname, SYM_L_GLOBAL, SYM_A_ALIGN)
+
+#endif /* __ASSEMBLY__ */
+
+#else /* CONFIG_CFI_CLANG */
+
+#ifdef __ASSEMBLY__
+#define __SYM_TYPED_FUNC_START_ALIAS(name, fname) \
+	SYM_FUNC_START_ALIAS(name)
+
+#define __SYM_TYPED_FUNC_START(name, fname) \
+	SYM_FUNC_START(name)
+#endif /* __ASSEMBLY__ */
+
+#endif /* CONFIG_CFI_CLANG */
+
+#ifdef __ASSEMBLY__
+#define SYM_TYPED_FUNC_START_ALIAS(name) \
+	__SYM_TYPED_FUNC_START_ALIAS(name, name)
+
+#define SYM_TYPED_FUNC_START(name) \
+	__SYM_TYPED_FUNC_START(name, name)
+#endif /* __ASSEMBLY__ */
+
+#endif /* _LINUX_CFI_TYPES_H */
-- 
2.36.0.550.gb090851708-goog


_______________________________________________
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] 174+ messages in thread

* [RFC PATCH v2 08/21] psci: Fix the function type for psci_initcall_t
  2022-05-13 20:21 ` Sami Tolvanen
@ 2022-05-13 20:21   ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

Functions called through a psci_initcall_t pointer all have
non-const arguments. Fix the type definition to avoid tripping
indirect call checks with CFI_CLANG.

Reported-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 drivers/firmware/psci/psci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
index cfb448eabdaa..6554bf4b8c99 100644
--- a/drivers/firmware/psci/psci.c
+++ b/drivers/firmware/psci/psci.c
@@ -521,7 +521,7 @@ static int __init psci_probe(void)
 	return 0;
 }
 
-typedef int (*psci_initcall_t)(const struct device_node *);
+typedef int (*psci_initcall_t)(struct device_node *);
 
 /*
  * PSCI init function for PSCI versions >=0.2
-- 
2.36.0.550.gb090851708-goog


^ permalink raw reply	[flat|nested] 174+ messages in thread

* [RFC PATCH v2 08/21] psci: Fix the function type for psci_initcall_t
@ 2022-05-13 20:21   ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

Functions called through a psci_initcall_t pointer all have
non-const arguments. Fix the type definition to avoid tripping
indirect call checks with CFI_CLANG.

Reported-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 drivers/firmware/psci/psci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
index cfb448eabdaa..6554bf4b8c99 100644
--- a/drivers/firmware/psci/psci.c
+++ b/drivers/firmware/psci/psci.c
@@ -521,7 +521,7 @@ static int __init psci_probe(void)
 	return 0;
 }
 
-typedef int (*psci_initcall_t)(const struct device_node *);
+typedef int (*psci_initcall_t)(struct device_node *);
 
 /*
  * PSCI init function for PSCI versions >=0.2
-- 
2.36.0.550.gb090851708-goog


_______________________________________________
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] 174+ messages in thread

* [RFC PATCH v2 09/21] arm64: Add types to indirect called assembly functions
  2022-05-13 20:21 ` Sami Tolvanen
@ 2022-05-13 20:21   ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

With CONFIG_CFI_CLANG, assembly functions indirectly called from C
code must be annotated with type identifiers to pass CFI checking. Use
SYM_TYPED_FUNC_START for indirectly called functions.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/arm64/crypto/ghash-ce-core.S | 5 +++--
 arch/arm64/crypto/sm3-ce-core.S   | 3 ++-
 arch/arm64/kernel/cpu-reset.S     | 5 +++--
 arch/arm64/mm/proc.S              | 5 +++--
 4 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/crypto/ghash-ce-core.S b/arch/arm64/crypto/ghash-ce-core.S
index 7868330dd54e..ebe5558929b7 100644
--- a/arch/arm64/crypto/ghash-ce-core.S
+++ b/arch/arm64/crypto/ghash-ce-core.S
@@ -6,6 +6,7 @@
  */
 
 #include <linux/linkage.h>
+#include <linux/cfi_types.h>
 #include <asm/assembler.h>
 
 	SHASH		.req	v0
@@ -350,11 +351,11 @@ CPU_LE(	rev64		T1.16b, T1.16b	)
 	 * void pmull_ghash_update(int blocks, u64 dg[], const char *src,
 	 *			   struct ghash_key const *k, const char *head)
 	 */
-SYM_FUNC_START(pmull_ghash_update_p64)
+SYM_TYPED_FUNC_START(pmull_ghash_update_p64)
 	__pmull_ghash	p64
 SYM_FUNC_END(pmull_ghash_update_p64)
 
-SYM_FUNC_START(pmull_ghash_update_p8)
+SYM_TYPED_FUNC_START(pmull_ghash_update_p8)
 	__pmull_ghash	p8
 SYM_FUNC_END(pmull_ghash_update_p8)
 
diff --git a/arch/arm64/crypto/sm3-ce-core.S b/arch/arm64/crypto/sm3-ce-core.S
index ef97d3187cb7..ca70cfacd0d0 100644
--- a/arch/arm64/crypto/sm3-ce-core.S
+++ b/arch/arm64/crypto/sm3-ce-core.S
@@ -6,6 +6,7 @@
  */
 
 #include <linux/linkage.h>
+#include <linux/cfi_types.h>
 #include <asm/assembler.h>
 
 	.irp		b, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
@@ -73,7 +74,7 @@
 	 *                       int blocks)
 	 */
 	.text
-SYM_FUNC_START(sm3_ce_transform)
+SYM_TYPED_FUNC_START(sm3_ce_transform)
 	/* load state */
 	ld1		{v8.4s-v9.4s}, [x0]
 	rev64		v8.4s, v8.4s
diff --git a/arch/arm64/kernel/cpu-reset.S b/arch/arm64/kernel/cpu-reset.S
index 48a8af97faa9..6b752fe89745 100644
--- a/arch/arm64/kernel/cpu-reset.S
+++ b/arch/arm64/kernel/cpu-reset.S
@@ -8,6 +8,7 @@
  */
 
 #include <linux/linkage.h>
+#include <linux/cfi_types.h>
 #include <asm/assembler.h>
 #include <asm/sysreg.h>
 #include <asm/virt.h>
@@ -28,7 +29,7 @@
  * branch to what would be the reset vector. It must be executed with the
  * flat identity mapping.
  */
-SYM_CODE_START(cpu_soft_restart)
+SYM_TYPED_FUNC_START(cpu_soft_restart)
 	mov_q	x12, INIT_SCTLR_EL1_MMU_OFF
 	pre_disable_mmu_workaround
 	/*
@@ -47,6 +48,6 @@ SYM_CODE_START(cpu_soft_restart)
 	mov	x1, x3				// arg1
 	mov	x2, x4				// arg2
 	br	x8
-SYM_CODE_END(cpu_soft_restart)
+SYM_FUNC_END(cpu_soft_restart)
 
 .popsection
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 50bbed947bec..dfa715315551 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -10,6 +10,7 @@
 #include <linux/init.h>
 #include <linux/linkage.h>
 #include <linux/pgtable.h>
+#include <linux/cfi_types.h>
 #include <asm/assembler.h>
 #include <asm/asm-offsets.h>
 #include <asm/asm_pointer_auth.h>
@@ -184,7 +185,7 @@ SYM_FUNC_END(cpu_do_resume)
  * This is the low-level counterpart to cpu_replace_ttbr1, and should not be
  * called by anything else. It can only be executed from a TTBR0 mapping.
  */
-SYM_FUNC_START(idmap_cpu_replace_ttbr1)
+SYM_TYPED_FUNC_START(idmap_cpu_replace_ttbr1)
 	save_and_disable_daif flags=x2
 
 	__idmap_cpu_set_reserved_ttbr1 x1, x3
@@ -224,7 +225,7 @@ SYM_FUNC_END(idmap_cpu_replace_ttbr1)
  */
 __idmap_kpti_flag:
 	.long	1
-SYM_FUNC_START(idmap_kpti_install_ng_mappings)
+SYM_TYPED_FUNC_START(idmap_kpti_install_ng_mappings)
 	cpu		.req	w0
 	num_cpus	.req	w1
 	swapper_pa	.req	x2
-- 
2.36.0.550.gb090851708-goog


^ permalink raw reply	[flat|nested] 174+ messages in thread

* [RFC PATCH v2 09/21] arm64: Add types to indirect called assembly functions
@ 2022-05-13 20:21   ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

With CONFIG_CFI_CLANG, assembly functions indirectly called from C
code must be annotated with type identifiers to pass CFI checking. Use
SYM_TYPED_FUNC_START for indirectly called functions.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/arm64/crypto/ghash-ce-core.S | 5 +++--
 arch/arm64/crypto/sm3-ce-core.S   | 3 ++-
 arch/arm64/kernel/cpu-reset.S     | 5 +++--
 arch/arm64/mm/proc.S              | 5 +++--
 4 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/crypto/ghash-ce-core.S b/arch/arm64/crypto/ghash-ce-core.S
index 7868330dd54e..ebe5558929b7 100644
--- a/arch/arm64/crypto/ghash-ce-core.S
+++ b/arch/arm64/crypto/ghash-ce-core.S
@@ -6,6 +6,7 @@
  */
 
 #include <linux/linkage.h>
+#include <linux/cfi_types.h>
 #include <asm/assembler.h>
 
 	SHASH		.req	v0
@@ -350,11 +351,11 @@ CPU_LE(	rev64		T1.16b, T1.16b	)
 	 * void pmull_ghash_update(int blocks, u64 dg[], const char *src,
 	 *			   struct ghash_key const *k, const char *head)
 	 */
-SYM_FUNC_START(pmull_ghash_update_p64)
+SYM_TYPED_FUNC_START(pmull_ghash_update_p64)
 	__pmull_ghash	p64
 SYM_FUNC_END(pmull_ghash_update_p64)
 
-SYM_FUNC_START(pmull_ghash_update_p8)
+SYM_TYPED_FUNC_START(pmull_ghash_update_p8)
 	__pmull_ghash	p8
 SYM_FUNC_END(pmull_ghash_update_p8)
 
diff --git a/arch/arm64/crypto/sm3-ce-core.S b/arch/arm64/crypto/sm3-ce-core.S
index ef97d3187cb7..ca70cfacd0d0 100644
--- a/arch/arm64/crypto/sm3-ce-core.S
+++ b/arch/arm64/crypto/sm3-ce-core.S
@@ -6,6 +6,7 @@
  */
 
 #include <linux/linkage.h>
+#include <linux/cfi_types.h>
 #include <asm/assembler.h>
 
 	.irp		b, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
@@ -73,7 +74,7 @@
 	 *                       int blocks)
 	 */
 	.text
-SYM_FUNC_START(sm3_ce_transform)
+SYM_TYPED_FUNC_START(sm3_ce_transform)
 	/* load state */
 	ld1		{v8.4s-v9.4s}, [x0]
 	rev64		v8.4s, v8.4s
diff --git a/arch/arm64/kernel/cpu-reset.S b/arch/arm64/kernel/cpu-reset.S
index 48a8af97faa9..6b752fe89745 100644
--- a/arch/arm64/kernel/cpu-reset.S
+++ b/arch/arm64/kernel/cpu-reset.S
@@ -8,6 +8,7 @@
  */
 
 #include <linux/linkage.h>
+#include <linux/cfi_types.h>
 #include <asm/assembler.h>
 #include <asm/sysreg.h>
 #include <asm/virt.h>
@@ -28,7 +29,7 @@
  * branch to what would be the reset vector. It must be executed with the
  * flat identity mapping.
  */
-SYM_CODE_START(cpu_soft_restart)
+SYM_TYPED_FUNC_START(cpu_soft_restart)
 	mov_q	x12, INIT_SCTLR_EL1_MMU_OFF
 	pre_disable_mmu_workaround
 	/*
@@ -47,6 +48,6 @@ SYM_CODE_START(cpu_soft_restart)
 	mov	x1, x3				// arg1
 	mov	x2, x4				// arg2
 	br	x8
-SYM_CODE_END(cpu_soft_restart)
+SYM_FUNC_END(cpu_soft_restart)
 
 .popsection
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 50bbed947bec..dfa715315551 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -10,6 +10,7 @@
 #include <linux/init.h>
 #include <linux/linkage.h>
 #include <linux/pgtable.h>
+#include <linux/cfi_types.h>
 #include <asm/assembler.h>
 #include <asm/asm-offsets.h>
 #include <asm/asm_pointer_auth.h>
@@ -184,7 +185,7 @@ SYM_FUNC_END(cpu_do_resume)
  * This is the low-level counterpart to cpu_replace_ttbr1, and should not be
  * called by anything else. It can only be executed from a TTBR0 mapping.
  */
-SYM_FUNC_START(idmap_cpu_replace_ttbr1)
+SYM_TYPED_FUNC_START(idmap_cpu_replace_ttbr1)
 	save_and_disable_daif flags=x2
 
 	__idmap_cpu_set_reserved_ttbr1 x1, x3
@@ -224,7 +225,7 @@ SYM_FUNC_END(idmap_cpu_replace_ttbr1)
  */
 __idmap_kpti_flag:
 	.long	1
-SYM_FUNC_START(idmap_kpti_install_ng_mappings)
+SYM_TYPED_FUNC_START(idmap_kpti_install_ng_mappings)
 	cpu		.req	w0
 	num_cpus	.req	w1
 	swapper_pa	.req	x2
-- 
2.36.0.550.gb090851708-goog


_______________________________________________
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] 174+ messages in thread

* [RFC PATCH v2 10/21] arm64: Add CFI error handling
  2022-05-13 20:21 ` Sami Tolvanen
@ 2022-05-13 20:21   ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

With -fsanitize=kcfi, CFI always traps. Add arm64 support for handling
CFI failures. The registers containing the target address and the
expected type are encoded in the first ten bits of the ESR as follows:

 - 0-4: n, where the register Xn contains the target address
 - 5-9: m, where the register Wm contains the type hash

Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/arm64/include/asm/brk-imm.h |  6 +++++
 arch/arm64/kernel/traps.c        | 46 +++++++++++++++++++++++++++++---
 2 files changed, 49 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/brk-imm.h b/arch/arm64/include/asm/brk-imm.h
index ec7720dbe2c8..6e000113e508 100644
--- a/arch/arm64/include/asm/brk-imm.h
+++ b/arch/arm64/include/asm/brk-imm.h
@@ -17,6 +17,7 @@
  * 0x401: for compile time BRK instruction
  * 0x800: kernel-mode BUG() and WARN() traps
  * 0x9xx: tag-based KASAN trap (allowed values 0x900 - 0x9ff)
+ * 0x8xxx: Control-Flow Integrity traps
  */
 #define KPROBES_BRK_IMM			0x004
 #define UPROBES_BRK_IMM			0x005
@@ -28,4 +29,9 @@
 #define KASAN_BRK_IMM			0x900
 #define KASAN_BRK_MASK			0x0ff
 
+#define CFI_BRK_IMM_TARGET		GENMASK(4, 0)
+#define CFI_BRK_IMM_TYPE		GENMASK(9, 5)
+#define CFI_BRK_IMM_BASE		0x8000
+#define CFI_BRK_IMM_MASK		(CFI_BRK_IMM_TARGET | CFI_BRK_IMM_TYPE)
+
 #endif
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 0529fd57567e..17b083b683f4 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -26,6 +26,7 @@
 #include <linux/syscalls.h>
 #include <linux/mm_types.h>
 #include <linux/kasan.h>
+#include <linux/cfi.h>
 
 #include <asm/atomic.h>
 #include <asm/bug.h>
@@ -990,6 +991,37 @@ static struct break_hook bug_break_hook = {
 	.imm = BUG_BRK_IMM,
 };
 
+#ifdef CONFIG_CFI_CLANG
+static int cfi_handler(struct pt_regs *regs, unsigned int esr)
+{
+	unsigned long target, type;
+
+	target = pt_regs_read_reg(regs, FIELD_GET(CFI_BRK_IMM_TARGET, esr));
+	type = pt_regs_read_reg(regs, FIELD_GET(CFI_BRK_IMM_TYPE, esr));
+
+	switch (report_cfi_failure(regs, regs->pc, target, type)) {
+	case BUG_TRAP_TYPE_BUG:
+		die("Oops - CFI", regs, 0);
+		break;
+
+	case BUG_TRAP_TYPE_WARN:
+		break;
+
+	default:
+		return DBG_HOOK_ERROR;
+	}
+
+	arm64_skip_faulting_instruction(regs, AARCH64_INSN_SIZE);
+	return DBG_HOOK_HANDLED;
+}
+
+static struct break_hook cfi_break_hook = {
+	.fn = cfi_handler,
+	.imm = CFI_BRK_IMM_BASE,
+	.mask = CFI_BRK_IMM_MASK,
+};
+#endif /* CONFIG_CFI_CLANG */
+
 static int reserved_fault_handler(struct pt_regs *regs, unsigned int esr)
 {
 	pr_err("%s generated an invalid instruction at %pS!\n",
@@ -1051,6 +1083,9 @@ static struct break_hook kasan_break_hook = {
 };
 #endif
 
+
+#define esr_comment(esr) ((esr) & ESR_ELx_BRK64_ISS_COMMENT_MASK)
+
 /*
  * Initial handler for AArch64 BRK exceptions
  * This handler only used until debug_traps_init().
@@ -1058,10 +1093,12 @@ static struct break_hook kasan_break_hook = {
 int __init early_brk64(unsigned long addr, unsigned int esr,
 		struct pt_regs *regs)
 {
+#ifdef CONFIG_CFI_CLANG
+	if ((esr_comment(esr) & ~CFI_BRK_IMM_MASK) == CFI_BRK_IMM_BASE)
+		return cfi_handler(regs, esr) != DBG_HOOK_HANDLED;
+#endif
 #ifdef CONFIG_KASAN_SW_TAGS
-	unsigned int comment = esr & ESR_ELx_BRK64_ISS_COMMENT_MASK;
-
-	if ((comment & ~KASAN_BRK_MASK) == KASAN_BRK_IMM)
+	if ((esr_comment(esr) & ~KASAN_BRK_MASK) == KASAN_BRK_IMM)
 		return kasan_handler(regs, esr) != DBG_HOOK_HANDLED;
 #endif
 	return bug_handler(regs, esr) != DBG_HOOK_HANDLED;
@@ -1070,6 +1107,9 @@ int __init early_brk64(unsigned long addr, unsigned int esr,
 void __init trap_init(void)
 {
 	register_kernel_break_hook(&bug_break_hook);
+#ifdef CONFIG_CFI_CLANG
+	register_kernel_break_hook(&cfi_break_hook);
+#endif
 	register_kernel_break_hook(&fault_break_hook);
 #ifdef CONFIG_KASAN_SW_TAGS
 	register_kernel_break_hook(&kasan_break_hook);
-- 
2.36.0.550.gb090851708-goog


^ permalink raw reply	[flat|nested] 174+ messages in thread

* [RFC PATCH v2 10/21] arm64: Add CFI error handling
@ 2022-05-13 20:21   ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

With -fsanitize=kcfi, CFI always traps. Add arm64 support for handling
CFI failures. The registers containing the target address and the
expected type are encoded in the first ten bits of the ESR as follows:

 - 0-4: n, where the register Xn contains the target address
 - 5-9: m, where the register Wm contains the type hash

Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/arm64/include/asm/brk-imm.h |  6 +++++
 arch/arm64/kernel/traps.c        | 46 +++++++++++++++++++++++++++++---
 2 files changed, 49 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/brk-imm.h b/arch/arm64/include/asm/brk-imm.h
index ec7720dbe2c8..6e000113e508 100644
--- a/arch/arm64/include/asm/brk-imm.h
+++ b/arch/arm64/include/asm/brk-imm.h
@@ -17,6 +17,7 @@
  * 0x401: for compile time BRK instruction
  * 0x800: kernel-mode BUG() and WARN() traps
  * 0x9xx: tag-based KASAN trap (allowed values 0x900 - 0x9ff)
+ * 0x8xxx: Control-Flow Integrity traps
  */
 #define KPROBES_BRK_IMM			0x004
 #define UPROBES_BRK_IMM			0x005
@@ -28,4 +29,9 @@
 #define KASAN_BRK_IMM			0x900
 #define KASAN_BRK_MASK			0x0ff
 
+#define CFI_BRK_IMM_TARGET		GENMASK(4, 0)
+#define CFI_BRK_IMM_TYPE		GENMASK(9, 5)
+#define CFI_BRK_IMM_BASE		0x8000
+#define CFI_BRK_IMM_MASK		(CFI_BRK_IMM_TARGET | CFI_BRK_IMM_TYPE)
+
 #endif
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 0529fd57567e..17b083b683f4 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -26,6 +26,7 @@
 #include <linux/syscalls.h>
 #include <linux/mm_types.h>
 #include <linux/kasan.h>
+#include <linux/cfi.h>
 
 #include <asm/atomic.h>
 #include <asm/bug.h>
@@ -990,6 +991,37 @@ static struct break_hook bug_break_hook = {
 	.imm = BUG_BRK_IMM,
 };
 
+#ifdef CONFIG_CFI_CLANG
+static int cfi_handler(struct pt_regs *regs, unsigned int esr)
+{
+	unsigned long target, type;
+
+	target = pt_regs_read_reg(regs, FIELD_GET(CFI_BRK_IMM_TARGET, esr));
+	type = pt_regs_read_reg(regs, FIELD_GET(CFI_BRK_IMM_TYPE, esr));
+
+	switch (report_cfi_failure(regs, regs->pc, target, type)) {
+	case BUG_TRAP_TYPE_BUG:
+		die("Oops - CFI", regs, 0);
+		break;
+
+	case BUG_TRAP_TYPE_WARN:
+		break;
+
+	default:
+		return DBG_HOOK_ERROR;
+	}
+
+	arm64_skip_faulting_instruction(regs, AARCH64_INSN_SIZE);
+	return DBG_HOOK_HANDLED;
+}
+
+static struct break_hook cfi_break_hook = {
+	.fn = cfi_handler,
+	.imm = CFI_BRK_IMM_BASE,
+	.mask = CFI_BRK_IMM_MASK,
+};
+#endif /* CONFIG_CFI_CLANG */
+
 static int reserved_fault_handler(struct pt_regs *regs, unsigned int esr)
 {
 	pr_err("%s generated an invalid instruction at %pS!\n",
@@ -1051,6 +1083,9 @@ static struct break_hook kasan_break_hook = {
 };
 #endif
 
+
+#define esr_comment(esr) ((esr) & ESR_ELx_BRK64_ISS_COMMENT_MASK)
+
 /*
  * Initial handler for AArch64 BRK exceptions
  * This handler only used until debug_traps_init().
@@ -1058,10 +1093,12 @@ static struct break_hook kasan_break_hook = {
 int __init early_brk64(unsigned long addr, unsigned int esr,
 		struct pt_regs *regs)
 {
+#ifdef CONFIG_CFI_CLANG
+	if ((esr_comment(esr) & ~CFI_BRK_IMM_MASK) == CFI_BRK_IMM_BASE)
+		return cfi_handler(regs, esr) != DBG_HOOK_HANDLED;
+#endif
 #ifdef CONFIG_KASAN_SW_TAGS
-	unsigned int comment = esr & ESR_ELx_BRK64_ISS_COMMENT_MASK;
-
-	if ((comment & ~KASAN_BRK_MASK) == KASAN_BRK_IMM)
+	if ((esr_comment(esr) & ~KASAN_BRK_MASK) == KASAN_BRK_IMM)
 		return kasan_handler(regs, esr) != DBG_HOOK_HANDLED;
 #endif
 	return bug_handler(regs, esr) != DBG_HOOK_HANDLED;
@@ -1070,6 +1107,9 @@ int __init early_brk64(unsigned long addr, unsigned int esr,
 void __init trap_init(void)
 {
 	register_kernel_break_hook(&bug_break_hook);
+#ifdef CONFIG_CFI_CLANG
+	register_kernel_break_hook(&cfi_break_hook);
+#endif
 	register_kernel_break_hook(&fault_break_hook);
 #ifdef CONFIG_KASAN_SW_TAGS
 	register_kernel_break_hook(&kasan_break_hook);
-- 
2.36.0.550.gb090851708-goog


_______________________________________________
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] 174+ messages in thread

* [RFC PATCH v2 11/21] arm64: Drop unneeded __nocfi attributes
  2022-05-13 20:21 ` Sami Tolvanen
@ 2022-05-13 20:21   ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

With -fsanitize=kcfi, CONFIG_CFI_CLANG no longer has issues
with address space confusion in functions that switch to linear
mapping. Now that the indirectly called assembly functions have
type annotations, drop the __nocfi attributes.

Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/arm64/include/asm/mmu_context.h | 2 +-
 arch/arm64/kernel/alternative.c      | 2 +-
 arch/arm64/kernel/cpufeature.c       | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
index 6770667b34a3..ca0140d0b8cf 100644
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -143,7 +143,7 @@ static inline void cpu_install_ttbr0(phys_addr_t ttbr0, unsigned long t0sz)
  * Atomically replaces the active TTBR1_EL1 PGD with a new VA-compatible PGD,
  * avoiding the possibility of conflicting TLB entries being allocated.
  */
-static inline void __nocfi cpu_replace_ttbr1(pgd_t *pgdp)
+static inline void cpu_replace_ttbr1(pgd_t *pgdp)
 {
 	typedef void (ttbr_replace_func)(phys_addr_t);
 	extern ttbr_replace_func idmap_cpu_replace_ttbr1;
diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c
index 7bbf5104b7b7..e98466bab633 100644
--- a/arch/arm64/kernel/alternative.c
+++ b/arch/arm64/kernel/alternative.c
@@ -133,7 +133,7 @@ static void clean_dcache_range_nopatch(u64 start, u64 end)
 	} while (cur += d_size, cur < end);
 }
 
-static void __nocfi __apply_alternatives(struct alt_region *region, bool is_module,
+static void __apply_alternatives(struct alt_region *region, bool is_module,
 				 unsigned long *feature_mask)
 {
 	struct alt_instr *alt;
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index d72c4b4d389c..af78dcacf9fe 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1596,7 +1596,7 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
 }
 
 #ifdef CONFIG_UNMAP_KERNEL_AT_EL0
-static void __nocfi
+static void
 kpti_install_ng_mappings(const struct arm64_cpu_capabilities *__unused)
 {
 	typedef void (kpti_remap_fn)(int, int, phys_addr_t);
-- 
2.36.0.550.gb090851708-goog


^ permalink raw reply	[flat|nested] 174+ messages in thread

* [RFC PATCH v2 11/21] arm64: Drop unneeded __nocfi attributes
@ 2022-05-13 20:21   ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

With -fsanitize=kcfi, CONFIG_CFI_CLANG no longer has issues
with address space confusion in functions that switch to linear
mapping. Now that the indirectly called assembly functions have
type annotations, drop the __nocfi attributes.

Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/arm64/include/asm/mmu_context.h | 2 +-
 arch/arm64/kernel/alternative.c      | 2 +-
 arch/arm64/kernel/cpufeature.c       | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
index 6770667b34a3..ca0140d0b8cf 100644
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -143,7 +143,7 @@ static inline void cpu_install_ttbr0(phys_addr_t ttbr0, unsigned long t0sz)
  * Atomically replaces the active TTBR1_EL1 PGD with a new VA-compatible PGD,
  * avoiding the possibility of conflicting TLB entries being allocated.
  */
-static inline void __nocfi cpu_replace_ttbr1(pgd_t *pgdp)
+static inline void cpu_replace_ttbr1(pgd_t *pgdp)
 {
 	typedef void (ttbr_replace_func)(phys_addr_t);
 	extern ttbr_replace_func idmap_cpu_replace_ttbr1;
diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c
index 7bbf5104b7b7..e98466bab633 100644
--- a/arch/arm64/kernel/alternative.c
+++ b/arch/arm64/kernel/alternative.c
@@ -133,7 +133,7 @@ static void clean_dcache_range_nopatch(u64 start, u64 end)
 	} while (cur += d_size, cur < end);
 }
 
-static void __nocfi __apply_alternatives(struct alt_region *region, bool is_module,
+static void __apply_alternatives(struct alt_region *region, bool is_module,
 				 unsigned long *feature_mask)
 {
 	struct alt_instr *alt;
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index d72c4b4d389c..af78dcacf9fe 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1596,7 +1596,7 @@ static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
 }
 
 #ifdef CONFIG_UNMAP_KERNEL_AT_EL0
-static void __nocfi
+static void
 kpti_install_ng_mappings(const struct arm64_cpu_capabilities *__unused)
 {
 	typedef void (kpti_remap_fn)(int, int, phys_addr_t);
-- 
2.36.0.550.gb090851708-goog


_______________________________________________
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] 174+ messages in thread

* [RFC PATCH v2 12/21] treewide: Drop function_nocfi
  2022-05-13 20:21 ` Sami Tolvanen
@ 2022-05-13 20:21   ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

With -fsanitize=kcfi, we no longer need function_nocfi() as
the compiler won't change function references to point to a
jump table. Remove all implementations and uses of the macro.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/arm64/include/asm/compiler.h         | 16 ----------------
 arch/arm64/include/asm/ftrace.h           |  2 +-
 arch/arm64/include/asm/mmu_context.h      |  2 +-
 arch/arm64/kernel/acpi_parking_protocol.c |  2 +-
 arch/arm64/kernel/cpufeature.c            |  2 +-
 arch/arm64/kernel/ftrace.c                |  2 +-
 arch/arm64/kernel/machine_kexec.c         |  2 +-
 arch/arm64/kernel/psci.c                  |  2 +-
 arch/arm64/kernel/smp_spin_table.c        |  2 +-
 drivers/firmware/psci/psci.c              |  4 ++--
 drivers/misc/lkdtm/usercopy.c             |  2 +-
 include/linux/compiler.h                  | 10 ----------
 12 files changed, 11 insertions(+), 37 deletions(-)

diff --git a/arch/arm64/include/asm/compiler.h b/arch/arm64/include/asm/compiler.h
index dc3ea4080e2e..6fb2e6bcc392 100644
--- a/arch/arm64/include/asm/compiler.h
+++ b/arch/arm64/include/asm/compiler.h
@@ -23,20 +23,4 @@
 #define __builtin_return_address(val)					\
 	(void *)(ptrauth_clear_pac((unsigned long)__builtin_return_address(val)))
 
-#ifdef CONFIG_CFI_CLANG
-/*
- * With CONFIG_CFI_CLANG, the compiler replaces function address
- * references with the address of the function's CFI jump table
- * entry. The function_nocfi macro always returns the address of the
- * actual function instead.
- */
-#define function_nocfi(x) ({						\
-	void *addr;							\
-	asm("adrp %0, " __stringify(x) "\n\t"				\
-	    "add  %0, %0, :lo12:" __stringify(x)			\
-	    : "=r" (addr));						\
-	addr;								\
-})
-#endif
-
 #endif /* __ASM_COMPILER_H */
diff --git a/arch/arm64/include/asm/ftrace.h b/arch/arm64/include/asm/ftrace.h
index 1494cfa8639b..c96d47cb8f46 100644
--- a/arch/arm64/include/asm/ftrace.h
+++ b/arch/arm64/include/asm/ftrace.h
@@ -26,7 +26,7 @@
 #ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
 #define ARCH_SUPPORTS_FTRACE_OPS 1
 #else
-#define MCOUNT_ADDR		((unsigned long)function_nocfi(_mcount))
+#define MCOUNT_ADDR		((unsigned long)_mcount)
 #endif
 
 /* The BL at the callsite's adjusted rec->ip */
diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
index ca0140d0b8cf..8fa4cfbdda90 100644
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -164,7 +164,7 @@ static inline void cpu_replace_ttbr1(pgd_t *pgdp)
 		ttbr1 |= TTBR_CNP_BIT;
 	}
 
-	replace_phys = (void *)__pa_symbol(function_nocfi(idmap_cpu_replace_ttbr1));
+	replace_phys = (void *)__pa_symbol(idmap_cpu_replace_ttbr1);
 
 	cpu_install_idmap();
 	replace_phys(ttbr1);
diff --git a/arch/arm64/kernel/acpi_parking_protocol.c b/arch/arm64/kernel/acpi_parking_protocol.c
index bfeeb5319abf..b1990e38aed0 100644
--- a/arch/arm64/kernel/acpi_parking_protocol.c
+++ b/arch/arm64/kernel/acpi_parking_protocol.c
@@ -99,7 +99,7 @@ static int acpi_parking_protocol_cpu_boot(unsigned int cpu)
 	 * that read this address need to convert this address to the
 	 * Boot-Loader's endianness before jumping.
 	 */
-	writeq_relaxed(__pa_symbol(function_nocfi(secondary_entry)),
+	writeq_relaxed(__pa_symbol(secondary_entry),
 		       &mailbox->entry_point);
 	writel_relaxed(cpu_entry->gic_cpu_id, &mailbox->cpu_id);
 
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index af78dcacf9fe..5dbe381670a0 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1619,7 +1619,7 @@ kpti_install_ng_mappings(const struct arm64_cpu_capabilities *__unused)
 	if (arm64_use_ng_mappings)
 		return;
 
-	remap_fn = (void *)__pa_symbol(function_nocfi(idmap_kpti_install_ng_mappings));
+	remap_fn = (void *)__pa_symbol(idmap_kpti_install_ng_mappings);
 
 	cpu_install_idmap();
 	remap_fn(cpu, num_online_cpus(), __pa_symbol(swapper_pg_dir));
diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
index 4506c4a90ac1..4128ca6ed485 100644
--- a/arch/arm64/kernel/ftrace.c
+++ b/arch/arm64/kernel/ftrace.c
@@ -56,7 +56,7 @@ int ftrace_update_ftrace_func(ftrace_func_t func)
 	unsigned long pc;
 	u32 new;
 
-	pc = (unsigned long)function_nocfi(ftrace_call);
+	pc = (unsigned long)ftrace_call;
 	new = aarch64_insn_gen_branch_imm(pc, (unsigned long)func,
 					  AARCH64_INSN_BRANCH_LINK);
 
diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
index e16b248699d5..4eb5388aa5a6 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -204,7 +204,7 @@ void machine_kexec(struct kimage *kimage)
 		typeof(cpu_soft_restart) *restart;
 
 		cpu_install_idmap();
-		restart = (void *)__pa_symbol(function_nocfi(cpu_soft_restart));
+		restart = (void *)__pa_symbol(cpu_soft_restart);
 		restart(is_hyp_nvhe(), kimage->start, kimage->arch.dtb_mem,
 			0, 0);
 	} else {
diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
index ab7f4c476104..29a8e444db83 100644
--- a/arch/arm64/kernel/psci.c
+++ b/arch/arm64/kernel/psci.c
@@ -38,7 +38,7 @@ static int __init cpu_psci_cpu_prepare(unsigned int cpu)
 
 static int cpu_psci_cpu_boot(unsigned int cpu)
 {
-	phys_addr_t pa_secondary_entry = __pa_symbol(function_nocfi(secondary_entry));
+	phys_addr_t pa_secondary_entry = __pa_symbol(secondary_entry);
 	int err = psci_ops.cpu_on(cpu_logical_map(cpu), pa_secondary_entry);
 	if (err)
 		pr_err("failed to boot CPU%d (%d)\n", cpu, err);
diff --git a/arch/arm64/kernel/smp_spin_table.c b/arch/arm64/kernel/smp_spin_table.c
index 7e1624ecab3c..49029eace3ad 100644
--- a/arch/arm64/kernel/smp_spin_table.c
+++ b/arch/arm64/kernel/smp_spin_table.c
@@ -66,7 +66,7 @@ static int smp_spin_table_cpu_init(unsigned int cpu)
 static int smp_spin_table_cpu_prepare(unsigned int cpu)
 {
 	__le64 __iomem *release_addr;
-	phys_addr_t pa_holding_pen = __pa_symbol(function_nocfi(secondary_holding_pen));
+	phys_addr_t pa_holding_pen = __pa_symbol(secondary_holding_pen);
 
 	if (!cpu_release_addr[cpu])
 		return -ENODEV;
diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
index 6554bf4b8c99..16a1daec8cd2 100644
--- a/drivers/firmware/psci/psci.c
+++ b/drivers/firmware/psci/psci.c
@@ -334,7 +334,7 @@ static int __init psci_features(u32 psci_func_id)
 static int psci_suspend_finisher(unsigned long state)
 {
 	u32 power_state = state;
-	phys_addr_t pa_cpu_resume = __pa_symbol(function_nocfi(cpu_resume));
+	phys_addr_t pa_cpu_resume = __pa_symbol(cpu_resume);
 
 	return psci_ops.cpu_suspend(power_state, pa_cpu_resume);
 }
@@ -359,7 +359,7 @@ int psci_cpu_suspend_enter(u32 state)
 
 static int psci_system_suspend(unsigned long unused)
 {
-	phys_addr_t pa_cpu_resume = __pa_symbol(function_nocfi(cpu_resume));
+	phys_addr_t pa_cpu_resume = __pa_symbol(cpu_resume);
 
 	return invoke_psci_fn(PSCI_FN_NATIVE(1_0, SYSTEM_SUSPEND),
 			      pa_cpu_resume, 0, 0);
diff --git a/drivers/misc/lkdtm/usercopy.c b/drivers/misc/lkdtm/usercopy.c
index 9161ce7ed47a..79a17b1c4885 100644
--- a/drivers/misc/lkdtm/usercopy.c
+++ b/drivers/misc/lkdtm/usercopy.c
@@ -318,7 +318,7 @@ void lkdtm_USERCOPY_KERNEL(void)
 
 	pr_info("attempting bad copy_to_user from kernel text: %px\n",
 		vm_mmap);
-	if (copy_to_user((void __user *)user_addr, function_nocfi(vm_mmap),
+	if (copy_to_user((void __user *)user_addr, vm_mmap,
 			 unconst + PAGE_SIZE)) {
 		pr_warn("copy_to_user failed, but lacked Oops\n");
 		goto free_user;
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 9303f5fe5d89..80ed9644d129 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -203,16 +203,6 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
 	__v;								\
 })
 
-/*
- * With CONFIG_CFI_CLANG, the compiler replaces function addresses in
- * instrumented C code with jump table addresses. Architectures that
- * support CFI can define this macro to return the actual function address
- * when needed.
- */
-#ifndef function_nocfi
-#define function_nocfi(x) (x)
-#endif
-
 #endif /* __KERNEL__ */
 
 /*
-- 
2.36.0.550.gb090851708-goog


^ permalink raw reply	[flat|nested] 174+ messages in thread

* [RFC PATCH v2 12/21] treewide: Drop function_nocfi
@ 2022-05-13 20:21   ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

With -fsanitize=kcfi, we no longer need function_nocfi() as
the compiler won't change function references to point to a
jump table. Remove all implementations and uses of the macro.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/arm64/include/asm/compiler.h         | 16 ----------------
 arch/arm64/include/asm/ftrace.h           |  2 +-
 arch/arm64/include/asm/mmu_context.h      |  2 +-
 arch/arm64/kernel/acpi_parking_protocol.c |  2 +-
 arch/arm64/kernel/cpufeature.c            |  2 +-
 arch/arm64/kernel/ftrace.c                |  2 +-
 arch/arm64/kernel/machine_kexec.c         |  2 +-
 arch/arm64/kernel/psci.c                  |  2 +-
 arch/arm64/kernel/smp_spin_table.c        |  2 +-
 drivers/firmware/psci/psci.c              |  4 ++--
 drivers/misc/lkdtm/usercopy.c             |  2 +-
 include/linux/compiler.h                  | 10 ----------
 12 files changed, 11 insertions(+), 37 deletions(-)

diff --git a/arch/arm64/include/asm/compiler.h b/arch/arm64/include/asm/compiler.h
index dc3ea4080e2e..6fb2e6bcc392 100644
--- a/arch/arm64/include/asm/compiler.h
+++ b/arch/arm64/include/asm/compiler.h
@@ -23,20 +23,4 @@
 #define __builtin_return_address(val)					\
 	(void *)(ptrauth_clear_pac((unsigned long)__builtin_return_address(val)))
 
-#ifdef CONFIG_CFI_CLANG
-/*
- * With CONFIG_CFI_CLANG, the compiler replaces function address
- * references with the address of the function's CFI jump table
- * entry. The function_nocfi macro always returns the address of the
- * actual function instead.
- */
-#define function_nocfi(x) ({						\
-	void *addr;							\
-	asm("adrp %0, " __stringify(x) "\n\t"				\
-	    "add  %0, %0, :lo12:" __stringify(x)			\
-	    : "=r" (addr));						\
-	addr;								\
-})
-#endif
-
 #endif /* __ASM_COMPILER_H */
diff --git a/arch/arm64/include/asm/ftrace.h b/arch/arm64/include/asm/ftrace.h
index 1494cfa8639b..c96d47cb8f46 100644
--- a/arch/arm64/include/asm/ftrace.h
+++ b/arch/arm64/include/asm/ftrace.h
@@ -26,7 +26,7 @@
 #ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
 #define ARCH_SUPPORTS_FTRACE_OPS 1
 #else
-#define MCOUNT_ADDR		((unsigned long)function_nocfi(_mcount))
+#define MCOUNT_ADDR		((unsigned long)_mcount)
 #endif
 
 /* The BL at the callsite's adjusted rec->ip */
diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
index ca0140d0b8cf..8fa4cfbdda90 100644
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -164,7 +164,7 @@ static inline void cpu_replace_ttbr1(pgd_t *pgdp)
 		ttbr1 |= TTBR_CNP_BIT;
 	}
 
-	replace_phys = (void *)__pa_symbol(function_nocfi(idmap_cpu_replace_ttbr1));
+	replace_phys = (void *)__pa_symbol(idmap_cpu_replace_ttbr1);
 
 	cpu_install_idmap();
 	replace_phys(ttbr1);
diff --git a/arch/arm64/kernel/acpi_parking_protocol.c b/arch/arm64/kernel/acpi_parking_protocol.c
index bfeeb5319abf..b1990e38aed0 100644
--- a/arch/arm64/kernel/acpi_parking_protocol.c
+++ b/arch/arm64/kernel/acpi_parking_protocol.c
@@ -99,7 +99,7 @@ static int acpi_parking_protocol_cpu_boot(unsigned int cpu)
 	 * that read this address need to convert this address to the
 	 * Boot-Loader's endianness before jumping.
 	 */
-	writeq_relaxed(__pa_symbol(function_nocfi(secondary_entry)),
+	writeq_relaxed(__pa_symbol(secondary_entry),
 		       &mailbox->entry_point);
 	writel_relaxed(cpu_entry->gic_cpu_id, &mailbox->cpu_id);
 
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index af78dcacf9fe..5dbe381670a0 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1619,7 +1619,7 @@ kpti_install_ng_mappings(const struct arm64_cpu_capabilities *__unused)
 	if (arm64_use_ng_mappings)
 		return;
 
-	remap_fn = (void *)__pa_symbol(function_nocfi(idmap_kpti_install_ng_mappings));
+	remap_fn = (void *)__pa_symbol(idmap_kpti_install_ng_mappings);
 
 	cpu_install_idmap();
 	remap_fn(cpu, num_online_cpus(), __pa_symbol(swapper_pg_dir));
diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
index 4506c4a90ac1..4128ca6ed485 100644
--- a/arch/arm64/kernel/ftrace.c
+++ b/arch/arm64/kernel/ftrace.c
@@ -56,7 +56,7 @@ int ftrace_update_ftrace_func(ftrace_func_t func)
 	unsigned long pc;
 	u32 new;
 
-	pc = (unsigned long)function_nocfi(ftrace_call);
+	pc = (unsigned long)ftrace_call;
 	new = aarch64_insn_gen_branch_imm(pc, (unsigned long)func,
 					  AARCH64_INSN_BRANCH_LINK);
 
diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
index e16b248699d5..4eb5388aa5a6 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -204,7 +204,7 @@ void machine_kexec(struct kimage *kimage)
 		typeof(cpu_soft_restart) *restart;
 
 		cpu_install_idmap();
-		restart = (void *)__pa_symbol(function_nocfi(cpu_soft_restart));
+		restart = (void *)__pa_symbol(cpu_soft_restart);
 		restart(is_hyp_nvhe(), kimage->start, kimage->arch.dtb_mem,
 			0, 0);
 	} else {
diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
index ab7f4c476104..29a8e444db83 100644
--- a/arch/arm64/kernel/psci.c
+++ b/arch/arm64/kernel/psci.c
@@ -38,7 +38,7 @@ static int __init cpu_psci_cpu_prepare(unsigned int cpu)
 
 static int cpu_psci_cpu_boot(unsigned int cpu)
 {
-	phys_addr_t pa_secondary_entry = __pa_symbol(function_nocfi(secondary_entry));
+	phys_addr_t pa_secondary_entry = __pa_symbol(secondary_entry);
 	int err = psci_ops.cpu_on(cpu_logical_map(cpu), pa_secondary_entry);
 	if (err)
 		pr_err("failed to boot CPU%d (%d)\n", cpu, err);
diff --git a/arch/arm64/kernel/smp_spin_table.c b/arch/arm64/kernel/smp_spin_table.c
index 7e1624ecab3c..49029eace3ad 100644
--- a/arch/arm64/kernel/smp_spin_table.c
+++ b/arch/arm64/kernel/smp_spin_table.c
@@ -66,7 +66,7 @@ static int smp_spin_table_cpu_init(unsigned int cpu)
 static int smp_spin_table_cpu_prepare(unsigned int cpu)
 {
 	__le64 __iomem *release_addr;
-	phys_addr_t pa_holding_pen = __pa_symbol(function_nocfi(secondary_holding_pen));
+	phys_addr_t pa_holding_pen = __pa_symbol(secondary_holding_pen);
 
 	if (!cpu_release_addr[cpu])
 		return -ENODEV;
diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
index 6554bf4b8c99..16a1daec8cd2 100644
--- a/drivers/firmware/psci/psci.c
+++ b/drivers/firmware/psci/psci.c
@@ -334,7 +334,7 @@ static int __init psci_features(u32 psci_func_id)
 static int psci_suspend_finisher(unsigned long state)
 {
 	u32 power_state = state;
-	phys_addr_t pa_cpu_resume = __pa_symbol(function_nocfi(cpu_resume));
+	phys_addr_t pa_cpu_resume = __pa_symbol(cpu_resume);
 
 	return psci_ops.cpu_suspend(power_state, pa_cpu_resume);
 }
@@ -359,7 +359,7 @@ int psci_cpu_suspend_enter(u32 state)
 
 static int psci_system_suspend(unsigned long unused)
 {
-	phys_addr_t pa_cpu_resume = __pa_symbol(function_nocfi(cpu_resume));
+	phys_addr_t pa_cpu_resume = __pa_symbol(cpu_resume);
 
 	return invoke_psci_fn(PSCI_FN_NATIVE(1_0, SYSTEM_SUSPEND),
 			      pa_cpu_resume, 0, 0);
diff --git a/drivers/misc/lkdtm/usercopy.c b/drivers/misc/lkdtm/usercopy.c
index 9161ce7ed47a..79a17b1c4885 100644
--- a/drivers/misc/lkdtm/usercopy.c
+++ b/drivers/misc/lkdtm/usercopy.c
@@ -318,7 +318,7 @@ void lkdtm_USERCOPY_KERNEL(void)
 
 	pr_info("attempting bad copy_to_user from kernel text: %px\n",
 		vm_mmap);
-	if (copy_to_user((void __user *)user_addr, function_nocfi(vm_mmap),
+	if (copy_to_user((void __user *)user_addr, vm_mmap,
 			 unconst + PAGE_SIZE)) {
 		pr_warn("copy_to_user failed, but lacked Oops\n");
 		goto free_user;
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 9303f5fe5d89..80ed9644d129 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -203,16 +203,6 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
 	__v;								\
 })
 
-/*
- * With CONFIG_CFI_CLANG, the compiler replaces function addresses in
- * instrumented C code with jump table addresses. Architectures that
- * support CFI can define this macro to return the actual function address
- * when needed.
- */
-#ifndef function_nocfi
-#define function_nocfi(x) (x)
-#endif
-
 #endif /* __KERNEL__ */
 
 /*
-- 
2.36.0.550.gb090851708-goog


_______________________________________________
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] 174+ messages in thread

* [RFC PATCH v2 13/21] treewide: Drop WARN_ON_FUNCTION_MISMATCH
  2022-05-13 20:21 ` Sami Tolvanen
@ 2022-05-13 20:21   ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

CONFIG_CFI_CLANG no longer breaks cross-module function address
equality, which makes WARN_ON_FUNCTION_MISMATCH unnecessary. Remove
the definition and switch back to WARN_ON_ONCE.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 include/asm-generic/bug.h | 16 ----------------
 kernel/kthread.c          |  3 +--
 kernel/workqueue.c        |  2 +-
 3 files changed, 2 insertions(+), 19 deletions(-)

diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index ba1f860af38b..4050b191e1a9 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -220,22 +220,6 @@ extern __printf(1, 2) void __warn_printk(const char *fmt, ...);
 # define WARN_ON_SMP(x)			({0;})
 #endif
 
-/*
- * WARN_ON_FUNCTION_MISMATCH() warns if a value doesn't match a
- * function address, and can be useful for catching issues with
- * callback functions, for example.
- *
- * With CONFIG_CFI_CLANG, the warning is disabled because the
- * compiler replaces function addresses taken in C code with
- * local jump table addresses, which breaks cross-module function
- * address equality.
- */
-#if defined(CONFIG_CFI_CLANG) && defined(CONFIG_MODULES)
-# define WARN_ON_FUNCTION_MISMATCH(x, fn) ({ 0; })
-#else
-# define WARN_ON_FUNCTION_MISMATCH(x, fn) WARN_ON_ONCE((x) != (fn))
-#endif
-
 #endif /* __ASSEMBLY__ */
 
 #endif
diff --git a/kernel/kthread.c b/kernel/kthread.c
index 50265f69a135..dfeb87876b4a 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -1050,8 +1050,7 @@ static void __kthread_queue_delayed_work(struct kthread_worker *worker,
 	struct timer_list *timer = &dwork->timer;
 	struct kthread_work *work = &dwork->work;
 
-	WARN_ON_FUNCTION_MISMATCH(timer->function,
-				  kthread_delayed_work_timer_fn);
+	WARN_ON_ONCE(timer->function != kthread_delayed_work_timer_fn);
 
 	/*
 	 * If @delay is 0, queue @dwork->work immediately.  This is for
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 0d2514b4ff0d..18c1a1c09684 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1651,7 +1651,7 @@ static void __queue_delayed_work(int cpu, struct workqueue_struct *wq,
 	struct work_struct *work = &dwork->work;
 
 	WARN_ON_ONCE(!wq);
-	WARN_ON_FUNCTION_MISMATCH(timer->function, delayed_work_timer_fn);
+	WARN_ON_ONCE(timer->function != delayed_work_timer_fn);
 	WARN_ON_ONCE(timer_pending(timer));
 	WARN_ON_ONCE(!list_empty(&work->entry));
 
-- 
2.36.0.550.gb090851708-goog


^ permalink raw reply	[flat|nested] 174+ messages in thread

* [RFC PATCH v2 13/21] treewide: Drop WARN_ON_FUNCTION_MISMATCH
@ 2022-05-13 20:21   ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

CONFIG_CFI_CLANG no longer breaks cross-module function address
equality, which makes WARN_ON_FUNCTION_MISMATCH unnecessary. Remove
the definition and switch back to WARN_ON_ONCE.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 include/asm-generic/bug.h | 16 ----------------
 kernel/kthread.c          |  3 +--
 kernel/workqueue.c        |  2 +-
 3 files changed, 2 insertions(+), 19 deletions(-)

diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index ba1f860af38b..4050b191e1a9 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -220,22 +220,6 @@ extern __printf(1, 2) void __warn_printk(const char *fmt, ...);
 # define WARN_ON_SMP(x)			({0;})
 #endif
 
-/*
- * WARN_ON_FUNCTION_MISMATCH() warns if a value doesn't match a
- * function address, and can be useful for catching issues with
- * callback functions, for example.
- *
- * With CONFIG_CFI_CLANG, the warning is disabled because the
- * compiler replaces function addresses taken in C code with
- * local jump table addresses, which breaks cross-module function
- * address equality.
- */
-#if defined(CONFIG_CFI_CLANG) && defined(CONFIG_MODULES)
-# define WARN_ON_FUNCTION_MISMATCH(x, fn) ({ 0; })
-#else
-# define WARN_ON_FUNCTION_MISMATCH(x, fn) WARN_ON_ONCE((x) != (fn))
-#endif
-
 #endif /* __ASSEMBLY__ */
 
 #endif
diff --git a/kernel/kthread.c b/kernel/kthread.c
index 50265f69a135..dfeb87876b4a 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -1050,8 +1050,7 @@ static void __kthread_queue_delayed_work(struct kthread_worker *worker,
 	struct timer_list *timer = &dwork->timer;
 	struct kthread_work *work = &dwork->work;
 
-	WARN_ON_FUNCTION_MISMATCH(timer->function,
-				  kthread_delayed_work_timer_fn);
+	WARN_ON_ONCE(timer->function != kthread_delayed_work_timer_fn);
 
 	/*
 	 * If @delay is 0, queue @dwork->work immediately.  This is for
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 0d2514b4ff0d..18c1a1c09684 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1651,7 +1651,7 @@ static void __queue_delayed_work(int cpu, struct workqueue_struct *wq,
 	struct work_struct *work = &dwork->work;
 
 	WARN_ON_ONCE(!wq);
-	WARN_ON_FUNCTION_MISMATCH(timer->function, delayed_work_timer_fn);
+	WARN_ON_ONCE(timer->function != delayed_work_timer_fn);
 	WARN_ON_ONCE(timer_pending(timer));
 	WARN_ON_ONCE(!list_empty(&work->entry));
 
-- 
2.36.0.550.gb090851708-goog


_______________________________________________
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] 174+ messages in thread

* [RFC PATCH v2 14/21] treewide: Drop __cficanonical
  2022-05-13 20:21 ` Sami Tolvanen
@ 2022-05-13 20:21   ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

CONFIG_CFI_CLANG doesn't use a jump table anymore and therefore,
won't change function references to point elsewhere. Remove the
__cficanonical attribute and all uses of it.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 include/linux/compiler_types.h | 4 ----
 include/linux/init.h           | 4 ++--
 include/linux/pci.h            | 4 ++--
 3 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 1c2c33ae1b37..bdd2526af46a 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -263,10 +263,6 @@ struct ftrace_likely_data {
 # define __nocfi
 #endif
 
-#ifndef __cficanonical
-# define __cficanonical
-#endif
-
 /*
  * Any place that could be marked with the "alloc_size" attribute is also
  * a place to be marked with the "malloc" attribute. Do this as part of the
diff --git a/include/linux/init.h b/include/linux/init.h
index baf0b29a7010..76058c9e0399 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -220,8 +220,8 @@ extern bool initcall_debug;
 	__initcall_name(initstub, __iid, id)
 
 #define __define_initcall_stub(__stub, fn)			\
-	int __init __cficanonical __stub(void);			\
-	int __init __cficanonical __stub(void)			\
+	int __init __stub(void);				\
+	int __init __stub(void)					\
 	{ 							\
 		return fn();					\
 	}							\
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 60adf42460ab..3cc50c4e3c64 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -2021,8 +2021,8 @@ enum pci_fixup_pass {
 #ifdef CONFIG_LTO_CLANG
 #define __DECLARE_PCI_FIXUP_SECTION(sec, name, vendor, device, class,	\
 				  class_shift, hook, stub)		\
-	void __cficanonical stub(struct pci_dev *dev);			\
-	void __cficanonical stub(struct pci_dev *dev)			\
+	void stub(struct pci_dev *dev);					\
+	void stub(struct pci_dev *dev)					\
 	{ 								\
 		hook(dev); 						\
 	}								\
-- 
2.36.0.550.gb090851708-goog


^ permalink raw reply	[flat|nested] 174+ messages in thread

* [RFC PATCH v2 14/21] treewide: Drop __cficanonical
@ 2022-05-13 20:21   ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

CONFIG_CFI_CLANG doesn't use a jump table anymore and therefore,
won't change function references to point elsewhere. Remove the
__cficanonical attribute and all uses of it.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 include/linux/compiler_types.h | 4 ----
 include/linux/init.h           | 4 ++--
 include/linux/pci.h            | 4 ++--
 3 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 1c2c33ae1b37..bdd2526af46a 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -263,10 +263,6 @@ struct ftrace_likely_data {
 # define __nocfi
 #endif
 
-#ifndef __cficanonical
-# define __cficanonical
-#endif
-
 /*
  * Any place that could be marked with the "alloc_size" attribute is also
  * a place to be marked with the "malloc" attribute. Do this as part of the
diff --git a/include/linux/init.h b/include/linux/init.h
index baf0b29a7010..76058c9e0399 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -220,8 +220,8 @@ extern bool initcall_debug;
 	__initcall_name(initstub, __iid, id)
 
 #define __define_initcall_stub(__stub, fn)			\
-	int __init __cficanonical __stub(void);			\
-	int __init __cficanonical __stub(void)			\
+	int __init __stub(void);				\
+	int __init __stub(void)					\
 	{ 							\
 		return fn();					\
 	}							\
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 60adf42460ab..3cc50c4e3c64 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -2021,8 +2021,8 @@ enum pci_fixup_pass {
 #ifdef CONFIG_LTO_CLANG
 #define __DECLARE_PCI_FIXUP_SECTION(sec, name, vendor, device, class,	\
 				  class_shift, hook, stub)		\
-	void __cficanonical stub(struct pci_dev *dev);			\
-	void __cficanonical stub(struct pci_dev *dev)			\
+	void stub(struct pci_dev *dev);					\
+	void stub(struct pci_dev *dev)					\
 	{ 								\
 		hook(dev); 						\
 	}								\
-- 
2.36.0.550.gb090851708-goog


_______________________________________________
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] 174+ messages in thread

* [RFC PATCH v2 15/21] objtool: Don't warn about __cfi_ preambles falling through
  2022-05-13 20:21 ` Sami Tolvanen
@ 2022-05-13 20:21   ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

The __cfi_ preambles contain valid instructions, which embed KCFI
type information in the following format:

  __cfi_function:
    int3
    int3
    mov <id>, %eax
    int3
    int3
  function:
    ...

While the preambles are STT_FUNC and contain valid instructions,
they are not executed and always fall through. Skip the warning for
them.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 tools/objtool/check.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index ca5b74603008..88f005ae6dcc 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -3311,6 +3311,10 @@ static int validate_branch(struct objtool_file *file, struct symbol *func,
 		next_insn = next_insn_to_validate(file, insn);
 
 		if (func && insn->func && func != insn->func->pfunc) {
+			/* Ignore KCFI type preambles, which always fall through */
+			if (!strncmp(func->name, "__cfi_", 6))
+				return 0;
+
 			WARN("%s() falls through to next function %s()",
 			     func->name, insn->func->name);
 			return 1;
-- 
2.36.0.550.gb090851708-goog


^ permalink raw reply	[flat|nested] 174+ messages in thread

* [RFC PATCH v2 15/21] objtool: Don't warn about __cfi_ preambles falling through
@ 2022-05-13 20:21   ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

The __cfi_ preambles contain valid instructions, which embed KCFI
type information in the following format:

  __cfi_function:
    int3
    int3
    mov <id>, %eax
    int3
    int3
  function:
    ...

While the preambles are STT_FUNC and contain valid instructions,
they are not executed and always fall through. Skip the warning for
them.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 tools/objtool/check.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index ca5b74603008..88f005ae6dcc 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -3311,6 +3311,10 @@ static int validate_branch(struct objtool_file *file, struct symbol *func,
 		next_insn = next_insn_to_validate(file, insn);
 
 		if (func && insn->func && func != insn->func->pfunc) {
+			/* Ignore KCFI type preambles, which always fall through */
+			if (!strncmp(func->name, "__cfi_", 6))
+				return 0;
+
 			WARN("%s() falls through to next function %s()",
 			     func->name, insn->func->name);
 			return 1;
-- 
2.36.0.550.gb090851708-goog


_______________________________________________
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] 174+ messages in thread

* [RFC PATCH v2 16/21] x86/tools/relocs: Ignore __kcfi_typeid_ relocations
  2022-05-13 20:21 ` Sami Tolvanen
@ 2022-05-13 20:21   ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

Ignore __kcfi_typeid_ symbols. These are compiler-generated constants
that contain CFI type identifiers.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/x86/tools/relocs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index e2c5b296120d..2925074b9a58 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -56,6 +56,7 @@ static const char * const sym_regex_kernel[S_NSYMTYPES] = {
 	"^(xen_irq_disable_direct_reloc$|"
 	"xen_save_fl_direct_reloc$|"
 	"VDSO|"
+	"__kcfi_typeid_|"
 	"__crc_)",
 
 /*
-- 
2.36.0.550.gb090851708-goog


^ permalink raw reply	[flat|nested] 174+ messages in thread

* [RFC PATCH v2 16/21] x86/tools/relocs: Ignore __kcfi_typeid_ relocations
@ 2022-05-13 20:21   ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

Ignore __kcfi_typeid_ symbols. These are compiler-generated constants
that contain CFI type identifiers.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/x86/tools/relocs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index e2c5b296120d..2925074b9a58 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -56,6 +56,7 @@ static const char * const sym_regex_kernel[S_NSYMTYPES] = {
 	"^(xen_irq_disable_direct_reloc$|"
 	"xen_save_fl_direct_reloc$|"
 	"VDSO|"
+	"__kcfi_typeid_|"
 	"__crc_)",
 
 /*
-- 
2.36.0.550.gb090851708-goog


_______________________________________________
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] 174+ messages in thread

* [RFC PATCH v2 17/21] x86: Add types to indirectly called assembly functions
  2022-05-13 20:21 ` Sami Tolvanen
@ 2022-05-13 20:21   ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

With CONFIG_CFI_CLANG, assembly functions indirectly called from C code
must be annotated with type identifiers to pass CFI checking.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/x86/crypto/blowfish-x86_64-asm_64.S | 5 +++--
 arch/x86/lib/memcpy_64.S                 | 3 ++-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/x86/crypto/blowfish-x86_64-asm_64.S b/arch/x86/crypto/blowfish-x86_64-asm_64.S
index 802d71582689..4a43e072d2d1 100644
--- a/arch/x86/crypto/blowfish-x86_64-asm_64.S
+++ b/arch/x86/crypto/blowfish-x86_64-asm_64.S
@@ -6,6 +6,7 @@
  */
 
 #include <linux/linkage.h>
+#include <linux/cfi_types.h>
 
 .file "blowfish-x86_64-asm.S"
 .text
@@ -141,7 +142,7 @@ SYM_FUNC_START(__blowfish_enc_blk)
 	RET;
 SYM_FUNC_END(__blowfish_enc_blk)
 
-SYM_FUNC_START(blowfish_dec_blk)
+SYM_TYPED_FUNC_START(blowfish_dec_blk)
 	/* input:
 	 *	%rdi: ctx
 	 *	%rsi: dst
@@ -332,7 +333,7 @@ SYM_FUNC_START(__blowfish_enc_blk_4way)
 	RET;
 SYM_FUNC_END(__blowfish_enc_blk_4way)
 
-SYM_FUNC_START(blowfish_dec_blk_4way)
+SYM_TYPED_FUNC_START(blowfish_dec_blk_4way)
 	/* input:
 	 *	%rdi: ctx
 	 *	%rsi: dst
diff --git a/arch/x86/lib/memcpy_64.S b/arch/x86/lib/memcpy_64.S
index d0d7b9bc6cad..e5d9b299577f 100644
--- a/arch/x86/lib/memcpy_64.S
+++ b/arch/x86/lib/memcpy_64.S
@@ -2,6 +2,7 @@
 /* Copyright 2002 Andi Kleen */
 
 #include <linux/linkage.h>
+#include <linux/cfi_types.h>
 #include <asm/errno.h>
 #include <asm/cpufeatures.h>
 #include <asm/alternative.h>
@@ -27,7 +28,7 @@
  * Output:
  * rax original destination
  */
-SYM_FUNC_START(__memcpy)
+__SYM_TYPED_FUNC_START(__memcpy, memcpy)
 	ALTERNATIVE_2 "jmp memcpy_orig", "", X86_FEATURE_REP_GOOD, \
 		      "jmp memcpy_erms", X86_FEATURE_ERMS
 
-- 
2.36.0.550.gb090851708-goog


^ permalink raw reply	[flat|nested] 174+ messages in thread

* [RFC PATCH v2 17/21] x86: Add types to indirectly called assembly functions
@ 2022-05-13 20:21   ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

With CONFIG_CFI_CLANG, assembly functions indirectly called from C code
must be annotated with type identifiers to pass CFI checking.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/x86/crypto/blowfish-x86_64-asm_64.S | 5 +++--
 arch/x86/lib/memcpy_64.S                 | 3 ++-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/x86/crypto/blowfish-x86_64-asm_64.S b/arch/x86/crypto/blowfish-x86_64-asm_64.S
index 802d71582689..4a43e072d2d1 100644
--- a/arch/x86/crypto/blowfish-x86_64-asm_64.S
+++ b/arch/x86/crypto/blowfish-x86_64-asm_64.S
@@ -6,6 +6,7 @@
  */
 
 #include <linux/linkage.h>
+#include <linux/cfi_types.h>
 
 .file "blowfish-x86_64-asm.S"
 .text
@@ -141,7 +142,7 @@ SYM_FUNC_START(__blowfish_enc_blk)
 	RET;
 SYM_FUNC_END(__blowfish_enc_blk)
 
-SYM_FUNC_START(blowfish_dec_blk)
+SYM_TYPED_FUNC_START(blowfish_dec_blk)
 	/* input:
 	 *	%rdi: ctx
 	 *	%rsi: dst
@@ -332,7 +333,7 @@ SYM_FUNC_START(__blowfish_enc_blk_4way)
 	RET;
 SYM_FUNC_END(__blowfish_enc_blk_4way)
 
-SYM_FUNC_START(blowfish_dec_blk_4way)
+SYM_TYPED_FUNC_START(blowfish_dec_blk_4way)
 	/* input:
 	 *	%rdi: ctx
 	 *	%rsi: dst
diff --git a/arch/x86/lib/memcpy_64.S b/arch/x86/lib/memcpy_64.S
index d0d7b9bc6cad..e5d9b299577f 100644
--- a/arch/x86/lib/memcpy_64.S
+++ b/arch/x86/lib/memcpy_64.S
@@ -2,6 +2,7 @@
 /* Copyright 2002 Andi Kleen */
 
 #include <linux/linkage.h>
+#include <linux/cfi_types.h>
 #include <asm/errno.h>
 #include <asm/cpufeatures.h>
 #include <asm/alternative.h>
@@ -27,7 +28,7 @@
  * Output:
  * rax original destination
  */
-SYM_FUNC_START(__memcpy)
+__SYM_TYPED_FUNC_START(__memcpy, memcpy)
 	ALTERNATIVE_2 "jmp memcpy_orig", "", X86_FEATURE_REP_GOOD, \
 		      "jmp memcpy_erms", X86_FEATURE_ERMS
 
-- 
2.36.0.550.gb090851708-goog


_______________________________________________
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] 174+ messages in thread

* [RFC PATCH v2 18/21] x86/purgatory: Disable CFI
  2022-05-13 20:21 ` Sami Tolvanen
@ 2022-05-13 20:21   ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

Disable CONFIG_CFI_CLANG for the stand-alone purgatory.ro.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
---
 arch/x86/purgatory/Makefile | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
index ae53d54d7959..b3fa947fa38b 100644
--- a/arch/x86/purgatory/Makefile
+++ b/arch/x86/purgatory/Makefile
@@ -55,6 +55,10 @@ ifdef CONFIG_RETPOLINE
 PURGATORY_CFLAGS_REMOVE		+= $(RETPOLINE_CFLAGS)
 endif
 
+ifdef CONFIG_CFI_CLANG
+PURGATORY_CFLAGS_REMOVE		+= $(CC_FLAGS_CFI)
+endif
+
 CFLAGS_REMOVE_purgatory.o	+= $(PURGATORY_CFLAGS_REMOVE)
 CFLAGS_purgatory.o		+= $(PURGATORY_CFLAGS)
 
-- 
2.36.0.550.gb090851708-goog


^ permalink raw reply	[flat|nested] 174+ messages in thread

* [RFC PATCH v2 18/21] x86/purgatory: Disable CFI
@ 2022-05-13 20:21   ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

Disable CONFIG_CFI_CLANG for the stand-alone purgatory.ro.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
---
 arch/x86/purgatory/Makefile | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
index ae53d54d7959..b3fa947fa38b 100644
--- a/arch/x86/purgatory/Makefile
+++ b/arch/x86/purgatory/Makefile
@@ -55,6 +55,10 @@ ifdef CONFIG_RETPOLINE
 PURGATORY_CFLAGS_REMOVE		+= $(RETPOLINE_CFLAGS)
 endif
 
+ifdef CONFIG_CFI_CLANG
+PURGATORY_CFLAGS_REMOVE		+= $(CC_FLAGS_CFI)
+endif
+
 CFLAGS_REMOVE_purgatory.o	+= $(PURGATORY_CFLAGS_REMOVE)
 CFLAGS_purgatory.o		+= $(PURGATORY_CFLAGS)
 
-- 
2.36.0.550.gb090851708-goog


_______________________________________________
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] 174+ messages in thread

* [RFC PATCH v2 19/21] x86/vdso: Disable CFI
  2022-05-13 20:21 ` Sami Tolvanen
@ 2022-05-13 20:21   ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

CC_FLAGS_LTO no longer includes CC_FLAGS_CFI, so filter these flags
out as well.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/x86/entry/vdso/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index 693f8b9031fb..abf41ef0f89e 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -91,7 +91,7 @@ ifneq ($(RETPOLINE_VDSO_CFLAGS),)
 endif
 endif
 
-$(vobjs): KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_LTO) $(GCC_PLUGINS_CFLAGS) $(RETPOLINE_CFLAGS),$(KBUILD_CFLAGS)) $(CFL)
+$(vobjs): KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_LTO) $(CC_FLAGS_CFI) $(GCC_PLUGINS_CFLAGS) $(RETPOLINE_CFLAGS),$(KBUILD_CFLAGS)) $(CFL)
 
 #
 # vDSO code runs in userspace and -pg doesn't help with profiling anyway.
@@ -151,6 +151,7 @@ KBUILD_CFLAGS_32 := $(filter-out -mfentry,$(KBUILD_CFLAGS_32))
 KBUILD_CFLAGS_32 := $(filter-out $(GCC_PLUGINS_CFLAGS),$(KBUILD_CFLAGS_32))
 KBUILD_CFLAGS_32 := $(filter-out $(RETPOLINE_CFLAGS),$(KBUILD_CFLAGS_32))
 KBUILD_CFLAGS_32 := $(filter-out $(CC_FLAGS_LTO),$(KBUILD_CFLAGS_32))
+KBUILD_CFLAGS_32 := $(filter-out $(CC_FLAGS_CFI),$(KBUILD_CFLAGS_32))
 KBUILD_CFLAGS_32 += -m32 -msoft-float -mregparm=0 -fpic
 KBUILD_CFLAGS_32 += -fno-stack-protector
 KBUILD_CFLAGS_32 += $(call cc-option, -foptimize-sibling-calls)
-- 
2.36.0.550.gb090851708-goog


^ permalink raw reply	[flat|nested] 174+ messages in thread

* [RFC PATCH v2 19/21] x86/vdso: Disable CFI
@ 2022-05-13 20:21   ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

CC_FLAGS_LTO no longer includes CC_FLAGS_CFI, so filter these flags
out as well.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/x86/entry/vdso/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index 693f8b9031fb..abf41ef0f89e 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -91,7 +91,7 @@ ifneq ($(RETPOLINE_VDSO_CFLAGS),)
 endif
 endif
 
-$(vobjs): KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_LTO) $(GCC_PLUGINS_CFLAGS) $(RETPOLINE_CFLAGS),$(KBUILD_CFLAGS)) $(CFL)
+$(vobjs): KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_LTO) $(CC_FLAGS_CFI) $(GCC_PLUGINS_CFLAGS) $(RETPOLINE_CFLAGS),$(KBUILD_CFLAGS)) $(CFL)
 
 #
 # vDSO code runs in userspace and -pg doesn't help with profiling anyway.
@@ -151,6 +151,7 @@ KBUILD_CFLAGS_32 := $(filter-out -mfentry,$(KBUILD_CFLAGS_32))
 KBUILD_CFLAGS_32 := $(filter-out $(GCC_PLUGINS_CFLAGS),$(KBUILD_CFLAGS_32))
 KBUILD_CFLAGS_32 := $(filter-out $(RETPOLINE_CFLAGS),$(KBUILD_CFLAGS_32))
 KBUILD_CFLAGS_32 := $(filter-out $(CC_FLAGS_LTO),$(KBUILD_CFLAGS_32))
+KBUILD_CFLAGS_32 := $(filter-out $(CC_FLAGS_CFI),$(KBUILD_CFLAGS_32))
 KBUILD_CFLAGS_32 += -m32 -msoft-float -mregparm=0 -fpic
 KBUILD_CFLAGS_32 += -fno-stack-protector
 KBUILD_CFLAGS_32 += $(call cc-option, -foptimize-sibling-calls)
-- 
2.36.0.550.gb090851708-goog


_______________________________________________
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] 174+ messages in thread

* [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
  2022-05-13 20:21 ` Sami Tolvanen
@ 2022-05-13 20:21   ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

With CONFIG_CFI_CLANG, the compiler injects a type preamble
immediately before each function and a check to validate the target
function type before indirect calls:

  ; type preamble
  __cfi_function:
    int3
    int3
    mov <id>, %eax
    int3
    int3
  function:
    ...
  ; indirect call check
    cmpl    <id>, -6(%r11)
    je      .Ltmp1
    ud2
  .Ltmp1:
    call    __x86_indirect_thunk_r11

Define the __CFI_TYPE helper macro for manual type annotations in
assembly code, add error handling for the CFI ud2 traps, and allow
CONFIG_CFI_CLANG to be selected on x86_64.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/x86/Kconfig               |  2 ++
 arch/x86/include/asm/linkage.h | 12 +++++++
 arch/x86/kernel/traps.c        | 60 +++++++++++++++++++++++++++++++++-
 3 files changed, 73 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 4bed3abf444d..2e73d0792d48 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -108,6 +108,8 @@ config X86
 	select ARCH_SUPPORTS_PAGE_TABLE_CHECK	if X86_64
 	select ARCH_SUPPORTS_NUMA_BALANCING	if X86_64
 	select ARCH_SUPPORTS_KMAP_LOCAL_FORCE_MAP	if NR_CPUS <= 4096
+	select ARCH_SUPPORTS_CFI_CLANG		if X86_64
+	select ARCH_USES_CFI_TRAPS		if X86_64 && CFI_CLANG
 	select ARCH_SUPPORTS_LTO_CLANG
 	select ARCH_SUPPORTS_LTO_CLANG_THIN
 	select ARCH_USE_BUILTIN_BSWAP
diff --git a/arch/x86/include/asm/linkage.h b/arch/x86/include/asm/linkage.h
index 85865f1645bd..0ee4a0af3974 100644
--- a/arch/x86/include/asm/linkage.h
+++ b/arch/x86/include/asm/linkage.h
@@ -25,6 +25,18 @@
 #define RET	ret
 #endif
 
+#ifdef CONFIG_CFI_CLANG
+#define __CFI_TYPE(name)					\
+	.fill 7, 1, 0xCC ASM_NL					\
+	SYM_START(__cfi_##name, SYM_L_LOCAL, SYM_A_NONE)	\
+	int3 ASM_NL						\
+	int3 ASM_NL						\
+	mov __kcfi_typeid_##name, %eax ASM_NL			\
+	int3 ASM_NL						\
+	int3 ASM_NL						\
+	SYM_FUNC_END(__cfi_##name)
+#endif
+
 #else /* __ASSEMBLY__ */
 
 #ifdef CONFIG_SLS
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 1563fb995005..320e257eb4be 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -40,6 +40,7 @@
 #include <linux/hardirq.h>
 #include <linux/atomic.h>
 #include <linux/ioasid.h>
+#include <linux/cfi.h>
 
 #include <asm/stacktrace.h>
 #include <asm/processor.h>
@@ -295,6 +296,62 @@ static inline void handle_invalid_op(struct pt_regs *regs)
 		      ILL_ILLOPN, error_get_trap_addr(regs));
 }
 
+#ifdef CONFIG_CFI_CLANG
+static void decode_cfi_insn(struct pt_regs *regs, unsigned long *target,
+			    unsigned long *type)
+{
+	char buffer[MAX_INSN_SIZE];
+	struct insn insn;
+	int offset;
+
+	*target = *type = 0;
+
+	/*
+	 * The compiler generates the following instruction sequence
+	 * for indirect call checks:
+	 *
+	 *   cmpl    <id>, -6(%reg)	; 7 bytes
+	 *   je      .Ltmp1		; 2 bytes
+	 *   ud2			; <- addr
+	 *   .Ltmp1:
+	 *
+	 * Both the type and the target address can be decoded from the
+	 * cmpl instruction.
+	 */
+	if (copy_from_kernel_nofault(buffer, (void *)regs->ip - 9, MAX_INSN_SIZE))
+		return;
+	if (insn_decode_kernel(&insn, buffer))
+		return;
+	if (insn.opcode.value != 0x81 || X86_MODRM_REG(insn.modrm.value) != 7)
+		return;
+
+	*type = insn.immediate.value;
+
+	offset = insn_get_modrm_rm_off(&insn, regs);
+	if (offset < 0)
+		return;
+
+	*target = *(unsigned long *)((void *)regs + offset);
+}
+
+static enum bug_trap_type handle_cfi_failure(struct pt_regs *regs)
+{
+	if (is_cfi_trap(regs->ip)) {
+		unsigned long target, type;
+
+		decode_cfi_insn(regs, &target, &type);
+		return report_cfi_failure(regs, regs->ip, target, type);
+	}
+
+	return BUG_TRAP_TYPE_NONE;
+}
+#else
+static inline enum bug_trap_type handle_cfi_failure(struct pt_regs *regs)
+{
+	return BUG_TRAP_TYPE_NONE;
+}
+#endif /* CONFIG_CFI_CLANG */
+
 static noinstr bool handle_bug(struct pt_regs *regs)
 {
 	bool handled = false;
@@ -312,7 +369,8 @@ static noinstr bool handle_bug(struct pt_regs *regs)
 	 */
 	if (regs->flags & X86_EFLAGS_IF)
 		raw_local_irq_enable();
-	if (report_bug(regs->ip, regs) == BUG_TRAP_TYPE_WARN) {
+	if (report_bug(regs->ip, regs) == BUG_TRAP_TYPE_WARN ||
+	    handle_cfi_failure(regs) == BUG_TRAP_TYPE_WARN) {
 		regs->ip += LEN_UD2;
 		handled = true;
 	}
-- 
2.36.0.550.gb090851708-goog


^ permalink raw reply	[flat|nested] 174+ messages in thread

* [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
@ 2022-05-13 20:21   ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

With CONFIG_CFI_CLANG, the compiler injects a type preamble
immediately before each function and a check to validate the target
function type before indirect calls:

  ; type preamble
  __cfi_function:
    int3
    int3
    mov <id>, %eax
    int3
    int3
  function:
    ...
  ; indirect call check
    cmpl    <id>, -6(%r11)
    je      .Ltmp1
    ud2
  .Ltmp1:
    call    __x86_indirect_thunk_r11

Define the __CFI_TYPE helper macro for manual type annotations in
assembly code, add error handling for the CFI ud2 traps, and allow
CONFIG_CFI_CLANG to be selected on x86_64.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 arch/x86/Kconfig               |  2 ++
 arch/x86/include/asm/linkage.h | 12 +++++++
 arch/x86/kernel/traps.c        | 60 +++++++++++++++++++++++++++++++++-
 3 files changed, 73 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 4bed3abf444d..2e73d0792d48 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -108,6 +108,8 @@ config X86
 	select ARCH_SUPPORTS_PAGE_TABLE_CHECK	if X86_64
 	select ARCH_SUPPORTS_NUMA_BALANCING	if X86_64
 	select ARCH_SUPPORTS_KMAP_LOCAL_FORCE_MAP	if NR_CPUS <= 4096
+	select ARCH_SUPPORTS_CFI_CLANG		if X86_64
+	select ARCH_USES_CFI_TRAPS		if X86_64 && CFI_CLANG
 	select ARCH_SUPPORTS_LTO_CLANG
 	select ARCH_SUPPORTS_LTO_CLANG_THIN
 	select ARCH_USE_BUILTIN_BSWAP
diff --git a/arch/x86/include/asm/linkage.h b/arch/x86/include/asm/linkage.h
index 85865f1645bd..0ee4a0af3974 100644
--- a/arch/x86/include/asm/linkage.h
+++ b/arch/x86/include/asm/linkage.h
@@ -25,6 +25,18 @@
 #define RET	ret
 #endif
 
+#ifdef CONFIG_CFI_CLANG
+#define __CFI_TYPE(name)					\
+	.fill 7, 1, 0xCC ASM_NL					\
+	SYM_START(__cfi_##name, SYM_L_LOCAL, SYM_A_NONE)	\
+	int3 ASM_NL						\
+	int3 ASM_NL						\
+	mov __kcfi_typeid_##name, %eax ASM_NL			\
+	int3 ASM_NL						\
+	int3 ASM_NL						\
+	SYM_FUNC_END(__cfi_##name)
+#endif
+
 #else /* __ASSEMBLY__ */
 
 #ifdef CONFIG_SLS
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 1563fb995005..320e257eb4be 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -40,6 +40,7 @@
 #include <linux/hardirq.h>
 #include <linux/atomic.h>
 #include <linux/ioasid.h>
+#include <linux/cfi.h>
 
 #include <asm/stacktrace.h>
 #include <asm/processor.h>
@@ -295,6 +296,62 @@ static inline void handle_invalid_op(struct pt_regs *regs)
 		      ILL_ILLOPN, error_get_trap_addr(regs));
 }
 
+#ifdef CONFIG_CFI_CLANG
+static void decode_cfi_insn(struct pt_regs *regs, unsigned long *target,
+			    unsigned long *type)
+{
+	char buffer[MAX_INSN_SIZE];
+	struct insn insn;
+	int offset;
+
+	*target = *type = 0;
+
+	/*
+	 * The compiler generates the following instruction sequence
+	 * for indirect call checks:
+	 *
+	 *   cmpl    <id>, -6(%reg)	; 7 bytes
+	 *   je      .Ltmp1		; 2 bytes
+	 *   ud2			; <- addr
+	 *   .Ltmp1:
+	 *
+	 * Both the type and the target address can be decoded from the
+	 * cmpl instruction.
+	 */
+	if (copy_from_kernel_nofault(buffer, (void *)regs->ip - 9, MAX_INSN_SIZE))
+		return;
+	if (insn_decode_kernel(&insn, buffer))
+		return;
+	if (insn.opcode.value != 0x81 || X86_MODRM_REG(insn.modrm.value) != 7)
+		return;
+
+	*type = insn.immediate.value;
+
+	offset = insn_get_modrm_rm_off(&insn, regs);
+	if (offset < 0)
+		return;
+
+	*target = *(unsigned long *)((void *)regs + offset);
+}
+
+static enum bug_trap_type handle_cfi_failure(struct pt_regs *regs)
+{
+	if (is_cfi_trap(regs->ip)) {
+		unsigned long target, type;
+
+		decode_cfi_insn(regs, &target, &type);
+		return report_cfi_failure(regs, regs->ip, target, type);
+	}
+
+	return BUG_TRAP_TYPE_NONE;
+}
+#else
+static inline enum bug_trap_type handle_cfi_failure(struct pt_regs *regs)
+{
+	return BUG_TRAP_TYPE_NONE;
+}
+#endif /* CONFIG_CFI_CLANG */
+
 static noinstr bool handle_bug(struct pt_regs *regs)
 {
 	bool handled = false;
@@ -312,7 +369,8 @@ static noinstr bool handle_bug(struct pt_regs *regs)
 	 */
 	if (regs->flags & X86_EFLAGS_IF)
 		raw_local_irq_enable();
-	if (report_bug(regs->ip, regs) == BUG_TRAP_TYPE_WARN) {
+	if (report_bug(regs->ip, regs) == BUG_TRAP_TYPE_WARN ||
+	    handle_cfi_failure(regs) == BUG_TRAP_TYPE_WARN) {
 		regs->ip += LEN_UD2;
 		handled = true;
 	}
-- 
2.36.0.550.gb090851708-goog


_______________________________________________
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] 174+ messages in thread

* [RFC PATCH v2 21/21] init: Drop __nocfi from __init
  2022-05-13 20:21 ` Sami Tolvanen
@ 2022-05-13 20:21   ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

It's no longer necessary to disable CFI checking for all __init
functions. Drop the __nocfi attribute.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 include/linux/init.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/init.h b/include/linux/init.h
index 76058c9e0399..a0a90cd73ebe 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -47,7 +47,7 @@
 
 /* These are for everybody (although not all archs will actually
    discard it in modules) */
-#define __init		__section(".init.text") __cold  __latent_entropy __noinitretpoline __nocfi
+#define __init		__section(".init.text") __cold  __latent_entropy __noinitretpoline
 #define __initdata	__section(".init.data")
 #define __initconst	__section(".init.rodata")
 #define __exitdata	__section(".exit.data")
-- 
2.36.0.550.gb090851708-goog


^ permalink raw reply	[flat|nested] 174+ messages in thread

* [RFC PATCH v2 21/21] init: Drop __nocfi from __init
@ 2022-05-13 20:21   ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-13 20:21 UTC (permalink / raw)
  To: linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, Sami Tolvanen

It's no longer necessary to disable CFI checking for all __init
functions. Drop the __nocfi attribute.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 include/linux/init.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/init.h b/include/linux/init.h
index 76058c9e0399..a0a90cd73ebe 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -47,7 +47,7 @@
 
 /* These are for everybody (although not all archs will actually
    discard it in modules) */
-#define __init		__section(".init.text") __cold  __latent_entropy __noinitretpoline __nocfi
+#define __init		__section(".init.text") __cold  __latent_entropy __noinitretpoline
 #define __initdata	__section(".init.data")
 #define __initconst	__section(".init.rodata")
 #define __exitdata	__section(".exit.data")
-- 
2.36.0.550.gb090851708-goog


_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 01/21] efi/libstub: Filter out CC_FLAGS_CFI
  2022-05-13 20:21   ` Sami Tolvanen
@ 2022-05-14 21:42     ` Kees Cook
  -1 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:42 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:39PM -0700, Sami Tolvanen wrote:
> Explicitly filter out CC_FLAGS_CFI in preparation for the flags being
> removed from CC_FLAGS_LTO.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Is it worth merging all the "existing" CC_FLAGS_LTO/CFI splits into a
single patch? Either way:

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 01/21] efi/libstub: Filter out CC_FLAGS_CFI
@ 2022-05-14 21:42     ` Kees Cook
  0 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:42 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:39PM -0700, Sami Tolvanen wrote:
> Explicitly filter out CC_FLAGS_CFI in preparation for the flags being
> removed from CC_FLAGS_LTO.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Is it worth merging all the "existing" CC_FLAGS_LTO/CFI splits into a
single patch? Either way:

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 02/21] arm64/vdso: Filter out CC_FLAGS_CFI
  2022-05-13 20:21   ` Sami Tolvanen
@ 2022-05-14 21:42     ` Kees Cook
  -1 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:42 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:40PM -0700, Sami Tolvanen wrote:
> Explicitly filter out CC_FLAGS_CFI in preparation for the flags being
> removed from CC_FLAGS_LTO.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 02/21] arm64/vdso: Filter out CC_FLAGS_CFI
@ 2022-05-14 21:42     ` Kees Cook
  0 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:42 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:40PM -0700, Sami Tolvanen wrote:
> Explicitly filter out CC_FLAGS_CFI in preparation for the flags being
> removed from CC_FLAGS_LTO.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 03/21] kallsyms: Ignore __kcfi_typeid_
  2022-05-13 20:21   ` Sami Tolvanen
@ 2022-05-14 21:43     ` Kees Cook
  -1 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:43 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:41PM -0700, Sami Tolvanen wrote:
> The compiler generates CFI type identifier symbols for annotating
> assembly functions at link time. Ignore them in kallsyms.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 03/21] kallsyms: Ignore __kcfi_typeid_
@ 2022-05-14 21:43     ` Kees Cook
  0 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:43 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:41PM -0700, Sami Tolvanen wrote:
> The compiler generates CFI type identifier symbols for annotating
> assembly functions at link time. Ignore them in kallsyms.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 04/21] cfi: Remove CONFIG_CFI_CLANG_SHADOW
  2022-05-13 20:21   ` Sami Tolvanen
@ 2022-05-14 21:43     ` Kees Cook
  -1 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:43 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:42PM -0700, Sami Tolvanen wrote:
> In preparation to switching to -fsanitize=kcfi, remove support for the
> CFI module shadow that will no longer be needed.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

I like that most of this series is dropping code. :P

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 04/21] cfi: Remove CONFIG_CFI_CLANG_SHADOW
@ 2022-05-14 21:43     ` Kees Cook
  0 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:43 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:42PM -0700, Sami Tolvanen wrote:
> In preparation to switching to -fsanitize=kcfi, remove support for the
> CFI module shadow that will no longer be needed.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

I like that most of this series is dropping code. :P

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 05/21] cfi: Drop __CFI_ADDRESSABLE
  2022-05-13 20:21   ` Sami Tolvanen
@ 2022-05-14 21:44     ` Kees Cook
  -1 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:44 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:43PM -0700, Sami Tolvanen wrote:
> The __CFI_ADDRESSABLE macro is used for init_module and cleanup_module
> to ensure we have the address of the CFI jump table, and with
> CONFIG_X86_KERNEL_IBT to ensure LTO won't optimize away the symbols.
> As __CFI_ADDRESSABLE is no longer necessary with -fsanitize=kcfi, add
> a more flexible version of the __ADDRESSABLE macro and always ensure
> these symbols won't be dropped.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

These macros were so fun to build, though! ;)

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 05/21] cfi: Drop __CFI_ADDRESSABLE
@ 2022-05-14 21:44     ` Kees Cook
  0 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:44 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:43PM -0700, Sami Tolvanen wrote:
> The __CFI_ADDRESSABLE macro is used for init_module and cleanup_module
> to ensure we have the address of the CFI jump table, and with
> CONFIG_X86_KERNEL_IBT to ensure LTO won't optimize away the symbols.
> As __CFI_ADDRESSABLE is no longer necessary with -fsanitize=kcfi, add
> a more flexible version of the __ADDRESSABLE macro and always ensure
> these symbols won't be dropped.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

These macros were so fun to build, though! ;)

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 06/21] cfi: Switch to -fsanitize=kcfi
  2022-05-13 20:21   ` Sami Tolvanen
@ 2022-05-14 21:46     ` Kees Cook
  -1 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:46 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:44PM -0700, Sami Tolvanen wrote:
> Switch from Clang's original forward-edge control-flow integrity
> implementation to -fsanitize=kcfi, which is better suited for the
> kernel, as it doesn't require LTO, doesn't use a jump table that
> requires altering function references, and won't break cross-module
> function address equality.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Yes please. And just to note it somewhere: landing the KCFI
implementation on Clang depends on this series being accepted (i.e. if
the arm64 and x86 maintainers are happy with this series, then that'll
unblock landing it in Clang (no reason to land something that won't get
used.)

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 06/21] cfi: Switch to -fsanitize=kcfi
@ 2022-05-14 21:46     ` Kees Cook
  0 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:46 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:44PM -0700, Sami Tolvanen wrote:
> Switch from Clang's original forward-edge control-flow integrity
> implementation to -fsanitize=kcfi, which is better suited for the
> kernel, as it doesn't require LTO, doesn't use a jump table that
> requires altering function references, and won't break cross-module
> function address equality.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Yes please. And just to note it somewhere: landing the KCFI
implementation on Clang depends on this series being accepted (i.e. if
the arm64 and x86 maintainers are happy with this series, then that'll
unblock landing it in Clang (no reason to land something that won't get
used.)

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 07/21] cfi: Add type helper macros
  2022-05-13 20:21   ` Sami Tolvanen
@ 2022-05-14 21:49     ` Kees Cook
  -1 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:49 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:45PM -0700, Sami Tolvanen wrote:
> With CONFIG_CFI_CLANG, assembly functions called indirectly
> from C code must be annotated with type identifiers to pass CFI
> checking. The compiler emits a __kcfi_typeid_<function> symbol for
> each address-taken function declaration in C, which contains the
> expected type identifier. Add typed versions of SYM_FUNC_START and
> SYM_FUNC_START_ALIAS, which emit the type identifier before the
> function.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

And the reason to not make this change universally (i.e. directly in
SYM_FUNC_START) is to minimize how many of these symbol annotations get
emitted? (And to more directly indicate which asm is called indirectly?)

What happens if an asm function is called indirectly and it doesn't have
this annotation? (Is this case detectable at compile-time?)

Regardless:

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 07/21] cfi: Add type helper macros
@ 2022-05-14 21:49     ` Kees Cook
  0 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:49 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:45PM -0700, Sami Tolvanen wrote:
> With CONFIG_CFI_CLANG, assembly functions called indirectly
> from C code must be annotated with type identifiers to pass CFI
> checking. The compiler emits a __kcfi_typeid_<function> symbol for
> each address-taken function declaration in C, which contains the
> expected type identifier. Add typed versions of SYM_FUNC_START and
> SYM_FUNC_START_ALIAS, which emit the type identifier before the
> function.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

And the reason to not make this change universally (i.e. directly in
SYM_FUNC_START) is to minimize how many of these symbol annotations get
emitted? (And to more directly indicate which asm is called indirectly?)

What happens if an asm function is called indirectly and it doesn't have
this annotation? (Is this case detectable at compile-time?)

Regardless:

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 08/21] psci: Fix the function type for psci_initcall_t
  2022-05-13 20:21   ` Sami Tolvanen
@ 2022-05-14 21:50     ` Kees Cook
  -1 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:50 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:46PM -0700, Sami Tolvanen wrote:
> Functions called through a psci_initcall_t pointer all have
> non-const arguments. Fix the type definition to avoid tripping
> indirect call checks with CFI_CLANG.
> 
> Reported-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

This could land separately from this series, too, yes?

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 08/21] psci: Fix the function type for psci_initcall_t
@ 2022-05-14 21:50     ` Kees Cook
  0 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:50 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:46PM -0700, Sami Tolvanen wrote:
> Functions called through a psci_initcall_t pointer all have
> non-const arguments. Fix the type definition to avoid tripping
> indirect call checks with CFI_CLANG.
> 
> Reported-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

This could land separately from this series, too, yes?

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 09/21] arm64: Add types to indirect called assembly functions
  2022-05-13 20:21   ` Sami Tolvanen
@ 2022-05-14 21:50     ` Kees Cook
  -1 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:50 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:47PM -0700, Sami Tolvanen wrote:
> With CONFIG_CFI_CLANG, assembly functions indirectly called from C
> code must be annotated with type identifiers to pass CFI checking. Use
> SYM_TYPED_FUNC_START for indirectly called functions.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Sort of related to my question about SYM_TYPED_FUNC_START itself, how
were these cases identified?

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 09/21] arm64: Add types to indirect called assembly functions
@ 2022-05-14 21:50     ` Kees Cook
  0 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:50 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:47PM -0700, Sami Tolvanen wrote:
> With CONFIG_CFI_CLANG, assembly functions indirectly called from C
> code must be annotated with type identifiers to pass CFI checking. Use
> SYM_TYPED_FUNC_START for indirectly called functions.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Sort of related to my question about SYM_TYPED_FUNC_START itself, how
were these cases identified?

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 10/21] arm64: Add CFI error handling
  2022-05-13 20:21   ` Sami Tolvanen
@ 2022-05-14 21:51     ` Kees Cook
  -1 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:51 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:48PM -0700, Sami Tolvanen wrote:
> With -fsanitize=kcfi, CFI always traps. Add arm64 support for handling
> CFI failures. The registers containing the target address and the
> expected type are encoded in the first ten bits of the ESR as follows:
> 
>  - 0-4: n, where the register Xn contains the target address
>  - 5-9: m, where the register Wm contains the type hash
> 
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

It might be nice just to include an example exception Oops in this
commit log.

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 10/21] arm64: Add CFI error handling
@ 2022-05-14 21:51     ` Kees Cook
  0 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:51 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:48PM -0700, Sami Tolvanen wrote:
> With -fsanitize=kcfi, CFI always traps. Add arm64 support for handling
> CFI failures. The registers containing the target address and the
> expected type are encoded in the first ten bits of the ESR as follows:
> 
>  - 0-4: n, where the register Xn contains the target address
>  - 5-9: m, where the register Wm contains the type hash
> 
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

It might be nice just to include an example exception Oops in this
commit log.

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 11/21] arm64: Drop unneeded __nocfi attributes
  2022-05-13 20:21   ` Sami Tolvanen
@ 2022-05-14 21:54     ` Kees Cook
  -1 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:54 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:49PM -0700, Sami Tolvanen wrote:
> With -fsanitize=kcfi, CONFIG_CFI_CLANG no longer has issues
> with address space confusion in functions that switch to linear
> mapping. Now that the indirectly called assembly functions have
> type annotations, drop the __nocfi attributes.
> 
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

It looks like there are still other cases that continue to require
__nocfi, yes? It looks like after this series, it's still BPF?

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 11/21] arm64: Drop unneeded __nocfi attributes
@ 2022-05-14 21:54     ` Kees Cook
  0 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:54 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:49PM -0700, Sami Tolvanen wrote:
> With -fsanitize=kcfi, CONFIG_CFI_CLANG no longer has issues
> with address space confusion in functions that switch to linear
> mapping. Now that the indirectly called assembly functions have
> type annotations, drop the __nocfi attributes.
> 
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

It looks like there are still other cases that continue to require
__nocfi, yes? It looks like after this series, it's still BPF?

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 12/21] treewide: Drop function_nocfi
  2022-05-13 20:21   ` Sami Tolvanen
@ 2022-05-14 21:54     ` Kees Cook
  -1 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:54 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:50PM -0700, Sami Tolvanen wrote:
> With -fsanitize=kcfi, we no longer need function_nocfi() as
> the compiler won't change function references to point to a
> jump table. Remove all implementations and uses of the macro.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 12/21] treewide: Drop function_nocfi
@ 2022-05-14 21:54     ` Kees Cook
  0 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:54 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:50PM -0700, Sami Tolvanen wrote:
> With -fsanitize=kcfi, we no longer need function_nocfi() as
> the compiler won't change function references to point to a
> jump table. Remove all implementations and uses of the macro.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 13/21] treewide: Drop WARN_ON_FUNCTION_MISMATCH
  2022-05-13 20:21   ` Sami Tolvanen
@ 2022-05-14 21:54     ` Kees Cook
  -1 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:54 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:51PM -0700, Sami Tolvanen wrote:
> CONFIG_CFI_CLANG no longer breaks cross-module function address
> equality, which makes WARN_ON_FUNCTION_MISMATCH unnecessary. Remove
> the definition and switch back to WARN_ON_ONCE.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

This one always felt like a trade-off, so I'm happy to see it go. :)

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 13/21] treewide: Drop WARN_ON_FUNCTION_MISMATCH
@ 2022-05-14 21:54     ` Kees Cook
  0 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:54 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:51PM -0700, Sami Tolvanen wrote:
> CONFIG_CFI_CLANG no longer breaks cross-module function address
> equality, which makes WARN_ON_FUNCTION_MISMATCH unnecessary. Remove
> the definition and switch back to WARN_ON_ONCE.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

This one always felt like a trade-off, so I'm happy to see it go. :)

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 14/21] treewide: Drop __cficanonical
  2022-05-13 20:21   ` Sami Tolvanen
@ 2022-05-14 21:56     ` Kees Cook
  -1 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:56 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:52PM -0700, Sami Tolvanen wrote:
> CONFIG_CFI_CLANG doesn't use a jump table anymore and therefore,
> won't change function references to point elsewhere. Remove the
> __cficanonical attribute and all uses of it.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> ---
>  include/linux/compiler_types.h | 4 ----
>  include/linux/init.h           | 4 ++--
>  include/linux/pci.h            | 4 ++--
>  3 files changed, 4 insertions(+), 8 deletions(-)

I think this is missing removing it from include/linux/compiler-clang.h ?

With that done (or explained why not):

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 14/21] treewide: Drop __cficanonical
@ 2022-05-14 21:56     ` Kees Cook
  0 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:56 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:52PM -0700, Sami Tolvanen wrote:
> CONFIG_CFI_CLANG doesn't use a jump table anymore and therefore,
> won't change function references to point elsewhere. Remove the
> __cficanonical attribute and all uses of it.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> ---
>  include/linux/compiler_types.h | 4 ----
>  include/linux/init.h           | 4 ++--
>  include/linux/pci.h            | 4 ++--
>  3 files changed, 4 insertions(+), 8 deletions(-)

I think this is missing removing it from include/linux/compiler-clang.h ?

With that done (or explained why not):

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 15/21] objtool: Don't warn about __cfi_ preambles falling through
  2022-05-13 20:21   ` Sami Tolvanen
@ 2022-05-14 21:56     ` Kees Cook
  -1 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:56 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:53PM -0700, Sami Tolvanen wrote:
> The __cfi_ preambles contain valid instructions, which embed KCFI
> type information in the following format:
> 
>   __cfi_function:
>     int3
>     int3
>     mov <id>, %eax
>     int3
>     int3
>   function:
>     ...
> 
> While the preambles are STT_FUNC and contain valid instructions,
> they are not executed and always fall through. Skip the warning for
> them.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 15/21] objtool: Don't warn about __cfi_ preambles falling through
@ 2022-05-14 21:56     ` Kees Cook
  0 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:56 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:53PM -0700, Sami Tolvanen wrote:
> The __cfi_ preambles contain valid instructions, which embed KCFI
> type information in the following format:
> 
>   __cfi_function:
>     int3
>     int3
>     mov <id>, %eax
>     int3
>     int3
>   function:
>     ...
> 
> While the preambles are STT_FUNC and contain valid instructions,
> they are not executed and always fall through. Skip the warning for
> them.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 16/21] x86/tools/relocs: Ignore __kcfi_typeid_ relocations
  2022-05-13 20:21   ` Sami Tolvanen
@ 2022-05-14 21:57     ` Kees Cook
  -1 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:57 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:54PM -0700, Sami Tolvanen wrote:
> Ignore __kcfi_typeid_ symbols. These are compiler-generated constants
> that contain CFI type identifiers.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 16/21] x86/tools/relocs: Ignore __kcfi_typeid_ relocations
@ 2022-05-14 21:57     ` Kees Cook
  0 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:57 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:54PM -0700, Sami Tolvanen wrote:
> Ignore __kcfi_typeid_ symbols. These are compiler-generated constants
> that contain CFI type identifiers.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 17/21] x86: Add types to indirectly called assembly functions
  2022-05-13 20:21   ` Sami Tolvanen
@ 2022-05-14 21:58     ` Kees Cook
  -1 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:58 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:55PM -0700, Sami Tolvanen wrote:
> With CONFIG_CFI_CLANG, assembly functions indirectly called from C code
> must be annotated with type identifiers to pass CFI checking.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 17/21] x86: Add types to indirectly called assembly functions
@ 2022-05-14 21:58     ` Kees Cook
  0 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:58 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:55PM -0700, Sami Tolvanen wrote:
> With CONFIG_CFI_CLANG, assembly functions indirectly called from C code
> must be annotated with type identifiers to pass CFI checking.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 18/21] x86/purgatory: Disable CFI
  2022-05-13 20:21   ` Sami Tolvanen
@ 2022-05-14 21:58     ` Kees Cook
  -1 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:58 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:56PM -0700, Sami Tolvanen wrote:
> Disable CONFIG_CFI_CLANG for the stand-alone purgatory.ro.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 18/21] x86/purgatory: Disable CFI
@ 2022-05-14 21:58     ` Kees Cook
  0 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:58 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:56PM -0700, Sami Tolvanen wrote:
> Disable CONFIG_CFI_CLANG for the stand-alone purgatory.ro.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 19/21] x86/vdso: Disable CFI
  2022-05-13 20:21   ` Sami Tolvanen
@ 2022-05-14 21:58     ` Kees Cook
  -1 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:58 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:57PM -0700, Sami Tolvanen wrote:
> CC_FLAGS_LTO no longer includes CC_FLAGS_CFI, so filter these flags
> out as well.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 19/21] x86/vdso: Disable CFI
@ 2022-05-14 21:58     ` Kees Cook
  0 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 21:58 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:57PM -0700, Sami Tolvanen wrote:
> CC_FLAGS_LTO no longer includes CC_FLAGS_CFI, so filter these flags
> out as well.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
  2022-05-13 20:21   ` Sami Tolvanen
@ 2022-05-14 22:02     ` Kees Cook
  -1 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 22:02 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:58PM -0700, Sami Tolvanen wrote:
> With CONFIG_CFI_CLANG, the compiler injects a type preamble
> immediately before each function and a check to validate the target
> function type before indirect calls:
> 
>   ; type preamble
>   __cfi_function:
>     int3
>     int3
>     mov <id>, %eax
>     int3
>     int3
>   function:
>     ...
>   ; indirect call check
>     cmpl    <id>, -6(%r11)
>     je      .Ltmp1
>     ud2
>   .Ltmp1:
>     call    __x86_indirect_thunk_r11
> 
> Define the __CFI_TYPE helper macro for manual type annotations in
> assembly code, add error handling for the CFI ud2 traps, and allow
> CONFIG_CFI_CLANG to be selected on x86_64.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> ---
>  arch/x86/Kconfig               |  2 ++
>  arch/x86/include/asm/linkage.h | 12 +++++++
>  arch/x86/kernel/traps.c        | 60 +++++++++++++++++++++++++++++++++-
>  3 files changed, 73 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 4bed3abf444d..2e73d0792d48 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -108,6 +108,8 @@ config X86
>  	select ARCH_SUPPORTS_PAGE_TABLE_CHECK	if X86_64
>  	select ARCH_SUPPORTS_NUMA_BALANCING	if X86_64
>  	select ARCH_SUPPORTS_KMAP_LOCAL_FORCE_MAP	if NR_CPUS <= 4096
> +	select ARCH_SUPPORTS_CFI_CLANG		if X86_64
> +	select ARCH_USES_CFI_TRAPS		if X86_64 && CFI_CLANG
>  	select ARCH_SUPPORTS_LTO_CLANG
>  	select ARCH_SUPPORTS_LTO_CLANG_THIN
>  	select ARCH_USE_BUILTIN_BSWAP
> diff --git a/arch/x86/include/asm/linkage.h b/arch/x86/include/asm/linkage.h
> index 85865f1645bd..0ee4a0af3974 100644
> --- a/arch/x86/include/asm/linkage.h
> +++ b/arch/x86/include/asm/linkage.h
> @@ -25,6 +25,18 @@
>  #define RET	ret
>  #endif
>  
> +#ifdef CONFIG_CFI_CLANG
> +#define __CFI_TYPE(name)					\
> +	.fill 7, 1, 0xCC ASM_NL					\
> +	SYM_START(__cfi_##name, SYM_L_LOCAL, SYM_A_NONE)	\
> +	int3 ASM_NL						\
> +	int3 ASM_NL						\
> +	mov __kcfi_typeid_##name, %eax ASM_NL			\
> +	int3 ASM_NL						\
> +	int3 ASM_NL						\
> +	SYM_FUNC_END(__cfi_##name)
> +#endif
> +
>  #else /* __ASSEMBLY__ */
>  
>  #ifdef CONFIG_SLS
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index 1563fb995005..320e257eb4be 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -40,6 +40,7 @@
>  #include <linux/hardirq.h>
>  #include <linux/atomic.h>
>  #include <linux/ioasid.h>
> +#include <linux/cfi.h>
>  
>  #include <asm/stacktrace.h>
>  #include <asm/processor.h>
> @@ -295,6 +296,62 @@ static inline void handle_invalid_op(struct pt_regs *regs)
>  		      ILL_ILLOPN, error_get_trap_addr(regs));
>  }
>  
> +#ifdef CONFIG_CFI_CLANG
> +static void decode_cfi_insn(struct pt_regs *regs, unsigned long *target,
> +			    unsigned long *type)
> +{
> +	char buffer[MAX_INSN_SIZE];
> +	struct insn insn;
> +	int offset;
> +
> +	*target = *type = 0;

Should report_cfi_failure() have some additional hinting for the case
where target/type are zero? Like, "hey, got an inexplicable CFI failure
here, but preamble decode failed. Yikes!"

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
@ 2022-05-14 22:02     ` Kees Cook
  0 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 22:02 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:58PM -0700, Sami Tolvanen wrote:
> With CONFIG_CFI_CLANG, the compiler injects a type preamble
> immediately before each function and a check to validate the target
> function type before indirect calls:
> 
>   ; type preamble
>   __cfi_function:
>     int3
>     int3
>     mov <id>, %eax
>     int3
>     int3
>   function:
>     ...
>   ; indirect call check
>     cmpl    <id>, -6(%r11)
>     je      .Ltmp1
>     ud2
>   .Ltmp1:
>     call    __x86_indirect_thunk_r11
> 
> Define the __CFI_TYPE helper macro for manual type annotations in
> assembly code, add error handling for the CFI ud2 traps, and allow
> CONFIG_CFI_CLANG to be selected on x86_64.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> ---
>  arch/x86/Kconfig               |  2 ++
>  arch/x86/include/asm/linkage.h | 12 +++++++
>  arch/x86/kernel/traps.c        | 60 +++++++++++++++++++++++++++++++++-
>  3 files changed, 73 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 4bed3abf444d..2e73d0792d48 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -108,6 +108,8 @@ config X86
>  	select ARCH_SUPPORTS_PAGE_TABLE_CHECK	if X86_64
>  	select ARCH_SUPPORTS_NUMA_BALANCING	if X86_64
>  	select ARCH_SUPPORTS_KMAP_LOCAL_FORCE_MAP	if NR_CPUS <= 4096
> +	select ARCH_SUPPORTS_CFI_CLANG		if X86_64
> +	select ARCH_USES_CFI_TRAPS		if X86_64 && CFI_CLANG
>  	select ARCH_SUPPORTS_LTO_CLANG
>  	select ARCH_SUPPORTS_LTO_CLANG_THIN
>  	select ARCH_USE_BUILTIN_BSWAP
> diff --git a/arch/x86/include/asm/linkage.h b/arch/x86/include/asm/linkage.h
> index 85865f1645bd..0ee4a0af3974 100644
> --- a/arch/x86/include/asm/linkage.h
> +++ b/arch/x86/include/asm/linkage.h
> @@ -25,6 +25,18 @@
>  #define RET	ret
>  #endif
>  
> +#ifdef CONFIG_CFI_CLANG
> +#define __CFI_TYPE(name)					\
> +	.fill 7, 1, 0xCC ASM_NL					\
> +	SYM_START(__cfi_##name, SYM_L_LOCAL, SYM_A_NONE)	\
> +	int3 ASM_NL						\
> +	int3 ASM_NL						\
> +	mov __kcfi_typeid_##name, %eax ASM_NL			\
> +	int3 ASM_NL						\
> +	int3 ASM_NL						\
> +	SYM_FUNC_END(__cfi_##name)
> +#endif
> +
>  #else /* __ASSEMBLY__ */
>  
>  #ifdef CONFIG_SLS
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index 1563fb995005..320e257eb4be 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -40,6 +40,7 @@
>  #include <linux/hardirq.h>
>  #include <linux/atomic.h>
>  #include <linux/ioasid.h>
> +#include <linux/cfi.h>
>  
>  #include <asm/stacktrace.h>
>  #include <asm/processor.h>
> @@ -295,6 +296,62 @@ static inline void handle_invalid_op(struct pt_regs *regs)
>  		      ILL_ILLOPN, error_get_trap_addr(regs));
>  }
>  
> +#ifdef CONFIG_CFI_CLANG
> +static void decode_cfi_insn(struct pt_regs *regs, unsigned long *target,
> +			    unsigned long *type)
> +{
> +	char buffer[MAX_INSN_SIZE];
> +	struct insn insn;
> +	int offset;
> +
> +	*target = *type = 0;

Should report_cfi_failure() have some additional hinting for the case
where target/type are zero? Like, "hey, got an inexplicable CFI failure
here, but preamble decode failed. Yikes!"

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 21/21] init: Drop __nocfi from __init
  2022-05-13 20:21   ` Sami Tolvanen
@ 2022-05-14 22:03     ` Kees Cook
  -1 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 22:03 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:59PM -0700, Sami Tolvanen wrote:
> It's no longer necessary to disable CFI checking for all __init
> functions. Drop the __nocfi attribute.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Maybe move this up after patch 11 (the arm64-wide __nocfi removal)?

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 21/21] init: Drop __nocfi from __init
@ 2022-05-14 22:03     ` Kees Cook
  0 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-14 22:03 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:59PM -0700, Sami Tolvanen wrote:
> It's no longer necessary to disable CFI checking for all __init
> functions. Drop the __nocfi attribute.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Maybe move this up after patch 11 (the arm64-wide __nocfi removal)?

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
  2022-05-13 20:21   ` Sami Tolvanen
@ 2022-05-15  3:19     ` Kees Cook
  -1 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-15  3:19 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:58PM -0700, Sami Tolvanen wrote:
> With CONFIG_CFI_CLANG, the compiler injects a type preamble
> immediately before each function and a check to validate the target
> function type before indirect calls:
> 
>   ; type preamble
>   __cfi_function:
>     int3
>     int3
>     mov <id>, %eax
>     int3
>     int3
>   function:
>     ...
>   ; indirect call check
>     cmpl    <id>, -6(%r11)
>     je      .Ltmp1
>     ud2
>   .Ltmp1:
>     call    __x86_indirect_thunk_r11
> 
> Define the __CFI_TYPE helper macro for manual type annotations in
> assembly code, add error handling for the CFI ud2 traps, and allow
> CONFIG_CFI_CLANG to be selected on x86_64.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Looks good testing with LKDTM...

$ echo CFI_FORWARD_PROTO | cat >/sys/kernel/debug/provoke-crash/DIRECT
[  144.084017] lkdtm: Performing direct entry CFI_FORWARD_PROTO
[  144.086138] lkdtm: Calling matched prototype ...
[  144.087833] lkdtm: Calling mismatched prototype ...
[  144.089777] CFI failure at lkdtm_CFI_FORWARD_PROTO+0x34/0x67 [lkdtm] (target: lkdtm_increment_int+0x0/0x7 [lkdtm]; expected type: 0x7e0c52a5)


Tested-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
@ 2022-05-15  3:19     ` Kees Cook
  0 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-15  3:19 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:58PM -0700, Sami Tolvanen wrote:
> With CONFIG_CFI_CLANG, the compiler injects a type preamble
> immediately before each function and a check to validate the target
> function type before indirect calls:
> 
>   ; type preamble
>   __cfi_function:
>     int3
>     int3
>     mov <id>, %eax
>     int3
>     int3
>   function:
>     ...
>   ; indirect call check
>     cmpl    <id>, -6(%r11)
>     je      .Ltmp1
>     ud2
>   .Ltmp1:
>     call    __x86_indirect_thunk_r11
> 
> Define the __CFI_TYPE helper macro for manual type annotations in
> assembly code, add error handling for the CFI ud2 traps, and allow
> CONFIG_CFI_CLANG to be selected on x86_64.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Looks good testing with LKDTM...

$ echo CFI_FORWARD_PROTO | cat >/sys/kernel/debug/provoke-crash/DIRECT
[  144.084017] lkdtm: Performing direct entry CFI_FORWARD_PROTO
[  144.086138] lkdtm: Calling matched prototype ...
[  144.087833] lkdtm: Calling mismatched prototype ...
[  144.089777] CFI failure at lkdtm_CFI_FORWARD_PROTO+0x34/0x67 [lkdtm] (target: lkdtm_increment_int+0x0/0x7 [lkdtm]; expected type: 0x7e0c52a5)


Tested-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 06/21] cfi: Switch to -fsanitize=kcfi
  2022-05-13 20:21   ` Sami Tolvanen
@ 2022-05-15  3:41     ` Kees Cook
  -1 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-15  3:41 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:44PM -0700, Sami Tolvanen wrote:
> Switch from Clang's original forward-edge control-flow integrity
> implementation to -fsanitize=kcfi, which is better suited for the
> kernel, as it doesn't require LTO, doesn't use a jump table that
> requires altering function references, and won't break cross-module
> function address equality.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Looks good on arm64 with LKDTM, too:

[   96.904483] lkdtm: Performing direct entry CFI_FORWARD_PROTO
[   96.904718] lkdtm: Calling matched prototype ...
[   96.904829] lkdtm: Calling mismatched prototype ...
[   96.905250] CFI failure at lkdtm_CFI_FORWARD_PROTO+0x54/0x94 [lkdtm] (target: lkdtm_increment_int+0x0/0x20 [lkdtm]; expected type: 0x7e0c52a5)

Tested-by: Kees Cook <keescook@chromium.org>

-Kees

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 06/21] cfi: Switch to -fsanitize=kcfi
@ 2022-05-15  3:41     ` Kees Cook
  0 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-15  3:41 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:44PM -0700, Sami Tolvanen wrote:
> Switch from Clang's original forward-edge control-flow integrity
> implementation to -fsanitize=kcfi, which is better suited for the
> kernel, as it doesn't require LTO, doesn't use a jump table that
> requires altering function references, and won't break cross-module
> function address equality.
> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Looks good on arm64 with LKDTM, too:

[   96.904483] lkdtm: Performing direct entry CFI_FORWARD_PROTO
[   96.904718] lkdtm: Calling matched prototype ...
[   96.904829] lkdtm: Calling mismatched prototype ...
[   96.905250] CFI failure at lkdtm_CFI_FORWARD_PROTO+0x54/0x94 [lkdtm] (target: lkdtm_increment_int+0x0/0x20 [lkdtm]; expected type: 0x7e0c52a5)

Tested-by: Kees Cook <keescook@chromium.org>

-Kees

-- 
Kees Cook

_______________________________________________
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] 174+ messages in thread

* RE: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
  2022-05-13 20:21   ` Sami Tolvanen
@ 2022-05-16  8:32     ` David Laight
  -1 siblings, 0 replies; 174+ messages in thread
From: David Laight @ 2022-05-16  8:32 UTC (permalink / raw)
  To: 'Sami Tolvanen', linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

From: Sami Tolvanen
> Sent: 13 May 2022 21:22
> 
> With CONFIG_CFI_CLANG, the compiler injects a type preamble
> immediately before each function and a check to validate the target
> function type before indirect calls:
> 
>   ; type preamble
>   __cfi_function:
>     int3
>     int3
>     mov <id>, %eax

Interesting - since this code can't be executed there is no
point adding an instruction 'prefix' to the 32bit constant.
 
>     int3
>     int3
>   function:
>     ...
>   ; indirect call check
>     cmpl    <id>, -6(%r11)
>     je      .Ltmp1
>     ud2
>   .Ltmp1:
>     call    __x86_indirect_thunk_r11
> 
> Define the __CFI_TYPE helper macro for manual type annotations in
> assembly code, add error handling for the CFI ud2 traps, and allow
> CONFIG_CFI_CLANG to be selected on x86_64.
> 
...
> +
> +	/*
> +	 * The compiler generates the following instruction sequence
> +	 * for indirect call checks:
> +	 *
> +	 *   cmpl    <id>, -6(%reg)	; 7 bytes

If the <id> is between -128 and 127 then an 8bit constant
(sign extended) might be used.
Possibly the compiler forces the assembler to generate the
long form.

There could also be a REX prefix.
That will break any code that tries to use %reg.

> +	 *   je      .Ltmp1		; 2 bytes
> +	 *   ud2			; <- addr
> +	 *   .Ltmp1:
> +	 *
> +	 * Both the type and the target address can be decoded from the
> +	 * cmpl instruction.
> +	 */
> +	if (copy_from_kernel_nofault(buffer, (void *)regs->ip - 9, MAX_INSN_SIZE))
> +		return;
> +	if (insn_decode_kernel(&insn, buffer))
> +		return;
> +	if (insn.opcode.value != 0x81 || X86_MODRM_REG(insn.modrm.value) != 7)
> +		return;

Since you are looking for a very specific opcode why bother
calling insn_decode_kernel() - just check for the required (masked)
byte values.

> +
> +	*type = insn.immediate.value;
> +
> +	offset = insn_get_modrm_rm_off(&insn, regs);

Given the expected instruction, isn't that -6 ??
> +	if (offset < 0)
> +		return;
> +
> +	*target = *(unsigned long *)((void *)regs + offset);

WTF is that calculating??

> +}
...

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

^ permalink raw reply	[flat|nested] 174+ messages in thread

* RE: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
@ 2022-05-16  8:32     ` David Laight
  0 siblings, 0 replies; 174+ messages in thread
From: David Laight @ 2022-05-16  8:32 UTC (permalink / raw)
  To: 'Sami Tolvanen', linux-kernel
  Cc: Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

From: Sami Tolvanen
> Sent: 13 May 2022 21:22
> 
> With CONFIG_CFI_CLANG, the compiler injects a type preamble
> immediately before each function and a check to validate the target
> function type before indirect calls:
> 
>   ; type preamble
>   __cfi_function:
>     int3
>     int3
>     mov <id>, %eax

Interesting - since this code can't be executed there is no
point adding an instruction 'prefix' to the 32bit constant.
 
>     int3
>     int3
>   function:
>     ...
>   ; indirect call check
>     cmpl    <id>, -6(%r11)
>     je      .Ltmp1
>     ud2
>   .Ltmp1:
>     call    __x86_indirect_thunk_r11
> 
> Define the __CFI_TYPE helper macro for manual type annotations in
> assembly code, add error handling for the CFI ud2 traps, and allow
> CONFIG_CFI_CLANG to be selected on x86_64.
> 
...
> +
> +	/*
> +	 * The compiler generates the following instruction sequence
> +	 * for indirect call checks:
> +	 *
> +	 *   cmpl    <id>, -6(%reg)	; 7 bytes

If the <id> is between -128 and 127 then an 8bit constant
(sign extended) might be used.
Possibly the compiler forces the assembler to generate the
long form.

There could also be a REX prefix.
That will break any code that tries to use %reg.

> +	 *   je      .Ltmp1		; 2 bytes
> +	 *   ud2			; <- addr
> +	 *   .Ltmp1:
> +	 *
> +	 * Both the type and the target address can be decoded from the
> +	 * cmpl instruction.
> +	 */
> +	if (copy_from_kernel_nofault(buffer, (void *)regs->ip - 9, MAX_INSN_SIZE))
> +		return;
> +	if (insn_decode_kernel(&insn, buffer))
> +		return;
> +	if (insn.opcode.value != 0x81 || X86_MODRM_REG(insn.modrm.value) != 7)
> +		return;

Since you are looking for a very specific opcode why bother
calling insn_decode_kernel() - just check for the required (masked)
byte values.

> +
> +	*type = insn.immediate.value;
> +
> +	offset = insn_get_modrm_rm_off(&insn, regs);

Given the expected instruction, isn't that -6 ??
> +	if (offset < 0)
> +		return;
> +
> +	*target = *(unsigned long *)((void *)regs + offset);

WTF is that calculating??

> +}
...

	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] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
  2022-05-13 20:21   ` Sami Tolvanen
@ 2022-05-16  9:54     ` Peter Zijlstra
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Zijlstra @ 2022-05-16  9:54 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Kees Cook, Josh Poimboeuf, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:58PM -0700, Sami Tolvanen wrote:
> With CONFIG_CFI_CLANG, the compiler injects a type preamble
> immediately before each function and a check to validate the target
> function type before indirect calls:
> 
>   ; type preamble
>   __cfi_function:
>     int3
>     int3
>     mov <id>, %eax
>     int3
>     int3
>   function:
>     ...

When I enable CFI_CLANG and X86_KERNEL_IBT I get:

0000000000000c80 <__cfi_io_schedule_timeout>:
c80:   cc                      int3
c81:   cc                      int3
c82:   b8 b5 b1 39 b3          mov    $0xb339b1b5,%eax
c87:   cc                      int3
c88:   cc                      int3

0000000000000c89 <io_schedule_timeout>:
c89:   f3 0f 1e fa             endbr64


That seems unfortunate. Would it be possible to get an additional
compiler option to suppress the endbr for all symbols that get a __cfi_
preaamble?

Also, perhaps s/CFI_CLANG/KERNEL_CFI/ or somesuch, so that GCC might
also implement this same scheme (in time)?

>   ; indirect call check
>     cmpl    <id>, -6(%r11)
>     je      .Ltmp1
>     ud2
>   .Ltmp1:
>     call    __x86_indirect_thunk_r11

The first one I try and find looks like:

26:       41 81 7b fa a6 96 9e 38         cmpl   $0x389e96a6,-0x6(%r11)
2e:       74 02                   je     32 <__traceiter_sched_kthread_stop+0x29>
30:       0f 0b                   ud2
32:       4c 89 f6                mov    %r14,%rsi
35:       e8 00 00 00 00          call   3a <__traceiter_sched_kthread_stop+0x31> 36: R_X86_64_PLT32      __x86_indirect_thunk_r11-0x4

This must not be. If I'm to rewrite that lot to:

  movl	$\hash, %r10d
  sub	$9, %r11
  call	*%r11
  .nop  4

Then there must not be spurious instruction in between the ud2 and the
indirect call/retpoline thing.

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
@ 2022-05-16  9:54     ` Peter Zijlstra
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Zijlstra @ 2022-05-16  9:54 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Kees Cook, Josh Poimboeuf, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:58PM -0700, Sami Tolvanen wrote:
> With CONFIG_CFI_CLANG, the compiler injects a type preamble
> immediately before each function and a check to validate the target
> function type before indirect calls:
> 
>   ; type preamble
>   __cfi_function:
>     int3
>     int3
>     mov <id>, %eax
>     int3
>     int3
>   function:
>     ...

When I enable CFI_CLANG and X86_KERNEL_IBT I get:

0000000000000c80 <__cfi_io_schedule_timeout>:
c80:   cc                      int3
c81:   cc                      int3
c82:   b8 b5 b1 39 b3          mov    $0xb339b1b5,%eax
c87:   cc                      int3
c88:   cc                      int3

0000000000000c89 <io_schedule_timeout>:
c89:   f3 0f 1e fa             endbr64


That seems unfortunate. Would it be possible to get an additional
compiler option to suppress the endbr for all symbols that get a __cfi_
preaamble?

Also, perhaps s/CFI_CLANG/KERNEL_CFI/ or somesuch, so that GCC might
also implement this same scheme (in time)?

>   ; indirect call check
>     cmpl    <id>, -6(%r11)
>     je      .Ltmp1
>     ud2
>   .Ltmp1:
>     call    __x86_indirect_thunk_r11

The first one I try and find looks like:

26:       41 81 7b fa a6 96 9e 38         cmpl   $0x389e96a6,-0x6(%r11)
2e:       74 02                   je     32 <__traceiter_sched_kthread_stop+0x29>
30:       0f 0b                   ud2
32:       4c 89 f6                mov    %r14,%rsi
35:       e8 00 00 00 00          call   3a <__traceiter_sched_kthread_stop+0x31> 36: R_X86_64_PLT32      __x86_indirect_thunk_r11-0x4

This must not be. If I'm to rewrite that lot to:

  movl	$\hash, %r10d
  sub	$9, %r11
  call	*%r11
  .nop  4

Then there must not be spurious instruction in between the ud2 and the
indirect call/retpoline thing.

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
  2022-05-16  9:54     ` Peter Zijlstra
@ 2022-05-16 11:45       ` Peter Zijlstra
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Zijlstra @ 2022-05-16 11:45 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Kees Cook, Josh Poimboeuf, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Mon, May 16, 2022 at 11:54:33AM +0200, Peter Zijlstra wrote:
> On Fri, May 13, 2022 at 01:21:58PM -0700, Sami Tolvanen wrote:
> > With CONFIG_CFI_CLANG, the compiler injects a type preamble
> > immediately before each function and a check to validate the target
> > function type before indirect calls:
> > 
> >   ; type preamble
> >   __cfi_function:
> >     int3
> >     int3
> >     mov <id>, %eax
> >     int3
> >     int3
> >   function:
> >     ...
> 
> When I enable CFI_CLANG and X86_KERNEL_IBT I get:
> 
> 0000000000000c80 <__cfi_io_schedule_timeout>:
> c80:   cc                      int3
> c81:   cc                      int3
> c82:   b8 b5 b1 39 b3          mov    $0xb339b1b5,%eax
> c87:   cc                      int3
> c88:   cc                      int3
> 
> 0000000000000c89 <io_schedule_timeout>:
> c89:   f3 0f 1e fa             endbr64
> 
> 
> That seems unfortunate. Would it be possible to get an additional
> compiler option to suppress the endbr for all symbols that get a __cfi_
> preaamble?
> 
> Also, perhaps s/CFI_CLANG/KERNEL_CFI/ or somesuch, so that GCC might
> also implement this same scheme (in time)?
> 
> >   ; indirect call check
> >     cmpl    <id>, -6(%r11)
> >     je      .Ltmp1
> >     ud2
> >   .Ltmp1:
> >     call    __x86_indirect_thunk_r11
> 
> The first one I try and find looks like:
> 
> 26:       41 81 7b fa a6 96 9e 38         cmpl   $0x389e96a6,-0x6(%r11)
> 2e:       74 02                   je     32 <__traceiter_sched_kthread_stop+0x29>
> 30:       0f 0b                   ud2
> 32:       4c 89 f6                mov    %r14,%rsi
> 35:       e8 00 00 00 00          call   3a <__traceiter_sched_kthread_stop+0x31> 36: R_X86_64_PLT32      __x86_indirect_thunk_r11-0x4
> 
> This must not be. If I'm to rewrite that lot to:
> 
>   movl	$\hash, %r10d
>   sub	$9, %r11
>   call	*%r11
>   .nop  4
> 
> Then there must not be spurious instruction in between the ud2 and the
> indirect call/retpoline thing.

Hmmm.. when I replace it with:

   movl	$\hash, %r10d
   sub	$9, %r11
   .nops 2

That would work, that has the added benefit of nicely co-existing with
the current retpoline patching.

The only remaining problem is how to find this; the .retpoline_sites is
fairly concenient, but if the compiler can put arbitrary amounts of code
in between this is going to be somewhat tedious.


^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
@ 2022-05-16 11:45       ` Peter Zijlstra
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Zijlstra @ 2022-05-16 11:45 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Kees Cook, Josh Poimboeuf, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Mon, May 16, 2022 at 11:54:33AM +0200, Peter Zijlstra wrote:
> On Fri, May 13, 2022 at 01:21:58PM -0700, Sami Tolvanen wrote:
> > With CONFIG_CFI_CLANG, the compiler injects a type preamble
> > immediately before each function and a check to validate the target
> > function type before indirect calls:
> > 
> >   ; type preamble
> >   __cfi_function:
> >     int3
> >     int3
> >     mov <id>, %eax
> >     int3
> >     int3
> >   function:
> >     ...
> 
> When I enable CFI_CLANG and X86_KERNEL_IBT I get:
> 
> 0000000000000c80 <__cfi_io_schedule_timeout>:
> c80:   cc                      int3
> c81:   cc                      int3
> c82:   b8 b5 b1 39 b3          mov    $0xb339b1b5,%eax
> c87:   cc                      int3
> c88:   cc                      int3
> 
> 0000000000000c89 <io_schedule_timeout>:
> c89:   f3 0f 1e fa             endbr64
> 
> 
> That seems unfortunate. Would it be possible to get an additional
> compiler option to suppress the endbr for all symbols that get a __cfi_
> preaamble?
> 
> Also, perhaps s/CFI_CLANG/KERNEL_CFI/ or somesuch, so that GCC might
> also implement this same scheme (in time)?
> 
> >   ; indirect call check
> >     cmpl    <id>, -6(%r11)
> >     je      .Ltmp1
> >     ud2
> >   .Ltmp1:
> >     call    __x86_indirect_thunk_r11
> 
> The first one I try and find looks like:
> 
> 26:       41 81 7b fa a6 96 9e 38         cmpl   $0x389e96a6,-0x6(%r11)
> 2e:       74 02                   je     32 <__traceiter_sched_kthread_stop+0x29>
> 30:       0f 0b                   ud2
> 32:       4c 89 f6                mov    %r14,%rsi
> 35:       e8 00 00 00 00          call   3a <__traceiter_sched_kthread_stop+0x31> 36: R_X86_64_PLT32      __x86_indirect_thunk_r11-0x4
> 
> This must not be. If I'm to rewrite that lot to:
> 
>   movl	$\hash, %r10d
>   sub	$9, %r11
>   call	*%r11
>   .nop  4
> 
> Then there must not be spurious instruction in between the ud2 and the
> indirect call/retpoline thing.

Hmmm.. when I replace it with:

   movl	$\hash, %r10d
   sub	$9, %r11
   .nops 2

That would work, that has the added benefit of nicely co-existing with
the current retpoline patching.

The only remaining problem is how to find this; the .retpoline_sites is
fairly concenient, but if the compiler can put arbitrary amounts of code
in between this is going to be somewhat tedious.


_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 07/21] cfi: Add type helper macros
  2022-05-14 21:49     ` Kees Cook
@ 2022-05-16 12:28       ` Rasmus Villemoes
  -1 siblings, 0 replies; 174+ messages in thread
From: Rasmus Villemoes @ 2022-05-16 12:28 UTC (permalink / raw)
  To: Kees Cook, Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On 14/05/2022 23.49, Kees Cook wrote:
> On Fri, May 13, 2022 at 01:21:45PM -0700, Sami Tolvanen wrote:
>> With CONFIG_CFI_CLANG, assembly functions called indirectly
>> from C code must be annotated with type identifiers to pass CFI
>> checking. The compiler emits a __kcfi_typeid_<function> symbol for
>> each address-taken function declaration in C, which contains the
>> expected type identifier. Add typed versions of SYM_FUNC_START and
>> SYM_FUNC_START_ALIAS, which emit the type identifier before the
>> function.
>>
>> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> 
> And the reason to not make this change universally (i.e. directly in
> SYM_FUNC_START) is to minimize how many of these symbol annotations get
> emitted? (And to more directly indicate which asm is called indirectly?)
> 
> What happens if an asm function is called indirectly and it doesn't have
> this annotation? 

Presumably that's a fail.

I'm also interested in how this works at the asm/linker level. I assume
that the .o file generated from the asm input has
__kcfi_typeid_<function> as an undefined symbol; the compiler emits that
symbol as an absolute one upon taking the address of <function>, and the
linker then has the info it needs to patch things up.

But what then happens if we have some function implemented in assembly
which for whatever .config reason never has its address taken in any .c
translation unit that gets linked in? Does the __kcfi_typeid_<function>
symbol silently resolve to 0, or does the link fail?

I can't really imagine the compiler emitting __kcfi_typeid_<function>
symbols for each and every function it sees merely declared in some header.

Two different .c files both taking the address of <function> should of
course emit the same value for __kcfi_typeid_<function>. Is there any
sanity check anywhere that that's actually the case?

Can we please have some objdump/readelf output from some .o files
involved here?

Rasmus

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 07/21] cfi: Add type helper macros
@ 2022-05-16 12:28       ` Rasmus Villemoes
  0 siblings, 0 replies; 174+ messages in thread
From: Rasmus Villemoes @ 2022-05-16 12:28 UTC (permalink / raw)
  To: Kees Cook, Sami Tolvanen
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On 14/05/2022 23.49, Kees Cook wrote:
> On Fri, May 13, 2022 at 01:21:45PM -0700, Sami Tolvanen wrote:
>> With CONFIG_CFI_CLANG, assembly functions called indirectly
>> from C code must be annotated with type identifiers to pass CFI
>> checking. The compiler emits a __kcfi_typeid_<function> symbol for
>> each address-taken function declaration in C, which contains the
>> expected type identifier. Add typed versions of SYM_FUNC_START and
>> SYM_FUNC_START_ALIAS, which emit the type identifier before the
>> function.
>>
>> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> 
> And the reason to not make this change universally (i.e. directly in
> SYM_FUNC_START) is to minimize how many of these symbol annotations get
> emitted? (And to more directly indicate which asm is called indirectly?)
> 
> What happens if an asm function is called indirectly and it doesn't have
> this annotation? 

Presumably that's a fail.

I'm also interested in how this works at the asm/linker level. I assume
that the .o file generated from the asm input has
__kcfi_typeid_<function> as an undefined symbol; the compiler emits that
symbol as an absolute one upon taking the address of <function>, and the
linker then has the info it needs to patch things up.

But what then happens if we have some function implemented in assembly
which for whatever .config reason never has its address taken in any .c
translation unit that gets linked in? Does the __kcfi_typeid_<function>
symbol silently resolve to 0, or does the link fail?

I can't really imagine the compiler emitting __kcfi_typeid_<function>
symbols for each and every function it sees merely declared in some header.

Two different .c files both taking the address of <function> should of
course emit the same value for __kcfi_typeid_<function>. Is there any
sanity check anywhere that that's actually the case?

Can we please have some objdump/readelf output from some .o files
involved here?

Rasmus

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
  2022-05-16 11:45       ` Peter Zijlstra
@ 2022-05-16 12:58         ` Peter Zijlstra
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Zijlstra @ 2022-05-16 12:58 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Kees Cook, Josh Poimboeuf, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, willy

On Mon, May 16, 2022 at 01:45:17PM +0200, Peter Zijlstra wrote:
> On Mon, May 16, 2022 at 11:54:33AM +0200, Peter Zijlstra wrote:
> > On Fri, May 13, 2022 at 01:21:58PM -0700, Sami Tolvanen wrote:

> > >   ; indirect call check
> > >     cmpl    <id>, -6(%r11)
> > >     je      .Ltmp1
> > >     ud2
> > >   .Ltmp1:
> > >     call    __x86_indirect_thunk_r11
> > 
> > The first one I try and find looks like:
> > 
> > 26:       41 81 7b fa a6 96 9e 38         cmpl   $0x389e96a6,-0x6(%r11)
> > 2e:       74 02                   je     32 <__traceiter_sched_kthread_stop+0x29>
> > 30:       0f 0b                   ud2
> > 32:       4c 89 f6                mov    %r14,%rsi
> > 35:       e8 00 00 00 00          call   3a <__traceiter_sched_kthread_stop+0x31> 36: R_X86_64_PLT32      __x86_indirect_thunk_r11-0x4
> > 
> > This must not be. If I'm to rewrite that lot to:
> > 
> >   movl	$\hash, %r10d
> >   sub	$9, %r11
> >   call	*%r11
> >   .nop  4
> > 
> > Then there must not be spurious instruction in between the ud2 and the
> > indirect call/retpoline thing.
> 
> Hmmm.. when I replace it with:
> 
>    movl	$\hash, %r10d
>    sub	$9, %r11
>    .nops 2
> 
> That would work, that has the added benefit of nicely co-existing with
> the current retpoline patching.
> 
> The only remaining problem is how to find this; the .retpoline_sites is
> fairly concenient, but if the compiler can put arbitrary amounts of code
> in between this is going to be somewhat tedious.
> 

Something like the *completely* untested below. It compiles, but because
the above code-gen issue it *cannot* work.

(also, it lacks module support)

@willy, how horribly broken is this xarray usage?

---
 arch/x86/include/asm/traps.h            |   1 +
 arch/x86/kernel/alternative.c           | 316 ++++++++++++++++++++++++++++++++
 arch/x86/kernel/cpu/common.c            |   5 +
 arch/x86/kernel/vmlinux.lds.S           |   9 +
 tools/objtool/check.c                   |  67 ++++++-
 tools/objtool/include/objtool/objtool.h |   1 +
 tools/objtool/objtool.c                 |   1 +
 7 files changed, 399 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/traps.h b/arch/x86/include/asm/traps.h
index 35317c5c551d..a423343cffbc 100644
--- a/arch/x86/include/asm/traps.h
+++ b/arch/x86/include/asm/traps.h
@@ -19,6 +19,7 @@ asmlinkage __visible noinstr struct pt_regs *vc_switch_off_ist(struct pt_regs *e
 #endif
 
 extern bool ibt_selftest(void);
+extern bool ibt_broken;
 
 #ifdef CONFIG_X86_F00F_BUG
 /* For handling the FOOF bug */
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index d374cb3cf024..abce4e78a1e0 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -18,6 +18,9 @@
 #include <linux/mmu_context.h>
 #include <linux/bsearch.h>
 #include <linux/sync_core.h>
+#include <linux/moduleloader.h>
+#include <linux/xarray.h>
+#include <linux/set_memory.h>
 #include <asm/text-patching.h>
 #include <asm/alternative.h>
 #include <asm/sections.h>
@@ -115,6 +118,7 @@ static void __init_or_module add_nops(void *insns, unsigned int len)
 }
 
 extern s32 __retpoline_sites[], __retpoline_sites_end[];
+extern s32 __cfi_sites[], __cfi_sites_end[];
 extern s32 __ibt_endbr_seal[], __ibt_endbr_seal_end[];
 extern struct alt_instr __alt_instructions[], __alt_instructions_end[];
 extern s32 __smp_locks[], __smp_locks_end[];
@@ -549,6 +553,315 @@ void __init_or_module noinline apply_ibt_endbr(s32 *start, s32 *end) { }
 
 #endif /* CONFIG_X86_KERNEL_IBT */
 
+#ifdef CONFIG_CFI_CLANG
+/*
+ *  FineIBT                                         kCFI
+ *
+ *  __fineibt_\hash:
+ *    xor     \hash, %r10     # 7
+ *    jz      1f              # 2
+ *    ud2                     # 2
+ *  1:ret                     # 1
+ *    int3                    # 1
+ *
+ *
+ *  __cfi_\sym:                                     __cfi_\sym:
+ *                                                    int3; int3                              # 2
+ *    endbr                   # 4                     mov     \hash, %eax                     # 5
+ *    call    __fineibt_\hash # 5                     int3; int3                              # 2
+ *  \sym:                                           \sym:
+ *  ...                                             ...
+ *
+ *
+ *  caller:                                         caller:
+ *    movl    \hash, %r10d    # 6                     cmpl    \hash, -6(%r11)                 # 8
+ *    sub     $9, %r11        # 4                     je      1f                              # 2
+ *    nop2                    # 2                     ud2                                     # 2
+ *
+ *    call    *%r11           # 3                     call    __x86_indirect_thunk_r11        # 5
+ *    nop2                    # 2
+ */
+
+static DEFINE_XARRAY(cfi_hashes);
+static int nr_cfi_hashes;
+
+static u32 decode_cfi_preamble(void *addr)
+{
+	u8 *p = addr;
+
+	if (p[0] == 0xcc && p[1] == 0xcc &&
+	    p[2] == 0xb8 &&
+	    p[7] == 0xcc && p[8] == 0xcc)
+		return *(u32 *)(addr + 3);
+
+	return 0; /* invalid hash value */
+}
+
+static u32 decode_cfi_caller(void *addr)
+{
+	u8 *p = addr;
+
+	if (((p[0] == 0x41 && p[1] == 0x81) ||
+	     (p[0] == 0xeb && p[1] == 0x0a)) && p[2] == 0x7b &&
+	    p[8] == 0x74 && p[9] == 0x02 &&
+	    p[10] == 0x0f && p[11] == 0x0b)
+		return *(u32 *)(addr + 4);
+
+	return 0; /* invalid hash value */
+}
+
+// .cfi_sites
+static int cfi_index_hashes(s32 *start, s32 *end)
+{
+	s32 *s;
+
+	for (s = start; s < end; s++) {
+		void *addr = (void *)s + *s;
+		void *xa;
+		u32 hash;
+
+		hash = decode_cfi_preamble(addr);
+		if (!hash) {
+			//WARN();
+			return -EINVAL;
+		}
+
+		xa = xa_store(&cfi_hashes, hash, NULL, GFP_KERNEL);
+		if (xa_is_err(xa)) {
+			//WARN();
+			return xa_err(xa);
+		}
+		nr_cfi_hashes++;
+	}
+
+	return 0;
+}
+
+asm (	".pushsection .rodata\n"
+	"fineibt_template_start:\n"
+	"	xorl	$0x12345678, %r10d\n"	// 7
+	"	je	1f\n"			// 2
+	"	ud2\n"				// 2
+	"1:	ret\n"				// 1
+	"	int3\n"
+	"	int3\n"
+	"	int3\n"
+	"	int3\n"				// 4
+	"fineibt_template_end:\n"
+	".popsection\n"
+    );
+
+extern u8 fineibt_template_start[];
+extern u8 fineibt_template_end[];
+
+static int cfi_create_fineibt_stubs(void)
+{
+	size_t size = 16 * nr_cfi_hashes;
+	int pages = 1 + ((size - 1) >> PAGE_SHIFT);
+	void *text, *entry, *xa;
+	unsigned long hash;
+	int err = -ENOMEM;
+
+	text = module_alloc(size);
+	if (!text)
+		return err;
+
+	entry = text;
+	xa_for_each(&cfi_hashes, hash, xa) {
+
+		memcpy(entry, fineibt_template_start, 16);
+		*(u32 *)(entry + 3) = hash;
+
+		xa = xa_store(&cfi_hashes, hash, entry, GFP_KERNEL);
+		if (xa_is_err(xa)) {
+			err = xa_err(xa);
+			goto err_alloc;
+		}
+		if (xa) {
+			err = -EINVAL;
+			goto err_alloc;
+		}
+
+		entry += 16;
+	}
+
+	set_memory_ro((unsigned long)text, pages);
+	set_memory_x((unsigned long)text, pages);
+
+	return 0;
+
+err_alloc:
+	module_memfree(text);
+	return -EINVAL;
+}
+
+// .retpoline_sites
+static int cfi_disable_callers(s32 *start, s32 *end)
+{
+	/*
+	 * Disable CFI by patching in a 2 byte JMP, this leaves the hash in
+	 * tact for later usage. Also see decode_cfi_caller() and
+	 * cfu_rewrite_callers().
+	 */
+	const u8 jmp12[] = { 0xeb, 0x0a };
+	s32 *s;
+
+	for (s = start; s < end; s++) {
+		void *addr = (void *)s + *s;
+		u32 hash;
+
+		hash = decode_cfi_caller(addr - 12);
+		if (!hash) {
+			// WARN();
+			return -EINVAL;
+		}
+
+		text_poke_early(addr - 12, jmp12, 2);
+	}
+
+	return 0;
+}
+
+asm (	".pushsection .rodata\n"
+	"fineibt_cfi_start:\n"
+	"	endbr64\n"
+	"	call fineibt_caller_start\n"
+	"fineibt_cfi_end:"
+	".popsection\n"
+    );
+
+extern u8 fineibt_cfi_start[];
+extern u8 fineibt_cfi_end[];
+
+// .cfi_sites
+static int cfi_rewrite_cfi(s32 *start, s32 *end)
+{
+	s32 *s;
+
+	for (s = start; s < end; s++) {
+		void *dest, *addr = (void *)s + *s;
+		unsigned long index;
+		u32 hash;
+
+		index = hash = decode_cfi_preamble(addr);
+		dest = xa_find(&cfi_hashes, &index, hash, XA_PRESENT);
+
+		if (WARN_ON_ONCE(index != hash || !dest))
+			return -EINVAL;
+
+		text_poke_early(addr, fineibt_cfi_start,
+				(fineibt_cfi_end - fineibt_cfi_start));
+
+		__text_gen_insn(addr + 4,
+				CALL_INSN_OPCODE, addr + 4,
+				dest, CALL_INSN_SIZE);
+	}
+
+	return 0;
+}
+
+asm (	".pushsection .rodata\n"
+	"fineibt_caller_start:\n"
+	"	movl	$0x12345678, %r10d\n"
+	"	sub	$9, %r11\n"
+	"	.nops	2\n"
+	"fineibt_caller_end:"
+	".popsection\n"
+    );
+
+extern u8 fineibt_caller_start[];
+extern u8 fineibt_caller_end[];
+
+// .retpoline_sites
+static int cfi_rewrite_callers(s32 *start, s32 *end)
+{
+	s32 *s;
+
+	for (s = start; s < end; s++) {
+		void *addr = (void *)s + *s;
+		u32 hash;
+
+		hash = decode_cfi_caller(addr - 12);
+
+		if (WARN_ON_ONCE(!hash))
+			return -EINVAL;
+
+		text_poke_early(addr - 12, fineibt_caller_start,
+				(fineibt_caller_end - fineibt_caller_end));
+
+		*(u32 *)(addr - 12 + 2) = hash;
+
+		/* rely on apply_retpolines() to rewrite the actual call */
+	}
+
+	return 0;
+}
+
+bool __ro_after_init ibt_broken = false;
+
+static void apply_fineibt(s32 *start_retpoline, s32 *end_retpoline,
+			  s32 *start_cfi, s32 *end_cfi)
+{
+	int ret;
+
+	/* If IBT, use FineIBT */
+	if (!HAS_KERNEL_IBT || !cpu_feature_enabled(X86_FEATURE_IBT))
+		return;
+
+	/*
+	 * Find and count all unique hash values.
+	 */
+	ret = cfi_index_hashes(start_cfi, end_cfi);
+	if (ret)
+		goto err;
+
+	/*
+	 * Allocate module memory and write FineIBT stubs.
+	 */
+	ret = cfi_create_fineibt_stubs();
+	if (ret)
+		goto err;
+
+	/*
+	 * Rewrite the callers to not use the __cfi_ stubs, such that we might
+	 * rewrite them. Disables all CFI. If this succeeds but any of the
+	 * later stages fails, we're CFI-less.
+	 */
+	ret = cfi_disable_callers(start_retpoline, end_retpoline);
+	if (ret)
+		goto err;
+
+	/*
+	 * Rewrite the __cfi_ stubs from kCFI to FineIBT.
+	 */
+	ret = cfi_rewrite_cfi(start_cfi, end_cfi);
+	if (ret)
+		goto err;
+
+	/*
+	 * Now that everything is in place; rewrite the callers to FineIBT.
+	 */
+	ret = cfi_rewrite_callers(start_retpoline, end_retpoline);
+	if (ret)
+		goto err;
+
+	return;
+
+err:
+	pr_err("Something went horribly wrong trying to rewrite the CFI implementation.\n");
+	/* must *NOT* enable IBT */
+	ibt_broken = true;
+}
+
+#else
+
+static void apply_fineibt(s32 *start_retpoline, s32 *end_retpoline,
+			  s32 *start_cfi, s32 *end_cfi)
+{
+}
+
+#endif
+
 #ifdef CONFIG_SMP
 static void alternatives_smp_lock(const s32 *start, const s32 *end,
 				  u8 *text, u8 *text_end)
@@ -855,6 +1168,9 @@ void __init alternative_instructions(void)
 	 */
 	apply_paravirt(__parainstructions, __parainstructions_end);
 
+	apply_fineibt(__retpoline_sites, __retpoline_sites_end,
+		      __cfi_sites, __cfi_sites_end);
+
 	/*
 	 * Rewrite the retpolines, must be done before alternatives since
 	 * those can rewrite the retpoline thunks.
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index e342ae4db3c4..e4377256b952 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -630,6 +630,11 @@ static __always_inline void setup_cet(struct cpuinfo_x86 *c)
 	    !cpu_feature_enabled(X86_FEATURE_IBT))
 		return;
 
+#ifdef CONFIG_CFI_CLANG
+	if (ibt_broken)
+		return;
+#endif
+
 	wrmsrl(MSR_IA32_S_CET, msr);
 	cr4_set_bits(X86_CR4_CET);
 
diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index 7fda7f27e762..72ffc91ddd20 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -294,6 +294,15 @@ SECTIONS
 	}
 #endif
 
+#if defined(CONFIG_CFI_CLANG) && defined(CONFIG_RETPOLINE) && defined(CONFIG_X86_KERNEL_IBT)
+	. = ALIGN(8);
+	.cfi_sites : AT(ADDR(.cfi_sites) - LOAD_OFFSET) {
+		__cfi_sites = .;
+		*(.cfi_sites)
+		__cfi_sites_end = .;
+	}
+#endif
+
 	/*
 	 * struct alt_inst entries. From the header (alternative.h):
 	 * "Alternative instructions for different CPU types or capabilities"
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 88f005ae6dcc..edc8aecf229c 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -797,6 +797,52 @@ static int create_ibt_endbr_seal_sections(struct objtool_file *file)
 	return 0;
 }
 
+static int create_cfi_sections(struct objtool_file *file)
+{
+	struct instruction *insn;
+	struct section *sec;
+	int idx;
+
+	sec = find_section_by_name(file->elf, ".cfi_sites");
+	if (sec) {
+		WARN("file already has .cfi_sites, skipping");
+		return 0;
+	}
+
+	idx = 0;
+	list_for_each_entry(insn, &file->cfi_list, call_node)
+		idx++;
+
+	if (!idx)
+		return 0;
+
+	sec = elf_create_section(file->elf, ".cfi_sites", 0,
+				 sizeof(int), idx);
+	if (!sec) {
+		WARN("elf_create_section: .cfi_sites");
+		return -1;
+	}
+
+	idx = 0;
+	list_for_each_entry(insn, &file->cfi_list, call_node) {
+
+		int *site = (int *)sec->data->d_buf + idx;
+		*site = 0;
+
+		if (elf_add_reloc_to_insn(file->elf, sec,
+					  idx * sizeof(int),
+					  R_X86_64_PC32,
+					  insn->sec, insn->offset)) {
+			WARN("elf_add_reloc_to_insn: .cfi_sites");
+			return -1;
+		}
+
+		idx++;
+	}
+
+	return 0;
+}
+
 static int create_mcount_loc_sections(struct objtool_file *file)
 {
 	struct section *sec;
@@ -3301,6 +3347,7 @@ static int validate_branch(struct objtool_file *file, struct symbol *func,
 {
 	struct alternative *alt;
 	struct instruction *next_insn, *prev_insn = NULL;
+	struct instruction *first_insn = insn;
 	struct section *sec;
 	u8 visited;
 	int ret;
@@ -3312,8 +3359,19 @@ static int validate_branch(struct objtool_file *file, struct symbol *func,
 
 		if (func && insn->func && func != insn->func->pfunc) {
 			/* Ignore KCFI type preambles, which always fall through */
-			if (!strncmp(func->name, "__cfi_", 6))
+			if (!strncmp(func->name, "__cfi_", 6)) {
+				/*
+				 * If the function has a __cfi_ preamble, the endbr
+				 * will live in there.
+				 */
+				insn->noendbr = true;
+				/*
+				 * The preamble starts with INSN_TRAP,
+				 * call_node cannot be used.
+				 */
+				list_add_tail(&first_insn->call_node, &file->cfi_list);
 				return 0;
+			}
 
 			WARN("%s() falls through to next function %s()",
 			     func->name, insn->func->name);
@@ -3953,6 +4011,13 @@ int check(struct objtool_file *file)
 		warnings += ret;
 	}
 
+	if (ibt && retpoline) {
+		ret = create_cfi_sections(file);
+		if (ret < 0)
+			goto out;
+		warnings += ret;
+	}
+
 	if (stats) {
 		printf("nr_insns_visited: %ld\n", nr_insns_visited);
 		printf("nr_cfi: %ld\n", nr_cfi);
diff --git a/tools/objtool/include/objtool/objtool.h b/tools/objtool/include/objtool/objtool.h
index a6e72d916807..93f52e275fa6 100644
--- a/tools/objtool/include/objtool/objtool.h
+++ b/tools/objtool/include/objtool/objtool.h
@@ -27,6 +27,7 @@ struct objtool_file {
 	struct list_head static_call_list;
 	struct list_head mcount_loc_list;
 	struct list_head endbr_list;
+	struct list_head cfi_list;
 	bool ignore_unreachables, hints, rodata;
 
 	unsigned int nr_endbr;
diff --git a/tools/objtool/objtool.c b/tools/objtool/objtool.c
index 843ff3c2f28e..16ed3613b0e2 100644
--- a/tools/objtool/objtool.c
+++ b/tools/objtool/objtool.c
@@ -129,6 +129,7 @@ struct objtool_file *objtool_open_read(const char *_objname)
 	INIT_LIST_HEAD(&file.static_call_list);
 	INIT_LIST_HEAD(&file.mcount_loc_list);
 	INIT_LIST_HEAD(&file.endbr_list);
+	INIT_LIST_HEAD(&file.cfi_list);
 	file.ignore_unreachables = no_unreachable;
 	file.hints = false;
 

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
@ 2022-05-16 12:58         ` Peter Zijlstra
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Zijlstra @ 2022-05-16 12:58 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Kees Cook, Josh Poimboeuf, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm, willy

On Mon, May 16, 2022 at 01:45:17PM +0200, Peter Zijlstra wrote:
> On Mon, May 16, 2022 at 11:54:33AM +0200, Peter Zijlstra wrote:
> > On Fri, May 13, 2022 at 01:21:58PM -0700, Sami Tolvanen wrote:

> > >   ; indirect call check
> > >     cmpl    <id>, -6(%r11)
> > >     je      .Ltmp1
> > >     ud2
> > >   .Ltmp1:
> > >     call    __x86_indirect_thunk_r11
> > 
> > The first one I try and find looks like:
> > 
> > 26:       41 81 7b fa a6 96 9e 38         cmpl   $0x389e96a6,-0x6(%r11)
> > 2e:       74 02                   je     32 <__traceiter_sched_kthread_stop+0x29>
> > 30:       0f 0b                   ud2
> > 32:       4c 89 f6                mov    %r14,%rsi
> > 35:       e8 00 00 00 00          call   3a <__traceiter_sched_kthread_stop+0x31> 36: R_X86_64_PLT32      __x86_indirect_thunk_r11-0x4
> > 
> > This must not be. If I'm to rewrite that lot to:
> > 
> >   movl	$\hash, %r10d
> >   sub	$9, %r11
> >   call	*%r11
> >   .nop  4
> > 
> > Then there must not be spurious instruction in between the ud2 and the
> > indirect call/retpoline thing.
> 
> Hmmm.. when I replace it with:
> 
>    movl	$\hash, %r10d
>    sub	$9, %r11
>    .nops 2
> 
> That would work, that has the added benefit of nicely co-existing with
> the current retpoline patching.
> 
> The only remaining problem is how to find this; the .retpoline_sites is
> fairly concenient, but if the compiler can put arbitrary amounts of code
> in between this is going to be somewhat tedious.
> 

Something like the *completely* untested below. It compiles, but because
the above code-gen issue it *cannot* work.

(also, it lacks module support)

@willy, how horribly broken is this xarray usage?

---
 arch/x86/include/asm/traps.h            |   1 +
 arch/x86/kernel/alternative.c           | 316 ++++++++++++++++++++++++++++++++
 arch/x86/kernel/cpu/common.c            |   5 +
 arch/x86/kernel/vmlinux.lds.S           |   9 +
 tools/objtool/check.c                   |  67 ++++++-
 tools/objtool/include/objtool/objtool.h |   1 +
 tools/objtool/objtool.c                 |   1 +
 7 files changed, 399 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/traps.h b/arch/x86/include/asm/traps.h
index 35317c5c551d..a423343cffbc 100644
--- a/arch/x86/include/asm/traps.h
+++ b/arch/x86/include/asm/traps.h
@@ -19,6 +19,7 @@ asmlinkage __visible noinstr struct pt_regs *vc_switch_off_ist(struct pt_regs *e
 #endif
 
 extern bool ibt_selftest(void);
+extern bool ibt_broken;
 
 #ifdef CONFIG_X86_F00F_BUG
 /* For handling the FOOF bug */
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index d374cb3cf024..abce4e78a1e0 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -18,6 +18,9 @@
 #include <linux/mmu_context.h>
 #include <linux/bsearch.h>
 #include <linux/sync_core.h>
+#include <linux/moduleloader.h>
+#include <linux/xarray.h>
+#include <linux/set_memory.h>
 #include <asm/text-patching.h>
 #include <asm/alternative.h>
 #include <asm/sections.h>
@@ -115,6 +118,7 @@ static void __init_or_module add_nops(void *insns, unsigned int len)
 }
 
 extern s32 __retpoline_sites[], __retpoline_sites_end[];
+extern s32 __cfi_sites[], __cfi_sites_end[];
 extern s32 __ibt_endbr_seal[], __ibt_endbr_seal_end[];
 extern struct alt_instr __alt_instructions[], __alt_instructions_end[];
 extern s32 __smp_locks[], __smp_locks_end[];
@@ -549,6 +553,315 @@ void __init_or_module noinline apply_ibt_endbr(s32 *start, s32 *end) { }
 
 #endif /* CONFIG_X86_KERNEL_IBT */
 
+#ifdef CONFIG_CFI_CLANG
+/*
+ *  FineIBT                                         kCFI
+ *
+ *  __fineibt_\hash:
+ *    xor     \hash, %r10     # 7
+ *    jz      1f              # 2
+ *    ud2                     # 2
+ *  1:ret                     # 1
+ *    int3                    # 1
+ *
+ *
+ *  __cfi_\sym:                                     __cfi_\sym:
+ *                                                    int3; int3                              # 2
+ *    endbr                   # 4                     mov     \hash, %eax                     # 5
+ *    call    __fineibt_\hash # 5                     int3; int3                              # 2
+ *  \sym:                                           \sym:
+ *  ...                                             ...
+ *
+ *
+ *  caller:                                         caller:
+ *    movl    \hash, %r10d    # 6                     cmpl    \hash, -6(%r11)                 # 8
+ *    sub     $9, %r11        # 4                     je      1f                              # 2
+ *    nop2                    # 2                     ud2                                     # 2
+ *
+ *    call    *%r11           # 3                     call    __x86_indirect_thunk_r11        # 5
+ *    nop2                    # 2
+ */
+
+static DEFINE_XARRAY(cfi_hashes);
+static int nr_cfi_hashes;
+
+static u32 decode_cfi_preamble(void *addr)
+{
+	u8 *p = addr;
+
+	if (p[0] == 0xcc && p[1] == 0xcc &&
+	    p[2] == 0xb8 &&
+	    p[7] == 0xcc && p[8] == 0xcc)
+		return *(u32 *)(addr + 3);
+
+	return 0; /* invalid hash value */
+}
+
+static u32 decode_cfi_caller(void *addr)
+{
+	u8 *p = addr;
+
+	if (((p[0] == 0x41 && p[1] == 0x81) ||
+	     (p[0] == 0xeb && p[1] == 0x0a)) && p[2] == 0x7b &&
+	    p[8] == 0x74 && p[9] == 0x02 &&
+	    p[10] == 0x0f && p[11] == 0x0b)
+		return *(u32 *)(addr + 4);
+
+	return 0; /* invalid hash value */
+}
+
+// .cfi_sites
+static int cfi_index_hashes(s32 *start, s32 *end)
+{
+	s32 *s;
+
+	for (s = start; s < end; s++) {
+		void *addr = (void *)s + *s;
+		void *xa;
+		u32 hash;
+
+		hash = decode_cfi_preamble(addr);
+		if (!hash) {
+			//WARN();
+			return -EINVAL;
+		}
+
+		xa = xa_store(&cfi_hashes, hash, NULL, GFP_KERNEL);
+		if (xa_is_err(xa)) {
+			//WARN();
+			return xa_err(xa);
+		}
+		nr_cfi_hashes++;
+	}
+
+	return 0;
+}
+
+asm (	".pushsection .rodata\n"
+	"fineibt_template_start:\n"
+	"	xorl	$0x12345678, %r10d\n"	// 7
+	"	je	1f\n"			// 2
+	"	ud2\n"				// 2
+	"1:	ret\n"				// 1
+	"	int3\n"
+	"	int3\n"
+	"	int3\n"
+	"	int3\n"				// 4
+	"fineibt_template_end:\n"
+	".popsection\n"
+    );
+
+extern u8 fineibt_template_start[];
+extern u8 fineibt_template_end[];
+
+static int cfi_create_fineibt_stubs(void)
+{
+	size_t size = 16 * nr_cfi_hashes;
+	int pages = 1 + ((size - 1) >> PAGE_SHIFT);
+	void *text, *entry, *xa;
+	unsigned long hash;
+	int err = -ENOMEM;
+
+	text = module_alloc(size);
+	if (!text)
+		return err;
+
+	entry = text;
+	xa_for_each(&cfi_hashes, hash, xa) {
+
+		memcpy(entry, fineibt_template_start, 16);
+		*(u32 *)(entry + 3) = hash;
+
+		xa = xa_store(&cfi_hashes, hash, entry, GFP_KERNEL);
+		if (xa_is_err(xa)) {
+			err = xa_err(xa);
+			goto err_alloc;
+		}
+		if (xa) {
+			err = -EINVAL;
+			goto err_alloc;
+		}
+
+		entry += 16;
+	}
+
+	set_memory_ro((unsigned long)text, pages);
+	set_memory_x((unsigned long)text, pages);
+
+	return 0;
+
+err_alloc:
+	module_memfree(text);
+	return -EINVAL;
+}
+
+// .retpoline_sites
+static int cfi_disable_callers(s32 *start, s32 *end)
+{
+	/*
+	 * Disable CFI by patching in a 2 byte JMP, this leaves the hash in
+	 * tact for later usage. Also see decode_cfi_caller() and
+	 * cfu_rewrite_callers().
+	 */
+	const u8 jmp12[] = { 0xeb, 0x0a };
+	s32 *s;
+
+	for (s = start; s < end; s++) {
+		void *addr = (void *)s + *s;
+		u32 hash;
+
+		hash = decode_cfi_caller(addr - 12);
+		if (!hash) {
+			// WARN();
+			return -EINVAL;
+		}
+
+		text_poke_early(addr - 12, jmp12, 2);
+	}
+
+	return 0;
+}
+
+asm (	".pushsection .rodata\n"
+	"fineibt_cfi_start:\n"
+	"	endbr64\n"
+	"	call fineibt_caller_start\n"
+	"fineibt_cfi_end:"
+	".popsection\n"
+    );
+
+extern u8 fineibt_cfi_start[];
+extern u8 fineibt_cfi_end[];
+
+// .cfi_sites
+static int cfi_rewrite_cfi(s32 *start, s32 *end)
+{
+	s32 *s;
+
+	for (s = start; s < end; s++) {
+		void *dest, *addr = (void *)s + *s;
+		unsigned long index;
+		u32 hash;
+
+		index = hash = decode_cfi_preamble(addr);
+		dest = xa_find(&cfi_hashes, &index, hash, XA_PRESENT);
+
+		if (WARN_ON_ONCE(index != hash || !dest))
+			return -EINVAL;
+
+		text_poke_early(addr, fineibt_cfi_start,
+				(fineibt_cfi_end - fineibt_cfi_start));
+
+		__text_gen_insn(addr + 4,
+				CALL_INSN_OPCODE, addr + 4,
+				dest, CALL_INSN_SIZE);
+	}
+
+	return 0;
+}
+
+asm (	".pushsection .rodata\n"
+	"fineibt_caller_start:\n"
+	"	movl	$0x12345678, %r10d\n"
+	"	sub	$9, %r11\n"
+	"	.nops	2\n"
+	"fineibt_caller_end:"
+	".popsection\n"
+    );
+
+extern u8 fineibt_caller_start[];
+extern u8 fineibt_caller_end[];
+
+// .retpoline_sites
+static int cfi_rewrite_callers(s32 *start, s32 *end)
+{
+	s32 *s;
+
+	for (s = start; s < end; s++) {
+		void *addr = (void *)s + *s;
+		u32 hash;
+
+		hash = decode_cfi_caller(addr - 12);
+
+		if (WARN_ON_ONCE(!hash))
+			return -EINVAL;
+
+		text_poke_early(addr - 12, fineibt_caller_start,
+				(fineibt_caller_end - fineibt_caller_end));
+
+		*(u32 *)(addr - 12 + 2) = hash;
+
+		/* rely on apply_retpolines() to rewrite the actual call */
+	}
+
+	return 0;
+}
+
+bool __ro_after_init ibt_broken = false;
+
+static void apply_fineibt(s32 *start_retpoline, s32 *end_retpoline,
+			  s32 *start_cfi, s32 *end_cfi)
+{
+	int ret;
+
+	/* If IBT, use FineIBT */
+	if (!HAS_KERNEL_IBT || !cpu_feature_enabled(X86_FEATURE_IBT))
+		return;
+
+	/*
+	 * Find and count all unique hash values.
+	 */
+	ret = cfi_index_hashes(start_cfi, end_cfi);
+	if (ret)
+		goto err;
+
+	/*
+	 * Allocate module memory and write FineIBT stubs.
+	 */
+	ret = cfi_create_fineibt_stubs();
+	if (ret)
+		goto err;
+
+	/*
+	 * Rewrite the callers to not use the __cfi_ stubs, such that we might
+	 * rewrite them. Disables all CFI. If this succeeds but any of the
+	 * later stages fails, we're CFI-less.
+	 */
+	ret = cfi_disable_callers(start_retpoline, end_retpoline);
+	if (ret)
+		goto err;
+
+	/*
+	 * Rewrite the __cfi_ stubs from kCFI to FineIBT.
+	 */
+	ret = cfi_rewrite_cfi(start_cfi, end_cfi);
+	if (ret)
+		goto err;
+
+	/*
+	 * Now that everything is in place; rewrite the callers to FineIBT.
+	 */
+	ret = cfi_rewrite_callers(start_retpoline, end_retpoline);
+	if (ret)
+		goto err;
+
+	return;
+
+err:
+	pr_err("Something went horribly wrong trying to rewrite the CFI implementation.\n");
+	/* must *NOT* enable IBT */
+	ibt_broken = true;
+}
+
+#else
+
+static void apply_fineibt(s32 *start_retpoline, s32 *end_retpoline,
+			  s32 *start_cfi, s32 *end_cfi)
+{
+}
+
+#endif
+
 #ifdef CONFIG_SMP
 static void alternatives_smp_lock(const s32 *start, const s32 *end,
 				  u8 *text, u8 *text_end)
@@ -855,6 +1168,9 @@ void __init alternative_instructions(void)
 	 */
 	apply_paravirt(__parainstructions, __parainstructions_end);
 
+	apply_fineibt(__retpoline_sites, __retpoline_sites_end,
+		      __cfi_sites, __cfi_sites_end);
+
 	/*
 	 * Rewrite the retpolines, must be done before alternatives since
 	 * those can rewrite the retpoline thunks.
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index e342ae4db3c4..e4377256b952 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -630,6 +630,11 @@ static __always_inline void setup_cet(struct cpuinfo_x86 *c)
 	    !cpu_feature_enabled(X86_FEATURE_IBT))
 		return;
 
+#ifdef CONFIG_CFI_CLANG
+	if (ibt_broken)
+		return;
+#endif
+
 	wrmsrl(MSR_IA32_S_CET, msr);
 	cr4_set_bits(X86_CR4_CET);
 
diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index 7fda7f27e762..72ffc91ddd20 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -294,6 +294,15 @@ SECTIONS
 	}
 #endif
 
+#if defined(CONFIG_CFI_CLANG) && defined(CONFIG_RETPOLINE) && defined(CONFIG_X86_KERNEL_IBT)
+	. = ALIGN(8);
+	.cfi_sites : AT(ADDR(.cfi_sites) - LOAD_OFFSET) {
+		__cfi_sites = .;
+		*(.cfi_sites)
+		__cfi_sites_end = .;
+	}
+#endif
+
 	/*
 	 * struct alt_inst entries. From the header (alternative.h):
 	 * "Alternative instructions for different CPU types or capabilities"
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 88f005ae6dcc..edc8aecf229c 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -797,6 +797,52 @@ static int create_ibt_endbr_seal_sections(struct objtool_file *file)
 	return 0;
 }
 
+static int create_cfi_sections(struct objtool_file *file)
+{
+	struct instruction *insn;
+	struct section *sec;
+	int idx;
+
+	sec = find_section_by_name(file->elf, ".cfi_sites");
+	if (sec) {
+		WARN("file already has .cfi_sites, skipping");
+		return 0;
+	}
+
+	idx = 0;
+	list_for_each_entry(insn, &file->cfi_list, call_node)
+		idx++;
+
+	if (!idx)
+		return 0;
+
+	sec = elf_create_section(file->elf, ".cfi_sites", 0,
+				 sizeof(int), idx);
+	if (!sec) {
+		WARN("elf_create_section: .cfi_sites");
+		return -1;
+	}
+
+	idx = 0;
+	list_for_each_entry(insn, &file->cfi_list, call_node) {
+
+		int *site = (int *)sec->data->d_buf + idx;
+		*site = 0;
+
+		if (elf_add_reloc_to_insn(file->elf, sec,
+					  idx * sizeof(int),
+					  R_X86_64_PC32,
+					  insn->sec, insn->offset)) {
+			WARN("elf_add_reloc_to_insn: .cfi_sites");
+			return -1;
+		}
+
+		idx++;
+	}
+
+	return 0;
+}
+
 static int create_mcount_loc_sections(struct objtool_file *file)
 {
 	struct section *sec;
@@ -3301,6 +3347,7 @@ static int validate_branch(struct objtool_file *file, struct symbol *func,
 {
 	struct alternative *alt;
 	struct instruction *next_insn, *prev_insn = NULL;
+	struct instruction *first_insn = insn;
 	struct section *sec;
 	u8 visited;
 	int ret;
@@ -3312,8 +3359,19 @@ static int validate_branch(struct objtool_file *file, struct symbol *func,
 
 		if (func && insn->func && func != insn->func->pfunc) {
 			/* Ignore KCFI type preambles, which always fall through */
-			if (!strncmp(func->name, "__cfi_", 6))
+			if (!strncmp(func->name, "__cfi_", 6)) {
+				/*
+				 * If the function has a __cfi_ preamble, the endbr
+				 * will live in there.
+				 */
+				insn->noendbr = true;
+				/*
+				 * The preamble starts with INSN_TRAP,
+				 * call_node cannot be used.
+				 */
+				list_add_tail(&first_insn->call_node, &file->cfi_list);
 				return 0;
+			}
 
 			WARN("%s() falls through to next function %s()",
 			     func->name, insn->func->name);
@@ -3953,6 +4011,13 @@ int check(struct objtool_file *file)
 		warnings += ret;
 	}
 
+	if (ibt && retpoline) {
+		ret = create_cfi_sections(file);
+		if (ret < 0)
+			goto out;
+		warnings += ret;
+	}
+
 	if (stats) {
 		printf("nr_insns_visited: %ld\n", nr_insns_visited);
 		printf("nr_cfi: %ld\n", nr_cfi);
diff --git a/tools/objtool/include/objtool/objtool.h b/tools/objtool/include/objtool/objtool.h
index a6e72d916807..93f52e275fa6 100644
--- a/tools/objtool/include/objtool/objtool.h
+++ b/tools/objtool/include/objtool/objtool.h
@@ -27,6 +27,7 @@ struct objtool_file {
 	struct list_head static_call_list;
 	struct list_head mcount_loc_list;
 	struct list_head endbr_list;
+	struct list_head cfi_list;
 	bool ignore_unreachables, hints, rodata;
 
 	unsigned int nr_endbr;
diff --git a/tools/objtool/objtool.c b/tools/objtool/objtool.c
index 843ff3c2f28e..16ed3613b0e2 100644
--- a/tools/objtool/objtool.c
+++ b/tools/objtool/objtool.c
@@ -129,6 +129,7 @@ struct objtool_file *objtool_open_read(const char *_objname)
 	INIT_LIST_HEAD(&file.static_call_list);
 	INIT_LIST_HEAD(&file.mcount_loc_list);
 	INIT_LIST_HEAD(&file.endbr_list);
+	INIT_LIST_HEAD(&file.cfi_list);
 	file.ignore_unreachables = no_unreachable;
 	file.hints = false;
 

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 01/21] efi/libstub: Filter out CC_FLAGS_CFI
  2022-05-14 21:42     ` Kees Cook
@ 2022-05-16 15:44       ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-16 15:44 UTC (permalink / raw)
  To: Kees Cook
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Sat, May 14, 2022 at 2:42 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, May 13, 2022 at 01:21:39PM -0700, Sami Tolvanen wrote:
> > Explicitly filter out CC_FLAGS_CFI in preparation for the flags being
> > removed from CC_FLAGS_LTO.
> >
> > Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
>
> Is it worth merging all the "existing" CC_FLAGS_LTO/CFI splits into a
> single patch? Either way:

Sure, I can merge them in the next version.

Sami

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 01/21] efi/libstub: Filter out CC_FLAGS_CFI
@ 2022-05-16 15:44       ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-16 15:44 UTC (permalink / raw)
  To: Kees Cook
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Sat, May 14, 2022 at 2:42 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, May 13, 2022 at 01:21:39PM -0700, Sami Tolvanen wrote:
> > Explicitly filter out CC_FLAGS_CFI in preparation for the flags being
> > removed from CC_FLAGS_LTO.
> >
> > Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
>
> Is it worth merging all the "existing" CC_FLAGS_LTO/CFI splits into a
> single patch? Either way:

Sure, I can merge them in the next version.

Sami

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 08/21] psci: Fix the function type for psci_initcall_t
  2022-05-14 21:50     ` Kees Cook
@ 2022-05-16 15:44       ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-16 15:44 UTC (permalink / raw)
  To: Kees Cook
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Sat, May 14, 2022 at 2:50 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, May 13, 2022 at 01:21:46PM -0700, Sami Tolvanen wrote:
> > Functions called through a psci_initcall_t pointer all have
> > non-const arguments. Fix the type definition to avoid tripping
> > indirect call checks with CFI_CLANG.
> >
> > Reported-by: Mark Rutland <mark.rutland@arm.com>
> > Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
>
> This could land separately from this series, too, yes?

Correct.

Sami

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 08/21] psci: Fix the function type for psci_initcall_t
@ 2022-05-16 15:44       ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-16 15:44 UTC (permalink / raw)
  To: Kees Cook
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Sat, May 14, 2022 at 2:50 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, May 13, 2022 at 01:21:46PM -0700, Sami Tolvanen wrote:
> > Functions called through a psci_initcall_t pointer all have
> > non-const arguments. Fix the type definition to avoid tripping
> > indirect call checks with CFI_CLANG.
> >
> > Reported-by: Mark Rutland <mark.rutland@arm.com>
> > Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
>
> This could land separately from this series, too, yes?

Correct.

Sami

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 07/21] cfi: Add type helper macros
  2022-05-14 21:49     ` Kees Cook
@ 2022-05-16 16:04       ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-16 16:04 UTC (permalink / raw)
  To: Kees Cook
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Sat, May 14, 2022 at 2:49 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, May 13, 2022 at 01:21:45PM -0700, Sami Tolvanen wrote:
> > With CONFIG_CFI_CLANG, assembly functions called indirectly
> > from C code must be annotated with type identifiers to pass CFI
> > checking. The compiler emits a __kcfi_typeid_<function> symbol for
> > each address-taken function declaration in C, which contains the
> > expected type identifier. Add typed versions of SYM_FUNC_START and
> > SYM_FUNC_START_ALIAS, which emit the type identifier before the
> > function.
> >
> > Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
>
> And the reason to not make this change universally (i.e. directly in
> SYM_FUNC_START) is to minimize how many of these symbol annotations get
> emitted? (And to more directly indicate which asm is called indirectly?)

The reason not to add this to SYM_FUNC_START is that the compiler
doesn't emit the type symbols for all functions. It currently emits
them for all address-taken function declarations in each translation
unit. We could potentially further limit this by emitting them only
for function declarations with a specific attribute, for example, but
that's something we can optimize later.

> What happens if an asm function is called indirectly and it doesn't have
> this annotation?

It will fail the CFI check.

> (Is this case detectable at compile-time?)

It's not. I'll update the commit message in the next version to
clarify these points.

Sami

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 07/21] cfi: Add type helper macros
@ 2022-05-16 16:04       ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-16 16:04 UTC (permalink / raw)
  To: Kees Cook
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Sat, May 14, 2022 at 2:49 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, May 13, 2022 at 01:21:45PM -0700, Sami Tolvanen wrote:
> > With CONFIG_CFI_CLANG, assembly functions called indirectly
> > from C code must be annotated with type identifiers to pass CFI
> > checking. The compiler emits a __kcfi_typeid_<function> symbol for
> > each address-taken function declaration in C, which contains the
> > expected type identifier. Add typed versions of SYM_FUNC_START and
> > SYM_FUNC_START_ALIAS, which emit the type identifier before the
> > function.
> >
> > Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
>
> And the reason to not make this change universally (i.e. directly in
> SYM_FUNC_START) is to minimize how many of these symbol annotations get
> emitted? (And to more directly indicate which asm is called indirectly?)

The reason not to add this to SYM_FUNC_START is that the compiler
doesn't emit the type symbols for all functions. It currently emits
them for all address-taken function declarations in each translation
unit. We could potentially further limit this by emitting them only
for function declarations with a specific attribute, for example, but
that's something we can optimize later.

> What happens if an asm function is called indirectly and it doesn't have
> this annotation?

It will fail the CFI check.

> (Is this case detectable at compile-time?)

It's not. I'll update the commit message in the next version to
clarify these points.

Sami

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 07/21] cfi: Add type helper macros
  2022-05-16 12:28       ` Rasmus Villemoes
@ 2022-05-16 16:23         ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-16 16:23 UTC (permalink / raw)
  To: Rasmus Villemoes
  Cc: Kees Cook, linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Mon, May 16, 2022 at 5:28 AM Rasmus Villemoes
<linux@rasmusvillemoes.dk> wrote:
>
> On 14/05/2022 23.49, Kees Cook wrote:
> > On Fri, May 13, 2022 at 01:21:45PM -0700, Sami Tolvanen wrote:
> >> With CONFIG_CFI_CLANG, assembly functions called indirectly
> >> from C code must be annotated with type identifiers to pass CFI
> >> checking. The compiler emits a __kcfi_typeid_<function> symbol for
> >> each address-taken function declaration in C, which contains the
> >> expected type identifier. Add typed versions of SYM_FUNC_START and
> >> SYM_FUNC_START_ALIAS, which emit the type identifier before the
> >> function.
> >>
> >> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> >
> > And the reason to not make this change universally (i.e. directly in
> > SYM_FUNC_START) is to minimize how many of these symbol annotations get
> > emitted? (And to more directly indicate which asm is called indirectly?)
> >
> > What happens if an asm function is called indirectly and it doesn't have
> > this annotation?
>
> Presumably that's a fail.
>
> I'm also interested in how this works at the asm/linker level. I assume
> that the .o file generated from the asm input has
> __kcfi_typeid_<function> as an undefined symbol; the compiler emits that
> symbol as an absolute one upon taking the address of <function>, and the
> linker then has the info it needs to patch things up.

Correct. The generated code looks like this:

00000000000003f7 <__cfi_blowfish_dec_blk>:
     3f7:       cc                      int3
     3f8:       cc                      int3
     3f9:       8b 04 25 00 00 00 00    mov    0x0,%eax
                        3fc: R_X86_64_32S       __kcfi_typeid_blowfish_dec_blk
     400:       cc                      int3
     401:       cc                      int3

0000000000000402 <blowfish_dec_blk>:

And the symbol table in the file that takes the address has this:

    45: ffffffffef478db5     0 NOTYPE  WEAK   DEFAULT  ABS
__kcfi_typeid_blowfish_dec_blk

> But what then happens if we have some function implemented in assembly
> which for whatever .config reason never has its address taken in any .c
> translation unit that gets linked in? Does the __kcfi_typeid_<function>
> symbol silently resolve to 0, or does the link fail?

It will fail to link in that case.

> I can't really imagine the compiler emitting __kcfi_typeid_<function>
> symbols for each and every function it sees merely declared in some header.

The compiler emits these only for address-taken declarations.

> Two different .c files both taking the address of <function> should of
> course emit the same value for __kcfi_typeid_<function>. Is there any
> sanity check anywhere that that's actually the case?

Not at the moment. I suppose we could warn about mismatches in the
linker though.

> Can we please have some objdump/readelf output from some .o files
> involved here?

Sure, I'll add examples to the commit message.

Sami

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 07/21] cfi: Add type helper macros
@ 2022-05-16 16:23         ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-16 16:23 UTC (permalink / raw)
  To: Rasmus Villemoes
  Cc: Kees Cook, linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Mon, May 16, 2022 at 5:28 AM Rasmus Villemoes
<linux@rasmusvillemoes.dk> wrote:
>
> On 14/05/2022 23.49, Kees Cook wrote:
> > On Fri, May 13, 2022 at 01:21:45PM -0700, Sami Tolvanen wrote:
> >> With CONFIG_CFI_CLANG, assembly functions called indirectly
> >> from C code must be annotated with type identifiers to pass CFI
> >> checking. The compiler emits a __kcfi_typeid_<function> symbol for
> >> each address-taken function declaration in C, which contains the
> >> expected type identifier. Add typed versions of SYM_FUNC_START and
> >> SYM_FUNC_START_ALIAS, which emit the type identifier before the
> >> function.
> >>
> >> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> >
> > And the reason to not make this change universally (i.e. directly in
> > SYM_FUNC_START) is to minimize how many of these symbol annotations get
> > emitted? (And to more directly indicate which asm is called indirectly?)
> >
> > What happens if an asm function is called indirectly and it doesn't have
> > this annotation?
>
> Presumably that's a fail.
>
> I'm also interested in how this works at the asm/linker level. I assume
> that the .o file generated from the asm input has
> __kcfi_typeid_<function> as an undefined symbol; the compiler emits that
> symbol as an absolute one upon taking the address of <function>, and the
> linker then has the info it needs to patch things up.

Correct. The generated code looks like this:

00000000000003f7 <__cfi_blowfish_dec_blk>:
     3f7:       cc                      int3
     3f8:       cc                      int3
     3f9:       8b 04 25 00 00 00 00    mov    0x0,%eax
                        3fc: R_X86_64_32S       __kcfi_typeid_blowfish_dec_blk
     400:       cc                      int3
     401:       cc                      int3

0000000000000402 <blowfish_dec_blk>:

And the symbol table in the file that takes the address has this:

    45: ffffffffef478db5     0 NOTYPE  WEAK   DEFAULT  ABS
__kcfi_typeid_blowfish_dec_blk

> But what then happens if we have some function implemented in assembly
> which for whatever .config reason never has its address taken in any .c
> translation unit that gets linked in? Does the __kcfi_typeid_<function>
> symbol silently resolve to 0, or does the link fail?

It will fail to link in that case.

> I can't really imagine the compiler emitting __kcfi_typeid_<function>
> symbols for each and every function it sees merely declared in some header.

The compiler emits these only for address-taken declarations.

> Two different .c files both taking the address of <function> should of
> course emit the same value for __kcfi_typeid_<function>. Is there any
> sanity check anywhere that that's actually the case?

Not at the moment. I suppose we could warn about mismatches in the
linker though.

> Can we please have some objdump/readelf output from some .o files
> involved here?

Sure, I'll add examples to the commit message.

Sami

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 10/21] arm64: Add CFI error handling
  2022-05-14 21:51     ` Kees Cook
@ 2022-05-16 16:24       ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-16 16:24 UTC (permalink / raw)
  To: Kees Cook
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Sat, May 14, 2022 at 2:51 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, May 13, 2022 at 01:21:48PM -0700, Sami Tolvanen wrote:
> > With -fsanitize=kcfi, CFI always traps. Add arm64 support for handling
> > CFI failures. The registers containing the target address and the
> > expected type are encoded in the first ten bits of the ESR as follows:
> >
> >  - 0-4: n, where the register Xn contains the target address
> >  - 5-9: m, where the register Wm contains the type hash
> >
> > Suggested-by: Mark Rutland <mark.rutland@arm.com>
> > Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
>
> It might be nice just to include an example exception Oops in this
> commit log.

Agreed, I'll add an example.

Sami

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 10/21] arm64: Add CFI error handling
@ 2022-05-16 16:24       ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-16 16:24 UTC (permalink / raw)
  To: Kees Cook
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Sat, May 14, 2022 at 2:51 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, May 13, 2022 at 01:21:48PM -0700, Sami Tolvanen wrote:
> > With -fsanitize=kcfi, CFI always traps. Add arm64 support for handling
> > CFI failures. The registers containing the target address and the
> > expected type are encoded in the first ten bits of the ESR as follows:
> >
> >  - 0-4: n, where the register Xn contains the target address
> >  - 5-9: m, where the register Wm contains the type hash
> >
> > Suggested-by: Mark Rutland <mark.rutland@arm.com>
> > Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
>
> It might be nice just to include an example exception Oops in this
> commit log.

Agreed, I'll add an example.

Sami

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 11/21] arm64: Drop unneeded __nocfi attributes
  2022-05-14 21:54     ` Kees Cook
@ 2022-05-16 16:28       ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-16 16:28 UTC (permalink / raw)
  To: Kees Cook
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Sat, May 14, 2022 at 2:54 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, May 13, 2022 at 01:21:49PM -0700, Sami Tolvanen wrote:
> > With -fsanitize=kcfi, CONFIG_CFI_CLANG no longer has issues
> > with address space confusion in functions that switch to linear
> > mapping. Now that the indirectly called assembly functions have
> > type annotations, drop the __nocfi attributes.
> >
> > Suggested-by: Mark Rutland <mark.rutland@arm.com>
> > Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
>
> It looks like there are still other cases that continue to require
> __nocfi, yes? It looks like after this series, it's still BPF?

Yes, BPF is the only remaining user of __nocfi after this series.

Sami

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 11/21] arm64: Drop unneeded __nocfi attributes
@ 2022-05-16 16:28       ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-16 16:28 UTC (permalink / raw)
  To: Kees Cook
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Sat, May 14, 2022 at 2:54 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, May 13, 2022 at 01:21:49PM -0700, Sami Tolvanen wrote:
> > With -fsanitize=kcfi, CONFIG_CFI_CLANG no longer has issues
> > with address space confusion in functions that switch to linear
> > mapping. Now that the indirectly called assembly functions have
> > type annotations, drop the __nocfi attributes.
> >
> > Suggested-by: Mark Rutland <mark.rutland@arm.com>
> > Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
>
> It looks like there are still other cases that continue to require
> __nocfi, yes? It looks like after this series, it's still BPF?

Yes, BPF is the only remaining user of __nocfi after this series.

Sami

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 14/21] treewide: Drop __cficanonical
  2022-05-14 21:56     ` Kees Cook
@ 2022-05-16 16:32       ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-16 16:32 UTC (permalink / raw)
  To: Kees Cook
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Sat, May 14, 2022 at 2:56 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, May 13, 2022 at 01:21:52PM -0700, Sami Tolvanen wrote:
> > CONFIG_CFI_CLANG doesn't use a jump table anymore and therefore,
> > won't change function references to point elsewhere. Remove the
> > __cficanonical attribute and all uses of it.
> >
> > Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> > ---
> >  include/linux/compiler_types.h | 4 ----
> >  include/linux/init.h           | 4 ++--
> >  include/linux/pci.h            | 4 ++--
> >  3 files changed, 4 insertions(+), 8 deletions(-)
>
> I think this is missing removing it from include/linux/compiler-clang.h ?

That was removed in the earlier patch that switched the CFI implementation.

> With that done (or explained why not):

I'll add a note about it to the commit message.

Sami

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 14/21] treewide: Drop __cficanonical
@ 2022-05-16 16:32       ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-16 16:32 UTC (permalink / raw)
  To: Kees Cook
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Sat, May 14, 2022 at 2:56 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, May 13, 2022 at 01:21:52PM -0700, Sami Tolvanen wrote:
> > CONFIG_CFI_CLANG doesn't use a jump table anymore and therefore,
> > won't change function references to point elsewhere. Remove the
> > __cficanonical attribute and all uses of it.
> >
> > Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> > ---
> >  include/linux/compiler_types.h | 4 ----
> >  include/linux/init.h           | 4 ++--
> >  include/linux/pci.h            | 4 ++--
> >  3 files changed, 4 insertions(+), 8 deletions(-)
>
> I think this is missing removing it from include/linux/compiler-clang.h ?

That was removed in the earlier patch that switched the CFI implementation.

> With that done (or explained why not):

I'll add a note about it to the commit message.

Sami

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
  2022-05-16  8:32     ` David Laight
@ 2022-05-16 16:39       ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-16 16:39 UTC (permalink / raw)
  To: David Laight
  Cc: linux-kernel, Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Mon, May 16, 2022 at 1:32 AM David Laight <David.Laight@aculab.com> wrote:
>
> From: Sami Tolvanen
> > Sent: 13 May 2022 21:22
> >
> > With CONFIG_CFI_CLANG, the compiler injects a type preamble
> > immediately before each function and a check to validate the target
> > function type before indirect calls:
> >
> >   ; type preamble
> >   __cfi_function:
> >     int3
> >     int3
> >     mov <id>, %eax
>
> Interesting - since this code can't be executed there is no
> point adding an instruction 'prefix' to the 32bit constant.

The reason to embed the type into an instruction is to avoid the need
to special case objtool's instruction decoder.

> >     int3
> >     int3
> >   function:
> >     ...
> >   ; indirect call check
> >     cmpl    <id>, -6(%r11)
> >     je      .Ltmp1
> >     ud2
> >   .Ltmp1:
> >     call    __x86_indirect_thunk_r11
> >
> > Define the __CFI_TYPE helper macro for manual type annotations in
> > assembly code, add error handling for the CFI ud2 traps, and allow
> > CONFIG_CFI_CLANG to be selected on x86_64.
> >
> ...
> > +
> > +     /*
> > +      * The compiler generates the following instruction sequence
> > +      * for indirect call checks:
> > +      *
> > +      *   cmpl    <id>, -6(%reg)     ; 7 bytes
>
> If the <id> is between -128 and 127 then an 8bit constant
> (sign extended) might be used.
> Possibly the compiler forces the assembler to generate the
> long form.
>
> There could also be a REX prefix.
> That will break any code that tries to use %reg.

The compiler always generates this specific instruction sequence.

> > +      *   je      .Ltmp1             ; 2 bytes
> > +      *   ud2                        ; <- addr
> > +      *   .Ltmp1:
> > +      *
> > +      * Both the type and the target address can be decoded from the
> > +      * cmpl instruction.
> > +      */
> > +     if (copy_from_kernel_nofault(buffer, (void *)regs->ip - 9, MAX_INSN_SIZE))
> > +             return;
> > +     if (insn_decode_kernel(&insn, buffer))
> > +             return;
> > +     if (insn.opcode.value != 0x81 || X86_MODRM_REG(insn.modrm.value) != 7)
> > +             return;
>
> Since you are looking for a very specific opcode why bother
> calling insn_decode_kernel() - just check for the required (masked)
> byte values.

Because I need to decode both the immediate value and the register
from that instruction.

> > +
> > +     *type = insn.immediate.value;
> > +
> > +     offset = insn_get_modrm_rm_off(&insn, regs);
>
> Given the expected instruction, isn't that -6 ??

No, this is the register offset.

> > +     if (offset < 0)
> > +             return;
> > +
> > +     *target = *(unsigned long *)((void *)regs + offset);
>
> WTF is that calculating??

It's reading the register value from pt_regs.

Sami

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
@ 2022-05-16 16:39       ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-16 16:39 UTC (permalink / raw)
  To: David Laight
  Cc: linux-kernel, Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Mon, May 16, 2022 at 1:32 AM David Laight <David.Laight@aculab.com> wrote:
>
> From: Sami Tolvanen
> > Sent: 13 May 2022 21:22
> >
> > With CONFIG_CFI_CLANG, the compiler injects a type preamble
> > immediately before each function and a check to validate the target
> > function type before indirect calls:
> >
> >   ; type preamble
> >   __cfi_function:
> >     int3
> >     int3
> >     mov <id>, %eax
>
> Interesting - since this code can't be executed there is no
> point adding an instruction 'prefix' to the 32bit constant.

The reason to embed the type into an instruction is to avoid the need
to special case objtool's instruction decoder.

> >     int3
> >     int3
> >   function:
> >     ...
> >   ; indirect call check
> >     cmpl    <id>, -6(%r11)
> >     je      .Ltmp1
> >     ud2
> >   .Ltmp1:
> >     call    __x86_indirect_thunk_r11
> >
> > Define the __CFI_TYPE helper macro for manual type annotations in
> > assembly code, add error handling for the CFI ud2 traps, and allow
> > CONFIG_CFI_CLANG to be selected on x86_64.
> >
> ...
> > +
> > +     /*
> > +      * The compiler generates the following instruction sequence
> > +      * for indirect call checks:
> > +      *
> > +      *   cmpl    <id>, -6(%reg)     ; 7 bytes
>
> If the <id> is between -128 and 127 then an 8bit constant
> (sign extended) might be used.
> Possibly the compiler forces the assembler to generate the
> long form.
>
> There could also be a REX prefix.
> That will break any code that tries to use %reg.

The compiler always generates this specific instruction sequence.

> > +      *   je      .Ltmp1             ; 2 bytes
> > +      *   ud2                        ; <- addr
> > +      *   .Ltmp1:
> > +      *
> > +      * Both the type and the target address can be decoded from the
> > +      * cmpl instruction.
> > +      */
> > +     if (copy_from_kernel_nofault(buffer, (void *)regs->ip - 9, MAX_INSN_SIZE))
> > +             return;
> > +     if (insn_decode_kernel(&insn, buffer))
> > +             return;
> > +     if (insn.opcode.value != 0x81 || X86_MODRM_REG(insn.modrm.value) != 7)
> > +             return;
>
> Since you are looking for a very specific opcode why bother
> calling insn_decode_kernel() - just check for the required (masked)
> byte values.

Because I need to decode both the immediate value and the register
from that instruction.

> > +
> > +     *type = insn.immediate.value;
> > +
> > +     offset = insn_get_modrm_rm_off(&insn, regs);
>
> Given the expected instruction, isn't that -6 ??

No, this is the register offset.

> > +     if (offset < 0)
> > +             return;
> > +
> > +     *target = *(unsigned long *)((void *)regs + offset);
>
> WTF is that calculating??

It's reading the register value from pt_regs.

Sami

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
  2022-05-16  9:54     ` Peter Zijlstra
@ 2022-05-16 17:15       ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-16 17:15 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: linux-kernel, Kees Cook, Josh Poimboeuf, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Mon, May 16, 2022 at 2:54 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Fri, May 13, 2022 at 01:21:58PM -0700, Sami Tolvanen wrote:
> > With CONFIG_CFI_CLANG, the compiler injects a type preamble
> > immediately before each function and a check to validate the target
> > function type before indirect calls:
> >
> >   ; type preamble
> >   __cfi_function:
> >     int3
> >     int3
> >     mov <id>, %eax
> >     int3
> >     int3
> >   function:
> >     ...
>
> When I enable CFI_CLANG and X86_KERNEL_IBT I get:
>
> 0000000000000c80 <__cfi_io_schedule_timeout>:
> c80:   cc                      int3
> c81:   cc                      int3
> c82:   b8 b5 b1 39 b3          mov    $0xb339b1b5,%eax
> c87:   cc                      int3
> c88:   cc                      int3
>
> 0000000000000c89 <io_schedule_timeout>:
> c89:   f3 0f 1e fa             endbr64
>
>
> That seems unfortunate. Would it be possible to get an additional
> compiler option to suppress the endbr for all symbols that get a __cfi_
> preaamble?

What's the concern with the endbr? Dropping it would currently break
the CFI+IBT combination on newer hardware, no?

> Also, perhaps s/CFI_CLANG/KERNEL_CFI/ or somesuch, so that GCC might
> also implement this same scheme (in time)?

I'm fine with renaming the config.

> >   ; indirect call check
> >     cmpl    <id>, -6(%r11)
> >     je      .Ltmp1
> >     ud2
> >   .Ltmp1:
> >     call    __x86_indirect_thunk_r11
>
> The first one I try and find looks like:
>
> 26:       41 81 7b fa a6 96 9e 38         cmpl   $0x389e96a6,-0x6(%r11)
> 2e:       74 02                   je     32 <__traceiter_sched_kthread_stop+0x29>
> 30:       0f 0b                   ud2
> 32:       4c 89 f6                mov    %r14,%rsi
> 35:       e8 00 00 00 00          call   3a <__traceiter_sched_kthread_stop+0x31> 36: R_X86_64_PLT32      __x86_indirect_thunk_r11-0x4
>
> This must not be. If I'm to rewrite that lot to:
>
>   movl  $\hash, %r10d
>   sub   $9, %r11
>   call  *%r11
>   .nop  4
>
> Then there must not be spurious instruction in between the ud2 and the
> indirect call/retpoline thing.

With the current compiler patch, LLVM sets up function arguments after
the CFI check. if it's a problem, we can look into changing that.

Sami

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
@ 2022-05-16 17:15       ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-16 17:15 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: linux-kernel, Kees Cook, Josh Poimboeuf, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Mon, May 16, 2022 at 2:54 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Fri, May 13, 2022 at 01:21:58PM -0700, Sami Tolvanen wrote:
> > With CONFIG_CFI_CLANG, the compiler injects a type preamble
> > immediately before each function and a check to validate the target
> > function type before indirect calls:
> >
> >   ; type preamble
> >   __cfi_function:
> >     int3
> >     int3
> >     mov <id>, %eax
> >     int3
> >     int3
> >   function:
> >     ...
>
> When I enable CFI_CLANG and X86_KERNEL_IBT I get:
>
> 0000000000000c80 <__cfi_io_schedule_timeout>:
> c80:   cc                      int3
> c81:   cc                      int3
> c82:   b8 b5 b1 39 b3          mov    $0xb339b1b5,%eax
> c87:   cc                      int3
> c88:   cc                      int3
>
> 0000000000000c89 <io_schedule_timeout>:
> c89:   f3 0f 1e fa             endbr64
>
>
> That seems unfortunate. Would it be possible to get an additional
> compiler option to suppress the endbr for all symbols that get a __cfi_
> preaamble?

What's the concern with the endbr? Dropping it would currently break
the CFI+IBT combination on newer hardware, no?

> Also, perhaps s/CFI_CLANG/KERNEL_CFI/ or somesuch, so that GCC might
> also implement this same scheme (in time)?

I'm fine with renaming the config.

> >   ; indirect call check
> >     cmpl    <id>, -6(%r11)
> >     je      .Ltmp1
> >     ud2
> >   .Ltmp1:
> >     call    __x86_indirect_thunk_r11
>
> The first one I try and find looks like:
>
> 26:       41 81 7b fa a6 96 9e 38         cmpl   $0x389e96a6,-0x6(%r11)
> 2e:       74 02                   je     32 <__traceiter_sched_kthread_stop+0x29>
> 30:       0f 0b                   ud2
> 32:       4c 89 f6                mov    %r14,%rsi
> 35:       e8 00 00 00 00          call   3a <__traceiter_sched_kthread_stop+0x31> 36: R_X86_64_PLT32      __x86_indirect_thunk_r11-0x4
>
> This must not be. If I'm to rewrite that lot to:
>
>   movl  $\hash, %r10d
>   sub   $9, %r11
>   call  *%r11
>   .nop  4
>
> Then there must not be spurious instruction in between the ud2 and the
> indirect call/retpoline thing.

With the current compiler patch, LLVM sets up function arguments after
the CFI check. if it's a problem, we can look into changing that.

Sami

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 21/21] init: Drop __nocfi from __init
  2022-05-14 22:03     ` Kees Cook
@ 2022-05-16 17:16       ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-16 17:16 UTC (permalink / raw)
  To: Kees Cook
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Sat, May 14, 2022 at 3:03 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, May 13, 2022 at 01:21:59PM -0700, Sami Tolvanen wrote:
> > It's no longer necessary to disable CFI checking for all __init
> > functions. Drop the __nocfi attribute.
> >
> > Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
>
> Maybe move this up after patch 11 (the arm64-wide __nocfi removal)?

Yes, that makes sense. I'll move it.

Sami

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 21/21] init: Drop __nocfi from __init
@ 2022-05-16 17:16       ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-16 17:16 UTC (permalink / raw)
  To: Kees Cook
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Sat, May 14, 2022 at 3:03 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, May 13, 2022 at 01:21:59PM -0700, Sami Tolvanen wrote:
> > It's no longer necessary to disable CFI checking for all __init
> > functions. Drop the __nocfi attribute.
> >
> > Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
>
> Maybe move this up after patch 11 (the arm64-wide __nocfi removal)?

Yes, that makes sense. I'll move it.

Sami

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 00/21] KCFI support
       [not found] ` <CA+icZUWr+-HjMvY1VZf+nqjTadxSTDciux0Y5Y-+p_j4o7CmXg@mail.gmail.com>
@ 2022-05-16 17:57     ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-16 17:57 UTC (permalink / raw)
  To: sedat.dilek
  Cc: linux-kernel, Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Mon, May 16, 2022 at 10:31 AM Sedat Dilek <sedat.dilek@gmail.com> wrote:
>> Anything Like LLVM cmake Options to be condidered and Set?
>
>
> I activate Clang and LLD ad projects - OK - enough?

Clang and LLD should be sufficient.

>> This series is also available in GitHub:
>>
>>   https://github.com/samitolvanen/linux/commits/kcfi-rfc-v2
>>
>>
>>
>
>> Can you please add a history of what changed?

Oops, I forgot to include that.

Changes in v2:
- Changed the compiler patch to encode arm64 target and type details
in the ESR, and updated the kernel error handling patch accordingly.
- Changed the compiler patch to embed the x86_64 type hash in a valid
instruction to avoid special casing objtool instruction decoding, and
added a __cfi_ symbol for the preamble. Changed the kernel error
handling and manual type annotations to match.
- Dropped the .kcfi_types section as that’s no longer needed by
objtool, and changed the objtool patch to simply ignore the __cfi_
preambles falling through.
- Dropped the .kcfi_traps section on arm64 as it’s no longer needed,
and moved the trap look-up code behind CONFIG_ARCH_USES_CFI_TRAPS,
which is selected only for x86_64.
- Dropped __nocfi attributes from arm64 code where CFI was disabled
due to address space confusion issues, and added type annotations to
relevant assembly functions.
- Dropped __nocfi from __init.

> Nathan has a i915 cfi patch in His personal kernel.org Git.
> Is this relevant to kcfi?

It fixes a type mismatch, so in that sense it's relevant.

> To distinguish between clang-cfi we should use different kbuild variables for kcfi.

The plan is to replace the current CFI implementation. Does reusing
the kbuild variable names cause a problem?

Sami

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 00/21] KCFI support
@ 2022-05-16 17:57     ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-16 17:57 UTC (permalink / raw)
  To: sedat.dilek
  Cc: linux-kernel, Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Mon, May 16, 2022 at 10:31 AM Sedat Dilek <sedat.dilek@gmail.com> wrote:
>> Anything Like LLVM cmake Options to be condidered and Set?
>
>
> I activate Clang and LLD ad projects - OK - enough?

Clang and LLD should be sufficient.

>> This series is also available in GitHub:
>>
>>   https://github.com/samitolvanen/linux/commits/kcfi-rfc-v2
>>
>>
>>
>
>> Can you please add a history of what changed?

Oops, I forgot to include that.

Changes in v2:
- Changed the compiler patch to encode arm64 target and type details
in the ESR, and updated the kernel error handling patch accordingly.
- Changed the compiler patch to embed the x86_64 type hash in a valid
instruction to avoid special casing objtool instruction decoding, and
added a __cfi_ symbol for the preamble. Changed the kernel error
handling and manual type annotations to match.
- Dropped the .kcfi_types section as that’s no longer needed by
objtool, and changed the objtool patch to simply ignore the __cfi_
preambles falling through.
- Dropped the .kcfi_traps section on arm64 as it’s no longer needed,
and moved the trap look-up code behind CONFIG_ARCH_USES_CFI_TRAPS,
which is selected only for x86_64.
- Dropped __nocfi attributes from arm64 code where CFI was disabled
due to address space confusion issues, and added type annotations to
relevant assembly functions.
- Dropped __nocfi from __init.

> Nathan has a i915 cfi patch in His personal kernel.org Git.
> Is this relevant to kcfi?

It fixes a type mismatch, so in that sense it's relevant.

> To distinguish between clang-cfi we should use different kbuild variables for kcfi.

The plan is to replace the current CFI implementation. Does reusing
the kbuild variable names cause a problem?

Sami

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
  2022-05-16 17:15       ` Sami Tolvanen
@ 2022-05-16 18:30         ` Peter Zijlstra
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Zijlstra @ 2022-05-16 18:30 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Kees Cook, Josh Poimboeuf, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Mon, May 16, 2022 at 10:15:00AM -0700, Sami Tolvanen wrote:
> On Mon, May 16, 2022 at 2:54 AM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Fri, May 13, 2022 at 01:21:58PM -0700, Sami Tolvanen wrote:
> > > With CONFIG_CFI_CLANG, the compiler injects a type preamble
> > > immediately before each function and a check to validate the target
> > > function type before indirect calls:
> > >
> > >   ; type preamble
> > >   __cfi_function:
> > >     int3
> > >     int3
> > >     mov <id>, %eax
> > >     int3
> > >     int3
> > >   function:
> > >     ...
> >
> > When I enable CFI_CLANG and X86_KERNEL_IBT I get:
> >
> > 0000000000000c80 <__cfi_io_schedule_timeout>:
> > c80:   cc                      int3
> > c81:   cc                      int3
> > c82:   b8 b5 b1 39 b3          mov    $0xb339b1b5,%eax
> > c87:   cc                      int3
> > c88:   cc                      int3
> >
> > 0000000000000c89 <io_schedule_timeout>:
> > c89:   f3 0f 1e fa             endbr64
> >
> >
> > That seems unfortunate. Would it be possible to get an additional
> > compiler option to suppress the endbr for all symbols that get a __cfi_
> > preaamble?
> 
> What's the concern with the endbr? Dropping it would currently break
> the CFI+IBT combination on newer hardware, no?

Well, yes, but also that combination isn't very interesting. See,

  https://lore.kernel.org/all/20220420004241.2093-1-joao@overdrivepizza.com/T/#m5d67fb010d488b2f8eee33f1eb39d12f769e4ad2

and the patch I did down-thread:

  https://lkml.kernel.org/r/YoJKhHluN4n0kZDm@hirez.programming.kicks-ass.net

If we have IBT, then FineIBT is a much better option than kCFI+IBT.
Removing that superfluous endbr also shrinks the whole thing by 4 bytes.

So I'm fine with the compiler generating working code for that
combination; but please get me an option to supress it in order to save
those pointless bytes. All this CFI stuff is enough bloat as it is.

> > >   ; indirect call check
> > >     cmpl    <id>, -6(%r11)
> > >     je      .Ltmp1
> > >     ud2
> > >   .Ltmp1:
> > >     call    __x86_indirect_thunk_r11
> >
> > The first one I try and find looks like:
> >
> > 26:       41 81 7b fa a6 96 9e 38         cmpl   $0x389e96a6,-0x6(%r11)
> > 2e:       74 02                   je     32 <__traceiter_sched_kthread_stop+0x29>
> > 30:       0f 0b                   ud2
> > 32:       4c 89 f6                mov    %r14,%rsi
> > 35:       e8 00 00 00 00          call   3a <__traceiter_sched_kthread_stop+0x31> 36: R_X86_64_PLT32      __x86_indirect_thunk_r11-0x4
> >
> > This must not be. If I'm to rewrite that lot to:
> >
> >   movl  $\hash, %r10d
> >   sub   $9, %r11
> >   call  *%r11
> >   .nop  4
> >
> > Then there must not be spurious instruction in between the ud2 and the
> > indirect call/retpoline thing.
> 
> With the current compiler patch, LLVM sets up function arguments after
> the CFI check. if it's a problem, we can look into changing that.

Yes, please fix that. Again see that same patch for why this is a
problem. Objtool can trivially find retpoline calls, but finding this
kCFI gadget is going to be hard work. If you ensure they're
unconditionally stuck together, then the problem goes away find one,
finds the other.


^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
@ 2022-05-16 18:30         ` Peter Zijlstra
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Zijlstra @ 2022-05-16 18:30 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Kees Cook, Josh Poimboeuf, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Mon, May 16, 2022 at 10:15:00AM -0700, Sami Tolvanen wrote:
> On Mon, May 16, 2022 at 2:54 AM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Fri, May 13, 2022 at 01:21:58PM -0700, Sami Tolvanen wrote:
> > > With CONFIG_CFI_CLANG, the compiler injects a type preamble
> > > immediately before each function and a check to validate the target
> > > function type before indirect calls:
> > >
> > >   ; type preamble
> > >   __cfi_function:
> > >     int3
> > >     int3
> > >     mov <id>, %eax
> > >     int3
> > >     int3
> > >   function:
> > >     ...
> >
> > When I enable CFI_CLANG and X86_KERNEL_IBT I get:
> >
> > 0000000000000c80 <__cfi_io_schedule_timeout>:
> > c80:   cc                      int3
> > c81:   cc                      int3
> > c82:   b8 b5 b1 39 b3          mov    $0xb339b1b5,%eax
> > c87:   cc                      int3
> > c88:   cc                      int3
> >
> > 0000000000000c89 <io_schedule_timeout>:
> > c89:   f3 0f 1e fa             endbr64
> >
> >
> > That seems unfortunate. Would it be possible to get an additional
> > compiler option to suppress the endbr for all symbols that get a __cfi_
> > preaamble?
> 
> What's the concern with the endbr? Dropping it would currently break
> the CFI+IBT combination on newer hardware, no?

Well, yes, but also that combination isn't very interesting. See,

  https://lore.kernel.org/all/20220420004241.2093-1-joao@overdrivepizza.com/T/#m5d67fb010d488b2f8eee33f1eb39d12f769e4ad2

and the patch I did down-thread:

  https://lkml.kernel.org/r/YoJKhHluN4n0kZDm@hirez.programming.kicks-ass.net

If we have IBT, then FineIBT is a much better option than kCFI+IBT.
Removing that superfluous endbr also shrinks the whole thing by 4 bytes.

So I'm fine with the compiler generating working code for that
combination; but please get me an option to supress it in order to save
those pointless bytes. All this CFI stuff is enough bloat as it is.

> > >   ; indirect call check
> > >     cmpl    <id>, -6(%r11)
> > >     je      .Ltmp1
> > >     ud2
> > >   .Ltmp1:
> > >     call    __x86_indirect_thunk_r11
> >
> > The first one I try and find looks like:
> >
> > 26:       41 81 7b fa a6 96 9e 38         cmpl   $0x389e96a6,-0x6(%r11)
> > 2e:       74 02                   je     32 <__traceiter_sched_kthread_stop+0x29>
> > 30:       0f 0b                   ud2
> > 32:       4c 89 f6                mov    %r14,%rsi
> > 35:       e8 00 00 00 00          call   3a <__traceiter_sched_kthread_stop+0x31> 36: R_X86_64_PLT32      __x86_indirect_thunk_r11-0x4
> >
> > This must not be. If I'm to rewrite that lot to:
> >
> >   movl  $\hash, %r10d
> >   sub   $9, %r11
> >   call  *%r11
> >   .nop  4
> >
> > Then there must not be spurious instruction in between the ud2 and the
> > indirect call/retpoline thing.
> 
> With the current compiler patch, LLVM sets up function arguments after
> the CFI check. if it's a problem, we can look into changing that.

Yes, please fix that. Again see that same patch for why this is a
problem. Objtool can trivially find retpoline calls, but finding this
kCFI gadget is going to be hard work. If you ensure they're
unconditionally stuck together, then the problem goes away find one,
finds the other.


_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
  2022-05-14 22:02     ` Kees Cook
@ 2022-05-16 18:57       ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-16 18:57 UTC (permalink / raw)
  To: Kees Cook
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Sat, May 14, 2022 at 3:03 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, May 13, 2022 at 01:21:58PM -0700, Sami Tolvanen wrote:
> > +#ifdef CONFIG_CFI_CLANG
> > +static void decode_cfi_insn(struct pt_regs *regs, unsigned long *target,
> > +                         unsigned long *type)
> > +{
> > +     char buffer[MAX_INSN_SIZE];
> > +     struct insn insn;
> > +     int offset;
> > +
> > +     *target = *type = 0;
>
> Should report_cfi_failure() have some additional hinting for the case
> where target/type are zero? Like, "hey, got an inexplicable CFI failure
> here, but preamble decode failed. Yikes!"

Good point, I'll add an error message here.

Sami

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
@ 2022-05-16 18:57       ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-16 18:57 UTC (permalink / raw)
  To: Kees Cook
  Cc: linux-kernel, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Sat, May 14, 2022 at 3:03 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, May 13, 2022 at 01:21:58PM -0700, Sami Tolvanen wrote:
> > +#ifdef CONFIG_CFI_CLANG
> > +static void decode_cfi_insn(struct pt_regs *regs, unsigned long *target,
> > +                         unsigned long *type)
> > +{
> > +     char buffer[MAX_INSN_SIZE];
> > +     struct insn insn;
> > +     int offset;
> > +
> > +     *target = *type = 0;
>
> Should report_cfi_failure() have some additional hinting for the case
> where target/type are zero? Like, "hey, got an inexplicable CFI failure
> here, but preamble decode failed. Yikes!"

Good point, I'll add an error message here.

Sami

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
  2022-05-16 18:30         ` Peter Zijlstra
@ 2022-05-16 19:39           ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-16 19:39 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: linux-kernel, Kees Cook, Josh Poimboeuf, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Mon, May 16, 2022 at 11:30 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Mon, May 16, 2022 at 10:15:00AM -0700, Sami Tolvanen wrote:
> > On Mon, May 16, 2022 at 2:54 AM Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > > On Fri, May 13, 2022 at 01:21:58PM -0700, Sami Tolvanen wrote:
> > > > With CONFIG_CFI_CLANG, the compiler injects a type preamble
> > > > immediately before each function and a check to validate the target
> > > > function type before indirect calls:
> > > >
> > > >   ; type preamble
> > > >   __cfi_function:
> > > >     int3
> > > >     int3
> > > >     mov <id>, %eax
> > > >     int3
> > > >     int3
> > > >   function:
> > > >     ...
> > >
> > > When I enable CFI_CLANG and X86_KERNEL_IBT I get:
> > >
> > > 0000000000000c80 <__cfi_io_schedule_timeout>:
> > > c80:   cc                      int3
> > > c81:   cc                      int3
> > > c82:   b8 b5 b1 39 b3          mov    $0xb339b1b5,%eax
> > > c87:   cc                      int3
> > > c88:   cc                      int3
> > >
> > > 0000000000000c89 <io_schedule_timeout>:
> > > c89:   f3 0f 1e fa             endbr64
> > >
> > >
> > > That seems unfortunate. Would it be possible to get an additional
> > > compiler option to suppress the endbr for all symbols that get a __cfi_
> > > preaamble?
> >
> > What's the concern with the endbr? Dropping it would currently break
> > the CFI+IBT combination on newer hardware, no?
>
> Well, yes, but also that combination isn't very interesting. See,
>
>   https://lore.kernel.org/all/20220420004241.2093-1-joao@overdrivepizza.com/T/#m5d67fb010d488b2f8eee33f1eb39d12f769e4ad2
>
> and the patch I did down-thread:
>
>   https://lkml.kernel.org/r/YoJKhHluN4n0kZDm@hirez.programming.kicks-ass.net
>
> If we have IBT, then FineIBT is a much better option than kCFI+IBT.
> Removing that superfluous endbr also shrinks the whole thing by 4 bytes.
>
> So I'm fine with the compiler generating working code for that
> combination; but please get me an option to supress it in order to save
> those pointless bytes. All this CFI stuff is enough bloat as it is.

Sure, I'll take a look at what's the best way to accomplish this.

> > > >   ; indirect call check
> > > >     cmpl    <id>, -6(%r11)
> > > >     je      .Ltmp1
> > > >     ud2
> > > >   .Ltmp1:
> > > >     call    __x86_indirect_thunk_r11
> > >
> > > The first one I try and find looks like:
> > >
> > > 26:       41 81 7b fa a6 96 9e 38         cmpl   $0x389e96a6,-0x6(%r11)
> > > 2e:       74 02                   je     32 <__traceiter_sched_kthread_stop+0x29>
> > > 30:       0f 0b                   ud2
> > > 32:       4c 89 f6                mov    %r14,%rsi
> > > 35:       e8 00 00 00 00          call   3a <__traceiter_sched_kthread_stop+0x31> 36: R_X86_64_PLT32      __x86_indirect_thunk_r11-0x4
> > >
> > > This must not be. If I'm to rewrite that lot to:
> > >
> > >   movl  $\hash, %r10d
> > >   sub   $9, %r11
> > >   call  *%r11
> > >   .nop  4
> > >
> > > Then there must not be spurious instruction in between the ud2 and the
> > > indirect call/retpoline thing.
> >
> > With the current compiler patch, LLVM sets up function arguments after
> > the CFI check. if it's a problem, we can look into changing that.
>
> Yes, please fix that. Again see that same patch for why this is a
> problem. Objtool can trivially find retpoline calls, but finding this
> kCFI gadget is going to be hard work. If you ensure they're
> unconditionally stuck together, then the problem goes away find one,
> finds the other.

You can use .kcfi_traps to locate the check right now, but I agree,
it's not quite ideal.

Sami

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
@ 2022-05-16 19:39           ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-16 19:39 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: linux-kernel, Kees Cook, Josh Poimboeuf, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Mon, May 16, 2022 at 11:30 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Mon, May 16, 2022 at 10:15:00AM -0700, Sami Tolvanen wrote:
> > On Mon, May 16, 2022 at 2:54 AM Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > > On Fri, May 13, 2022 at 01:21:58PM -0700, Sami Tolvanen wrote:
> > > > With CONFIG_CFI_CLANG, the compiler injects a type preamble
> > > > immediately before each function and a check to validate the target
> > > > function type before indirect calls:
> > > >
> > > >   ; type preamble
> > > >   __cfi_function:
> > > >     int3
> > > >     int3
> > > >     mov <id>, %eax
> > > >     int3
> > > >     int3
> > > >   function:
> > > >     ...
> > >
> > > When I enable CFI_CLANG and X86_KERNEL_IBT I get:
> > >
> > > 0000000000000c80 <__cfi_io_schedule_timeout>:
> > > c80:   cc                      int3
> > > c81:   cc                      int3
> > > c82:   b8 b5 b1 39 b3          mov    $0xb339b1b5,%eax
> > > c87:   cc                      int3
> > > c88:   cc                      int3
> > >
> > > 0000000000000c89 <io_schedule_timeout>:
> > > c89:   f3 0f 1e fa             endbr64
> > >
> > >
> > > That seems unfortunate. Would it be possible to get an additional
> > > compiler option to suppress the endbr for all symbols that get a __cfi_
> > > preaamble?
> >
> > What's the concern with the endbr? Dropping it would currently break
> > the CFI+IBT combination on newer hardware, no?
>
> Well, yes, but also that combination isn't very interesting. See,
>
>   https://lore.kernel.org/all/20220420004241.2093-1-joao@overdrivepizza.com/T/#m5d67fb010d488b2f8eee33f1eb39d12f769e4ad2
>
> and the patch I did down-thread:
>
>   https://lkml.kernel.org/r/YoJKhHluN4n0kZDm@hirez.programming.kicks-ass.net
>
> If we have IBT, then FineIBT is a much better option than kCFI+IBT.
> Removing that superfluous endbr also shrinks the whole thing by 4 bytes.
>
> So I'm fine with the compiler generating working code for that
> combination; but please get me an option to supress it in order to save
> those pointless bytes. All this CFI stuff is enough bloat as it is.

Sure, I'll take a look at what's the best way to accomplish this.

> > > >   ; indirect call check
> > > >     cmpl    <id>, -6(%r11)
> > > >     je      .Ltmp1
> > > >     ud2
> > > >   .Ltmp1:
> > > >     call    __x86_indirect_thunk_r11
> > >
> > > The first one I try and find looks like:
> > >
> > > 26:       41 81 7b fa a6 96 9e 38         cmpl   $0x389e96a6,-0x6(%r11)
> > > 2e:       74 02                   je     32 <__traceiter_sched_kthread_stop+0x29>
> > > 30:       0f 0b                   ud2
> > > 32:       4c 89 f6                mov    %r14,%rsi
> > > 35:       e8 00 00 00 00          call   3a <__traceiter_sched_kthread_stop+0x31> 36: R_X86_64_PLT32      __x86_indirect_thunk_r11-0x4
> > >
> > > This must not be. If I'm to rewrite that lot to:
> > >
> > >   movl  $\hash, %r10d
> > >   sub   $9, %r11
> > >   call  *%r11
> > >   .nop  4
> > >
> > > Then there must not be spurious instruction in between the ud2 and the
> > > indirect call/retpoline thing.
> >
> > With the current compiler patch, LLVM sets up function arguments after
> > the CFI check. if it's a problem, we can look into changing that.
>
> Yes, please fix that. Again see that same patch for why this is a
> problem. Objtool can trivially find retpoline calls, but finding this
> kCFI gadget is going to be hard work. If you ensure they're
> unconditionally stuck together, then the problem goes away find one,
> finds the other.

You can use .kcfi_traps to locate the check right now, but I agree,
it's not quite ideal.

Sami

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
  2022-05-16 19:39           ` Sami Tolvanen
@ 2022-05-16 20:37             ` Peter Zijlstra
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Zijlstra @ 2022-05-16 20:37 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Kees Cook, Josh Poimboeuf, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Mon, May 16, 2022 at 12:39:19PM -0700, Sami Tolvanen wrote:

> > > With the current compiler patch, LLVM sets up function arguments after
> > > the CFI check. if it's a problem, we can look into changing that.
> >
> > Yes, please fix that. Again see that same patch for why this is a
> > problem. Objtool can trivially find retpoline calls, but finding this
> > kCFI gadget is going to be hard work. If you ensure they're
> > unconditionally stuck together, then the problem goes away find one,
> > finds the other.
> 
> You can use .kcfi_traps to locate the check right now, but I agree,
> it's not quite ideal.

Oohh, indeed. Looking at that, I think .kcfi_traps would be better as
relative offsets; eg. 'addr = (void*)s + *s' like. Halfs the amount of
storage needed for it.

Also, that code can use a few {} extra.

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
@ 2022-05-16 20:37             ` Peter Zijlstra
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Zijlstra @ 2022-05-16 20:37 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Kees Cook, Josh Poimboeuf, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Mon, May 16, 2022 at 12:39:19PM -0700, Sami Tolvanen wrote:

> > > With the current compiler patch, LLVM sets up function arguments after
> > > the CFI check. if it's a problem, we can look into changing that.
> >
> > Yes, please fix that. Again see that same patch for why this is a
> > problem. Objtool can trivially find retpoline calls, but finding this
> > kCFI gadget is going to be hard work. If you ensure they're
> > unconditionally stuck together, then the problem goes away find one,
> > finds the other.
> 
> You can use .kcfi_traps to locate the check right now, but I agree,
> it's not quite ideal.

Oohh, indeed. Looking at that, I think .kcfi_traps would be better as
relative offsets; eg. 'addr = (void*)s + *s' like. Halfs the amount of
storage needed for it.

Also, that code can use a few {} extra.

_______________________________________________
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] 174+ messages in thread

* RE: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
  2022-05-16 16:39       ` Sami Tolvanen
@ 2022-05-16 21:32         ` David Laight
  -1 siblings, 0 replies; 174+ messages in thread
From: David Laight @ 2022-05-16 21:32 UTC (permalink / raw)
  To: 'Sami Tolvanen'
  Cc: linux-kernel, Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

From: Sami Tolvanen
> Sent: 16 May 2022 17:39
> 
> On Mon, May 16, 2022 at 1:32 AM David Laight <David.Laight@aculab.com> wrote:
> >
> > From: Sami Tolvanen
> > > Sent: 13 May 2022 21:22
> > >
> > > With CONFIG_CFI_CLANG, the compiler injects a type preamble
> > > immediately before each function and a check to validate the target
> > > function type before indirect calls:
> > >
> > >   ; type preamble
> > >   __cfi_function:
> > >     int3
> > >     int3
> > >     mov <id>, %eax
> >
> > Interesting - since this code can't be executed there is no
> > point adding an instruction 'prefix' to the 32bit constant.
> 
> The reason to embed the type into an instruction is to avoid the need
> to special case objtool's instruction decoder.
> 
> > >     int3
> > >     int3
> > >   function:
> > >     ...
> > >   ; indirect call check
> > >     cmpl    <id>, -6(%r11)
> > >     je      .Ltmp1
> > >     ud2
> > >   .Ltmp1:
> > >     call    __x86_indirect_thunk_r11
> > >
> > > Define the __CFI_TYPE helper macro for manual type annotations in
> > > assembly code, add error handling for the CFI ud2 traps, and allow
> > > CONFIG_CFI_CLANG to be selected on x86_64.
> > >
> > ...
> > > +
> > > +     /*
> > > +      * The compiler generates the following instruction sequence
> > > +      * for indirect call checks:
> > > +      *
> > > +      *   cmpl    <id>, -6(%reg)     ; 7 bytes
> >
> > If the <id> is between -128 and 127 then an 8bit constant
> > (sign extended) might be used.
> > Possibly the compiler forces the assembler to generate the
> > long form.
> >
> > There could also be a REX prefix.
> > That will break any code that tries to use %reg.
> 
> The compiler always generates this specific instruction sequence.

Yes, but there are several ways to encode 'cmpl imm,-6(reg)'.
Firstly you can use '81 /7 imm32' or '83 /7 imm8' where imm8 is sign extended.
(the /7 1/7/index_reg for a signed 8 bit offset).
But that only works for the original 32bit registers.
For the 64bit r8 to r15 an extra REX prefix is required.
That makes the instruction 8 bytes (if it needs a full 32bit immediate).

So if the register is %r11 there is an extra REX byte.
If the <id> is a hash and happens to be between -128 and 127
then there are three less bytes.

So decoding from regs->ip - 0 isn't always going to give
you the start of the instruction.

> 
> > > +      *   je      .Ltmp1             ; 2 bytes
> > > +      *   ud2                        ; <- addr
> > > +      *   .Ltmp1:
> > > +      *
> > > +      * Both the type and the target address can be decoded from the
> > > +      * cmpl instruction.
> > > +      */
> > > +     if (copy_from_kernel_nofault(buffer, (void *)regs->ip - 9, MAX_INSN_SIZE))
> > > +             return;
> > > +     if (insn_decode_kernel(&insn, buffer))
> > > +             return;
> > > +     if (insn.opcode.value != 0x81 || X86_MODRM_REG(insn.modrm.value) != 7)
> > > +             return;
> >
> > Since you are looking for a very specific opcode why bother
> > calling insn_decode_kernel() - just check for the required (masked)
> > byte values.
> 
> Because I need to decode both the immediate value and the register
> from that instruction.
> 
> > > +
> > > +     *type = insn.immediate.value;
> > > +
> > > +     offset = insn_get_modrm_rm_off(&insn, regs);
> >
> > Given the expected instruction, isn't that -6 ??
> 
> No, this is the register offset.

Hmmm.... strange function name...
> 
> > > +     if (offset < 0)
> > > +             return;
> > > +
> > > +     *target = *(unsigned long *)((void *)regs + offset);
> >
> > WTF is that calculating??
> 
> It's reading the register value from pt_regs.
> 
> Sami

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

^ permalink raw reply	[flat|nested] 174+ messages in thread

* RE: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
@ 2022-05-16 21:32         ` David Laight
  0 siblings, 0 replies; 174+ messages in thread
From: David Laight @ 2022-05-16 21:32 UTC (permalink / raw)
  To: 'Sami Tolvanen'
  Cc: linux-kernel, Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

From: Sami Tolvanen
> Sent: 16 May 2022 17:39
> 
> On Mon, May 16, 2022 at 1:32 AM David Laight <David.Laight@aculab.com> wrote:
> >
> > From: Sami Tolvanen
> > > Sent: 13 May 2022 21:22
> > >
> > > With CONFIG_CFI_CLANG, the compiler injects a type preamble
> > > immediately before each function and a check to validate the target
> > > function type before indirect calls:
> > >
> > >   ; type preamble
> > >   __cfi_function:
> > >     int3
> > >     int3
> > >     mov <id>, %eax
> >
> > Interesting - since this code can't be executed there is no
> > point adding an instruction 'prefix' to the 32bit constant.
> 
> The reason to embed the type into an instruction is to avoid the need
> to special case objtool's instruction decoder.
> 
> > >     int3
> > >     int3
> > >   function:
> > >     ...
> > >   ; indirect call check
> > >     cmpl    <id>, -6(%r11)
> > >     je      .Ltmp1
> > >     ud2
> > >   .Ltmp1:
> > >     call    __x86_indirect_thunk_r11
> > >
> > > Define the __CFI_TYPE helper macro for manual type annotations in
> > > assembly code, add error handling for the CFI ud2 traps, and allow
> > > CONFIG_CFI_CLANG to be selected on x86_64.
> > >
> > ...
> > > +
> > > +     /*
> > > +      * The compiler generates the following instruction sequence
> > > +      * for indirect call checks:
> > > +      *
> > > +      *   cmpl    <id>, -6(%reg)     ; 7 bytes
> >
> > If the <id> is between -128 and 127 then an 8bit constant
> > (sign extended) might be used.
> > Possibly the compiler forces the assembler to generate the
> > long form.
> >
> > There could also be a REX prefix.
> > That will break any code that tries to use %reg.
> 
> The compiler always generates this specific instruction sequence.

Yes, but there are several ways to encode 'cmpl imm,-6(reg)'.
Firstly you can use '81 /7 imm32' or '83 /7 imm8' where imm8 is sign extended.
(the /7 1/7/index_reg for a signed 8 bit offset).
But that only works for the original 32bit registers.
For the 64bit r8 to r15 an extra REX prefix is required.
That makes the instruction 8 bytes (if it needs a full 32bit immediate).

So if the register is %r11 there is an extra REX byte.
If the <id> is a hash and happens to be between -128 and 127
then there are three less bytes.

So decoding from regs->ip - 0 isn't always going to give
you the start of the instruction.

> 
> > > +      *   je      .Ltmp1             ; 2 bytes
> > > +      *   ud2                        ; <- addr
> > > +      *   .Ltmp1:
> > > +      *
> > > +      * Both the type and the target address can be decoded from the
> > > +      * cmpl instruction.
> > > +      */
> > > +     if (copy_from_kernel_nofault(buffer, (void *)regs->ip - 9, MAX_INSN_SIZE))
> > > +             return;
> > > +     if (insn_decode_kernel(&insn, buffer))
> > > +             return;
> > > +     if (insn.opcode.value != 0x81 || X86_MODRM_REG(insn.modrm.value) != 7)
> > > +             return;
> >
> > Since you are looking for a very specific opcode why bother
> > calling insn_decode_kernel() - just check for the required (masked)
> > byte values.
> 
> Because I need to decode both the immediate value and the register
> from that instruction.
> 
> > > +
> > > +     *type = insn.immediate.value;
> > > +
> > > +     offset = insn_get_modrm_rm_off(&insn, regs);
> >
> > Given the expected instruction, isn't that -6 ??
> 
> No, this is the register offset.

Hmmm.... strange function name...
> 
> > > +     if (offset < 0)
> > > +             return;
> > > +
> > > +     *target = *(unsigned long *)((void *)regs + offset);
> >
> > WTF is that calculating??
> 
> It's reading the register value from pt_regs.
> 
> Sami

	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] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
  2022-05-16 21:32         ` David Laight
@ 2022-05-16 21:44           ` Peter Zijlstra
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Zijlstra @ 2022-05-16 21:44 UTC (permalink / raw)
  To: David Laight
  Cc: 'Sami Tolvanen',
	linux-kernel, Kees Cook, Josh Poimboeuf, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Mon, May 16, 2022 at 09:32:55PM +0000, David Laight wrote:

> > The compiler always generates this specific instruction sequence.
> 
> Yes, but there are several ways to encode 'cmpl imm,-6(reg)'.

Yes, but we don't care. This *always* uses the 32bit immediate form.
Even if the immediate is small.

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
@ 2022-05-16 21:44           ` Peter Zijlstra
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Zijlstra @ 2022-05-16 21:44 UTC (permalink / raw)
  To: David Laight
  Cc: 'Sami Tolvanen',
	linux-kernel, Kees Cook, Josh Poimboeuf, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Mon, May 16, 2022 at 09:32:55PM +0000, David Laight wrote:

> > The compiler always generates this specific instruction sequence.
> 
> Yes, but there are several ways to encode 'cmpl imm,-6(reg)'.

Yes, but we don't care. This *always* uses the 32bit immediate form.
Even if the immediate is small.

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
  2022-05-16 21:44           ` Peter Zijlstra
@ 2022-05-16 22:03             ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-16 22:03 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: David Laight, linux-kernel, Kees Cook, Josh Poimboeuf, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Mon, May 16, 2022 at 2:44 PM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Mon, May 16, 2022 at 09:32:55PM +0000, David Laight wrote:
>
> > > The compiler always generates this specific instruction sequence.
> >
> > Yes, but there are several ways to encode 'cmpl imm,-6(reg)'.
>
> Yes, but we don't care. This *always* uses the 32bit immediate form.
> Even if the immediate is small.

Yes, that part is not a problem, but it's a valid point that LLVM
might not always use r8-r15 here, so I will have to check for the REX
prefix before blindly attempting to decode the instruction.

Sami

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
@ 2022-05-16 22:03             ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-16 22:03 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: David Laight, linux-kernel, Kees Cook, Josh Poimboeuf, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Mon, May 16, 2022 at 2:44 PM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Mon, May 16, 2022 at 09:32:55PM +0000, David Laight wrote:
>
> > > The compiler always generates this specific instruction sequence.
> >
> > Yes, but there are several ways to encode 'cmpl imm,-6(reg)'.
>
> Yes, but we don't care. This *always* uses the 32bit immediate form.
> Even if the immediate is small.

Yes, that part is not a problem, but it's a valid point that LLVM
might not always use r8-r15 here, so I will have to check for the REX
prefix before blindly attempting to decode the instruction.

Sami

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
  2022-05-16 18:30         ` Peter Zijlstra
@ 2022-05-16 22:59           ` Kees Cook
  -1 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-16 22:59 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Sami Tolvanen, linux-kernel, Josh Poimboeuf, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Mon, May 16, 2022 at 08:30:47PM +0200, Peter Zijlstra wrote:
> On Mon, May 16, 2022 at 10:15:00AM -0700, Sami Tolvanen wrote:
> > On Mon, May 16, 2022 at 2:54 AM Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > > On Fri, May 13, 2022 at 01:21:58PM -0700, Sami Tolvanen wrote:
> > > > With CONFIG_CFI_CLANG, the compiler injects a type preamble
> > > > immediately before each function and a check to validate the target
> > > > function type before indirect calls:
> > > >
> > > >   ; type preamble
> > > >   __cfi_function:
> > > >     int3
> > > >     int3
> > > >     mov <id>, %eax
> > > >     int3
> > > >     int3
> > > >   function:
> > > >     ...
> > >
> > > When I enable CFI_CLANG and X86_KERNEL_IBT I get:
> > >
> > > 0000000000000c80 <__cfi_io_schedule_timeout>:
> > > c80:   cc                      int3
> > > c81:   cc                      int3
> > > c82:   b8 b5 b1 39 b3          mov    $0xb339b1b5,%eax
> > > c87:   cc                      int3
> > > c88:   cc                      int3
> > >
> > > 0000000000000c89 <io_schedule_timeout>:
> > > c89:   f3 0f 1e fa             endbr64
> > >
> > >
> > > That seems unfortunate. Would it be possible to get an additional
> > > compiler option to suppress the endbr for all symbols that get a __cfi_
> > > preaamble?
> > 
> > What's the concern with the endbr? Dropping it would currently break
> > the CFI+IBT combination on newer hardware, no?
> 
> Well, yes, but also that combination isn't very interesting. See,
> 
>   https://lore.kernel.org/all/20220420004241.2093-1-joao@overdrivepizza.com/T/#m5d67fb010d488b2f8eee33f1eb39d12f769e4ad2
> 
> and the patch I did down-thread:
> 
>   https://lkml.kernel.org/r/YoJKhHluN4n0kZDm@hirez.programming.kicks-ass.net
> 
> If we have IBT, then FineIBT is a much better option than kCFI+IBT.

I'm still not convinced about this, but I'm on the fence.

Cons:
- FineIBT does callee-based hash verification, which means any
  attacker-constructed memory region just has to have an endbr and nops at
  "shellcode - 9". KCFI would need the region to have the hash at
  "shellcode - 6" and an endbr at "shellcode". However, that hash is well
  known, so it's not much protection.
- Potential performance hit due to making an additional "call" outside
  the cache lines of both caller and callee.

Pros:
- FineIBT can be done without read access to the kernel text, which will
  be nice in the exec-only future.

I'd kind of like the "dynamic FineIBT conversion" to be a config option,
at least at first. We could at least do performance comparisons between
them.

> Removing that superfluous endbr also shrinks the whole thing by 4 bytes.
> 
> So I'm fine with the compiler generating working code for that
> combination; but please get me an option to supress it in order to save
> those pointless bytes. All this CFI stuff is enough bloat as it is.

So, in the case of "built for IBT but running on a system without IBT",
no rewrite happens, and no endbr is present (i.e. address-taken
functions have endbr emission suppressed)?

Stock kernel build:
	function:
		[normal code]
	caller:
		call    __x86_indirect_thunk_r11

IBT kernel build:
	function:
		endbr
		[normal code]
	caller:
		call    __x86_indirect_thunk_r11

CFI kernel build:

	__cfi_function:
		[int3/mov/int3 preamble]
	function:
		[normal code]
	caller:
		cmpl    \hash, -6(%r11)
		je      .Ltmp1
		ud2
	.Ltmp1:
		call    __x86_indirect_thunk_r11

CFI+IBT kernel build:

	__cfi_function:
		[int3/mov/int3 preamble]
	function:
		endbr
		[normal code]
	caller:
		cmpl    \hash, -6(%r11)
		je      .Ltmp1
		ud2
	.Ltmp1:
		call    __x86_indirect_thunk_r11

CFI+IBT+FineIBT kernel build:

	__cfi_function:
		[int3/mov/int3 preamble]
	function:
		/* no endbr emitted */
		[normal code]
	caller:
		cmpl    \hash, -6(%r11)
		je      .Ltmp1
		ud2
	.Ltmp1:
		call    __x86_indirect_thunk_r11

	at boot, if IBT is detected:
	- replace __cfi_function with:
		endbr
		call __fineibt_\hash
	- replace caller with:
		movl    \hash, %r10d
		sub     $9, %r11
		nop2
		call    *%r11
	- inject all the __fineibt_\hash elements via module_alloc()
		__fineibt_\hash:
			xor     \hash, %r10
			jz      1f
			ud2
		1:	ret
			int3



-- 
Kees Cook

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
@ 2022-05-16 22:59           ` Kees Cook
  0 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-16 22:59 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Sami Tolvanen, linux-kernel, Josh Poimboeuf, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Mon, May 16, 2022 at 08:30:47PM +0200, Peter Zijlstra wrote:
> On Mon, May 16, 2022 at 10:15:00AM -0700, Sami Tolvanen wrote:
> > On Mon, May 16, 2022 at 2:54 AM Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > > On Fri, May 13, 2022 at 01:21:58PM -0700, Sami Tolvanen wrote:
> > > > With CONFIG_CFI_CLANG, the compiler injects a type preamble
> > > > immediately before each function and a check to validate the target
> > > > function type before indirect calls:
> > > >
> > > >   ; type preamble
> > > >   __cfi_function:
> > > >     int3
> > > >     int3
> > > >     mov <id>, %eax
> > > >     int3
> > > >     int3
> > > >   function:
> > > >     ...
> > >
> > > When I enable CFI_CLANG and X86_KERNEL_IBT I get:
> > >
> > > 0000000000000c80 <__cfi_io_schedule_timeout>:
> > > c80:   cc                      int3
> > > c81:   cc                      int3
> > > c82:   b8 b5 b1 39 b3          mov    $0xb339b1b5,%eax
> > > c87:   cc                      int3
> > > c88:   cc                      int3
> > >
> > > 0000000000000c89 <io_schedule_timeout>:
> > > c89:   f3 0f 1e fa             endbr64
> > >
> > >
> > > That seems unfortunate. Would it be possible to get an additional
> > > compiler option to suppress the endbr for all symbols that get a __cfi_
> > > preaamble?
> > 
> > What's the concern with the endbr? Dropping it would currently break
> > the CFI+IBT combination on newer hardware, no?
> 
> Well, yes, but also that combination isn't very interesting. See,
> 
>   https://lore.kernel.org/all/20220420004241.2093-1-joao@overdrivepizza.com/T/#m5d67fb010d488b2f8eee33f1eb39d12f769e4ad2
> 
> and the patch I did down-thread:
> 
>   https://lkml.kernel.org/r/YoJKhHluN4n0kZDm@hirez.programming.kicks-ass.net
> 
> If we have IBT, then FineIBT is a much better option than kCFI+IBT.

I'm still not convinced about this, but I'm on the fence.

Cons:
- FineIBT does callee-based hash verification, which means any
  attacker-constructed memory region just has to have an endbr and nops at
  "shellcode - 9". KCFI would need the region to have the hash at
  "shellcode - 6" and an endbr at "shellcode". However, that hash is well
  known, so it's not much protection.
- Potential performance hit due to making an additional "call" outside
  the cache lines of both caller and callee.

Pros:
- FineIBT can be done without read access to the kernel text, which will
  be nice in the exec-only future.

I'd kind of like the "dynamic FineIBT conversion" to be a config option,
at least at first. We could at least do performance comparisons between
them.

> Removing that superfluous endbr also shrinks the whole thing by 4 bytes.
> 
> So I'm fine with the compiler generating working code for that
> combination; but please get me an option to supress it in order to save
> those pointless bytes. All this CFI stuff is enough bloat as it is.

So, in the case of "built for IBT but running on a system without IBT",
no rewrite happens, and no endbr is present (i.e. address-taken
functions have endbr emission suppressed)?

Stock kernel build:
	function:
		[normal code]
	caller:
		call    __x86_indirect_thunk_r11

IBT kernel build:
	function:
		endbr
		[normal code]
	caller:
		call    __x86_indirect_thunk_r11

CFI kernel build:

	__cfi_function:
		[int3/mov/int3 preamble]
	function:
		[normal code]
	caller:
		cmpl    \hash, -6(%r11)
		je      .Ltmp1
		ud2
	.Ltmp1:
		call    __x86_indirect_thunk_r11

CFI+IBT kernel build:

	__cfi_function:
		[int3/mov/int3 preamble]
	function:
		endbr
		[normal code]
	caller:
		cmpl    \hash, -6(%r11)
		je      .Ltmp1
		ud2
	.Ltmp1:
		call    __x86_indirect_thunk_r11

CFI+IBT+FineIBT kernel build:

	__cfi_function:
		[int3/mov/int3 preamble]
	function:
		/* no endbr emitted */
		[normal code]
	caller:
		cmpl    \hash, -6(%r11)
		je      .Ltmp1
		ud2
	.Ltmp1:
		call    __x86_indirect_thunk_r11

	at boot, if IBT is detected:
	- replace __cfi_function with:
		endbr
		call __fineibt_\hash
	- replace caller with:
		movl    \hash, %r10d
		sub     $9, %r11
		nop2
		call    *%r11
	- inject all the __fineibt_\hash elements via module_alloc()
		__fineibt_\hash:
			xor     \hash, %r10
			jz      1f
			ud2
		1:	ret
			int3



-- 
Kees Cook

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
  2022-05-16 22:03             ` Sami Tolvanen
@ 2022-05-17  6:44               ` Peter Zijlstra
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Zijlstra @ 2022-05-17  6:44 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: David Laight, linux-kernel, Kees Cook, Josh Poimboeuf, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Mon, May 16, 2022 at 03:03:02PM -0700, Sami Tolvanen wrote:
> On Mon, May 16, 2022 at 2:44 PM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Mon, May 16, 2022 at 09:32:55PM +0000, David Laight wrote:
> >
> > > > The compiler always generates this specific instruction sequence.
> > >
> > > Yes, but there are several ways to encode 'cmpl imm,-6(reg)'.
> >
> > Yes, but we don't care. This *always* uses the 32bit immediate form.
> > Even if the immediate is small.
> 
> Yes, that part is not a problem, but it's a valid point that LLVM
> might not always use r8-r15 here, so I will have to check for the REX
> prefix before blindly attempting to decode the instruction.

LLVM has always used r11 for indirect calls, will that change?

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
@ 2022-05-17  6:44               ` Peter Zijlstra
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Zijlstra @ 2022-05-17  6:44 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: David Laight, linux-kernel, Kees Cook, Josh Poimboeuf, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Mon, May 16, 2022 at 03:03:02PM -0700, Sami Tolvanen wrote:
> On Mon, May 16, 2022 at 2:44 PM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Mon, May 16, 2022 at 09:32:55PM +0000, David Laight wrote:
> >
> > > > The compiler always generates this specific instruction sequence.
> > >
> > > Yes, but there are several ways to encode 'cmpl imm,-6(reg)'.
> >
> > Yes, but we don't care. This *always* uses the 32bit immediate form.
> > Even if the immediate is small.
> 
> Yes, that part is not a problem, but it's a valid point that LLVM
> might not always use r8-r15 here, so I will have to check for the REX
> prefix before blindly attempting to decode the instruction.

LLVM has always used r11 for indirect calls, will that change?

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 00/21] KCFI support
  2022-05-16 17:57     ` Sami Tolvanen
@ 2022-05-17  7:33       ` Sedat Dilek
  -1 siblings, 0 replies; 174+ messages in thread
From: Sedat Dilek @ 2022-05-17  7:33 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Mon, May 16, 2022 at 7:57 PM Sami Tolvanen <samitolvanen@google.com> wrote:
>
> On Mon, May 16, 2022 at 10:31 AM Sedat Dilek <sedat.dilek@gmail.com> wrote:
> >> Anything Like LLVM cmake Options to be condidered and Set?
> >
> >
> > I activate Clang and LLD ad projects - OK - enough?
>
> Clang and LLD should be sufficient.
>

Before I give this a try...
Some questions about the LLVM toolchain requirements...

I use tc-build to generate a selfmade LLVM toolchain for X86
(stage1-only + BPF).

$ python3 ./build-llvm.py --no-update --build-type Release -p
clang;lld -t X86;BPF --clang-vendor dileks -B
/home/dileks/src/llvm-toolchain/build -I /opt/llvm-toolchain
--check-targets clang lld --build-stage1-only --install-stage1-only -D
LLVM_PARALLEL_LINK_JOBS=1 --show-build-commands

Link: https://github.com/ClangBuiltLinux/tc-build.git

tc-build uses a GOOD_REVISION for regular kernel-builds, this is
currently 3b2e605e33bd.

$ git describe
llvmorg-15-init-5163-g3b2e605e33bd

$ git show -1 42a879eb2f22
commit 42a879eb2f22af6d1b85983c12fac68b2e9a5e03
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Mon Mar 21 09:19:26 2022 -0700

   build-llvm.py: Update known good revision

   Qualified with https://github.com/nathanchance/llvm-kernel-testing.

   Signed-off-by: Nathan Chancellor <nathan@kernel.org>

diff --git a/build-llvm.py b/build-llvm.py
index c3aade1092ec..54e5d4729a1a 100755
--- a/build-llvm.py
+++ b/build-llvm.py
@@ -16,7 +16,7 @@ import urllib.request as request
from urllib.error import URLError

# This is a known good revision of LLVM for building the kernel
-GOOD_REVISION = '08f70adedb775ce6d41a1f8ad75c4bac225efb5b'
+GOOD_REVISION = '3b2e605e33bd9017ff2eff1493add07822f9d58b'


class Directories:

So, your LLVM git is approx. 5.200 commits further.

$ git log --oneline
tc-build/GOOD_REVISION-20210321..for-15/kcfi-rfc-v2-samitolvanen | wc
-l
5190

Is your tags/kcfi-rfc-v2 the recommended LLVM toolchain for testing kcfi-rfc-v2?

What I want to ask is if your commit well tested for x86 (and arm64)
means build and boot on bare metal?

From Nathan I know if he says I have run kernel-tests - it works.
"Qualified with https://github.com/nathanchance/llvm-kernel-testing."

Just for the records:
You definitely need a pre-LLVM-15 toolchain + KCFI sanitizer patch?
LLVM-14?

> >> This series is also available in GitHub:
> >>
> >>   https://github.com/samitolvanen/linux/commits/kcfi-rfc-v2
> >>
> >>
> >>
> >
> >> Can you please add a history of what changed?
>
> Oops, I forgot to include that.
>

Thanks.
Please fold this ChangeLog into kcfi-rfc-v3.

> Changes in v2:
> - Changed the compiler patch to encode arm64 target and type details
> in the ESR, and updated the kernel error handling patch accordingly.
> - Changed the compiler patch to embed the x86_64 type hash in a valid
> instruction to avoid special casing objtool instruction decoding, and
> added a __cfi_ symbol for the preamble. Changed the kernel error
> handling and manual type annotations to match.
> - Dropped the .kcfi_types section as that’s no longer needed by
> objtool, and changed the objtool patch to simply ignore the __cfi_
> preambles falling through.
> - Dropped the .kcfi_traps section on arm64 as it’s no longer needed,
> and moved the trap look-up code behind CONFIG_ARCH_USES_CFI_TRAPS,
> which is selected only for x86_64.
> - Dropped __nocfi attributes from arm64 code where CFI was disabled
> due to address space confusion issues, and added type annotations to
> relevant assembly functions.
> - Dropped __nocfi from __init.
>
> > Nathan has a i915 cfi patch in His personal kernel.org Git.
> > Is this relevant to kcfi?
>
> It fixes a type mismatch, so in that sense it's relevant.
>

Here the link to patch "drm/i915: Fix CFI violation with show_dynamic_id()":

https://git.kernel.org/pub/scm/linux/kernel/git/nathan/linux.git/commit/?h=submitted/i915-cfi-fix&id=53735be6dc53453fcfbac658e847b54360e73871

> > To distinguish between clang-cfi we should use different kbuild variables for kcfi.
>
> The plan is to replace the current CFI implementation. Does reusing
> the kbuild variable names cause a problem?
>

No hurry.
Afaics someone in the long list of comments to single patches was
thinking of when GCC has "KCFI" support implemented...

You say no need to build your kernel with LTO...
That sounds good.
Currently, I build my kernels with Clang-14 and CONFIG_LTO_CLANG_THIN=y.
Does something speak against using CONFIG_LTO_CLANG_THIN=y with KCFI support?
Build-time?
Disc-usage?

Thanks for answering my questions.

- Sedat -

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 00/21] KCFI support
@ 2022-05-17  7:33       ` Sedat Dilek
  0 siblings, 0 replies; 174+ messages in thread
From: Sedat Dilek @ 2022-05-17  7:33 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Mon, May 16, 2022 at 7:57 PM Sami Tolvanen <samitolvanen@google.com> wrote:
>
> On Mon, May 16, 2022 at 10:31 AM Sedat Dilek <sedat.dilek@gmail.com> wrote:
> >> Anything Like LLVM cmake Options to be condidered and Set?
> >
> >
> > I activate Clang and LLD ad projects - OK - enough?
>
> Clang and LLD should be sufficient.
>

Before I give this a try...
Some questions about the LLVM toolchain requirements...

I use tc-build to generate a selfmade LLVM toolchain for X86
(stage1-only + BPF).

$ python3 ./build-llvm.py --no-update --build-type Release -p
clang;lld -t X86;BPF --clang-vendor dileks -B
/home/dileks/src/llvm-toolchain/build -I /opt/llvm-toolchain
--check-targets clang lld --build-stage1-only --install-stage1-only -D
LLVM_PARALLEL_LINK_JOBS=1 --show-build-commands

Link: https://github.com/ClangBuiltLinux/tc-build.git

tc-build uses a GOOD_REVISION for regular kernel-builds, this is
currently 3b2e605e33bd.

$ git describe
llvmorg-15-init-5163-g3b2e605e33bd

$ git show -1 42a879eb2f22
commit 42a879eb2f22af6d1b85983c12fac68b2e9a5e03
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Mon Mar 21 09:19:26 2022 -0700

   build-llvm.py: Update known good revision

   Qualified with https://github.com/nathanchance/llvm-kernel-testing.

   Signed-off-by: Nathan Chancellor <nathan@kernel.org>

diff --git a/build-llvm.py b/build-llvm.py
index c3aade1092ec..54e5d4729a1a 100755
--- a/build-llvm.py
+++ b/build-llvm.py
@@ -16,7 +16,7 @@ import urllib.request as request
from urllib.error import URLError

# This is a known good revision of LLVM for building the kernel
-GOOD_REVISION = '08f70adedb775ce6d41a1f8ad75c4bac225efb5b'
+GOOD_REVISION = '3b2e605e33bd9017ff2eff1493add07822f9d58b'


class Directories:

So, your LLVM git is approx. 5.200 commits further.

$ git log --oneline
tc-build/GOOD_REVISION-20210321..for-15/kcfi-rfc-v2-samitolvanen | wc
-l
5190

Is your tags/kcfi-rfc-v2 the recommended LLVM toolchain for testing kcfi-rfc-v2?

What I want to ask is if your commit well tested for x86 (and arm64)
means build and boot on bare metal?

From Nathan I know if he says I have run kernel-tests - it works.
"Qualified with https://github.com/nathanchance/llvm-kernel-testing."

Just for the records:
You definitely need a pre-LLVM-15 toolchain + KCFI sanitizer patch?
LLVM-14?

> >> This series is also available in GitHub:
> >>
> >>   https://github.com/samitolvanen/linux/commits/kcfi-rfc-v2
> >>
> >>
> >>
> >
> >> Can you please add a history of what changed?
>
> Oops, I forgot to include that.
>

Thanks.
Please fold this ChangeLog into kcfi-rfc-v3.

> Changes in v2:
> - Changed the compiler patch to encode arm64 target and type details
> in the ESR, and updated the kernel error handling patch accordingly.
> - Changed the compiler patch to embed the x86_64 type hash in a valid
> instruction to avoid special casing objtool instruction decoding, and
> added a __cfi_ symbol for the preamble. Changed the kernel error
> handling and manual type annotations to match.
> - Dropped the .kcfi_types section as that’s no longer needed by
> objtool, and changed the objtool patch to simply ignore the __cfi_
> preambles falling through.
> - Dropped the .kcfi_traps section on arm64 as it’s no longer needed,
> and moved the trap look-up code behind CONFIG_ARCH_USES_CFI_TRAPS,
> which is selected only for x86_64.
> - Dropped __nocfi attributes from arm64 code where CFI was disabled
> due to address space confusion issues, and added type annotations to
> relevant assembly functions.
> - Dropped __nocfi from __init.
>
> > Nathan has a i915 cfi patch in His personal kernel.org Git.
> > Is this relevant to kcfi?
>
> It fixes a type mismatch, so in that sense it's relevant.
>

Here the link to patch "drm/i915: Fix CFI violation with show_dynamic_id()":

https://git.kernel.org/pub/scm/linux/kernel/git/nathan/linux.git/commit/?h=submitted/i915-cfi-fix&id=53735be6dc53453fcfbac658e847b54360e73871

> > To distinguish between clang-cfi we should use different kbuild variables for kcfi.
>
> The plan is to replace the current CFI implementation. Does reusing
> the kbuild variable names cause a problem?
>

No hurry.
Afaics someone in the long list of comments to single patches was
thinking of when GCC has "KCFI" support implemented...

You say no need to build your kernel with LTO...
That sounds good.
Currently, I build my kernels with Clang-14 and CONFIG_LTO_CLANG_THIN=y.
Does something speak against using CONFIG_LTO_CLANG_THIN=y with KCFI support?
Build-time?
Disc-usage?

Thanks for answering my questions.

- Sedat -

_______________________________________________
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] 174+ messages in thread

* RE: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
  2022-05-16 22:03             ` Sami Tolvanen
@ 2022-05-17  7:56               ` David Laight
  -1 siblings, 0 replies; 174+ messages in thread
From: David Laight @ 2022-05-17  7:56 UTC (permalink / raw)
  To: 'Sami Tolvanen', Peter Zijlstra
  Cc: linux-kernel, Kees Cook, Josh Poimboeuf, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

From: Sami Tolvanen
> Sent: 16 May 2022 23:03
> 
> On Mon, May 16, 2022 at 2:44 PM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Mon, May 16, 2022 at 09:32:55PM +0000, David Laight wrote:
> >
> > > > The compiler always generates this specific instruction sequence.
> > >
> > > Yes, but there are several ways to encode 'cmpl imm,-6(reg)'.
> >
> > Yes, but we don't care. This *always* uses the 32bit immediate form.
> > Even if the immediate is small.
> 
> Yes, that part is not a problem, but it's a valid point that LLVM
> might not always use r8-r15 here, so I will have to check for the REX
> prefix before blindly attempting to decode the instruction.

Are you allowing for the REX prefix at all?
The encoding of:
> > > +      *   cmpl    <id>, -6(%reg)     ; 7 bytes
is
	<opcode><mod/TTT/rm><off8><imm32>
which is 7 bytes without the REX.
If reg is r11 there is an extra REX byte - for 8 in total.

Without the REX byte the decode will be using %bx.
So the testing should all have failed.
Which means that something else is wrong as well.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

^ permalink raw reply	[flat|nested] 174+ messages in thread

* RE: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
@ 2022-05-17  7:56               ` David Laight
  0 siblings, 0 replies; 174+ messages in thread
From: David Laight @ 2022-05-17  7:56 UTC (permalink / raw)
  To: 'Sami Tolvanen', Peter Zijlstra
  Cc: linux-kernel, Kees Cook, Josh Poimboeuf, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

From: Sami Tolvanen
> Sent: 16 May 2022 23:03
> 
> On Mon, May 16, 2022 at 2:44 PM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Mon, May 16, 2022 at 09:32:55PM +0000, David Laight wrote:
> >
> > > > The compiler always generates this specific instruction sequence.
> > >
> > > Yes, but there are several ways to encode 'cmpl imm,-6(reg)'.
> >
> > Yes, but we don't care. This *always* uses the 32bit immediate form.
> > Even if the immediate is small.
> 
> Yes, that part is not a problem, but it's a valid point that LLVM
> might not always use r8-r15 here, so I will have to check for the REX
> prefix before blindly attempting to decode the instruction.

Are you allowing for the REX prefix at all?
The encoding of:
> > > +      *   cmpl    <id>, -6(%reg)     ; 7 bytes
is
	<opcode><mod/TTT/rm><off8><imm32>
which is 7 bytes without the REX.
If reg is r11 there is an extra REX byte - for 8 in total.

Without the REX byte the decode will be using %bx.
So the testing should all have failed.
Which means that something else is wrong as well.

	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] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
  2022-05-16 22:59           ` Kees Cook
@ 2022-05-17  8:05             ` Peter Zijlstra
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Zijlstra @ 2022-05-17  8:05 UTC (permalink / raw)
  To: Kees Cook
  Cc: Sami Tolvanen, linux-kernel, Josh Poimboeuf, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Mon, May 16, 2022 at 03:59:41PM -0700, Kees Cook wrote:

> I'm still not convinced about this, but I'm on the fence.
> 
> Cons:
> - FineIBT does callee-based hash verification, which means any
>   attacker-constructed memory region just has to have an endbr and nops at
>   "shellcode - 9". KCFI would need the region to have the hash at
>   "shellcode - 6" and an endbr at "shellcode". However, that hash is well
>   known, so it's not much protection.

How would you get the ENDBR there anyway? If you can write code it's
game over.

> - Potential performance hit due to making an additional "call" outside
>   the cache lines of both caller and callee.

That was all an effort to shrink and simplify, all this CFI stuff is
massive bloat :/

If we use %eax instead of %r10d for the hash transfer (as per Joao), and
use int3 instead of ud2, then we can shrink the fineibt sequence to:

__cfi_\func:
	endbr				# 4
	xorl	$0x12345678, %eax	# 5
	jz	1f			# 2
	int3				# 1
\func:
	...

Which is 12 bytes, and needs a larger preamble (up from 9 in the current
proposal).

If we do the objtool/linker fixup, such that direct calls/jumps will
*never* hit ENDBR, then we can do something ugly like:

	kCFI			FineIBT

__cfi_\func:			__cfi_\func:
	int3				endbr
	movl $0x12345678, %rax		xorl $0x12345678, %eax
	int3				jz   1f
	int3				int3
\func:
	endbr
__direct_\func:			__direct_\func:
	...				...

which is 12 bytes on both sides and shrinks the preaamble to 8 bytes
while additionally also supporting kCFI+IBT for those few people that
don't care about speculation based attacks much.

But now it's complicated again and requires significant tools work :/
(also, using int3 isn't ideal).

> Pros:
> - FineIBT can be done without read access to the kernel text, which will
>   be nice in the exec-only future.

  - Mostly kills SpectreBHB (because it has the hash check *after*
    ENDBR).

So were IBT limits speculation to all sites that have ENDBR, you can
still target any of them. With FineIBT you loose all sites that don't
match on hash value, significantly reducing the options.

> I'd kind of like the "dynamic FineIBT conversion" to be a config option,
> at least at first. We could at least do performance comparisons between
> them.

Why would you need a config option for that? Since it is dynamic anyway
a boot option works fine.


Also, regardless of all this, it probably makes sense to add an LTO pass
to remove all unused __cfi_ symbols and endbr instructions, less viable
targets is more better :-)

I've been doing that with objtool for the IBT builds.

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
@ 2022-05-17  8:05             ` Peter Zijlstra
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Zijlstra @ 2022-05-17  8:05 UTC (permalink / raw)
  To: Kees Cook
  Cc: Sami Tolvanen, linux-kernel, Josh Poimboeuf, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Mon, May 16, 2022 at 03:59:41PM -0700, Kees Cook wrote:

> I'm still not convinced about this, but I'm on the fence.
> 
> Cons:
> - FineIBT does callee-based hash verification, which means any
>   attacker-constructed memory region just has to have an endbr and nops at
>   "shellcode - 9". KCFI would need the region to have the hash at
>   "shellcode - 6" and an endbr at "shellcode". However, that hash is well
>   known, so it's not much protection.

How would you get the ENDBR there anyway? If you can write code it's
game over.

> - Potential performance hit due to making an additional "call" outside
>   the cache lines of both caller and callee.

That was all an effort to shrink and simplify, all this CFI stuff is
massive bloat :/

If we use %eax instead of %r10d for the hash transfer (as per Joao), and
use int3 instead of ud2, then we can shrink the fineibt sequence to:

__cfi_\func:
	endbr				# 4
	xorl	$0x12345678, %eax	# 5
	jz	1f			# 2
	int3				# 1
\func:
	...

Which is 12 bytes, and needs a larger preamble (up from 9 in the current
proposal).

If we do the objtool/linker fixup, such that direct calls/jumps will
*never* hit ENDBR, then we can do something ugly like:

	kCFI			FineIBT

__cfi_\func:			__cfi_\func:
	int3				endbr
	movl $0x12345678, %rax		xorl $0x12345678, %eax
	int3				jz   1f
	int3				int3
\func:
	endbr
__direct_\func:			__direct_\func:
	...				...

which is 12 bytes on both sides and shrinks the preaamble to 8 bytes
while additionally also supporting kCFI+IBT for those few people that
don't care about speculation based attacks much.

But now it's complicated again and requires significant tools work :/
(also, using int3 isn't ideal).

> Pros:
> - FineIBT can be done without read access to the kernel text, which will
>   be nice in the exec-only future.

  - Mostly kills SpectreBHB (because it has the hash check *after*
    ENDBR).

So were IBT limits speculation to all sites that have ENDBR, you can
still target any of them. With FineIBT you loose all sites that don't
match on hash value, significantly reducing the options.

> I'd kind of like the "dynamic FineIBT conversion" to be a config option,
> at least at first. We could at least do performance comparisons between
> them.

Why would you need a config option for that? Since it is dynamic anyway
a boot option works fine.


Also, regardless of all this, it probably makes sense to add an LTO pass
to remove all unused __cfi_ symbols and endbr instructions, less viable
targets is more better :-)

I've been doing that with objtool for the IBT builds.

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
  2022-05-17  8:05             ` Peter Zijlstra
@ 2022-05-17  8:32               ` Joao Moreira
  -1 siblings, 0 replies; 174+ messages in thread
From: Joao Moreira @ 2022-05-17  8:32 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Kees Cook, Sami Tolvanen, linux-kernel, Josh Poimboeuf, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

>> Cons:
>> - FineIBT does callee-based hash verification, which means any
>>   attacker-constructed memory region just has to have an endbr and 
>> nops at
>>   "shellcode - 9". KCFI would need the region to have the hash at
>>   "shellcode - 6" and an endbr at "shellcode". However, that hash is 
>> well
>>   known, so it's not much protection.
> 
> How would you get the ENDBR there anyway? If you can write code it's
> game over.
> 
+1 here. If you can't keep W^X, both approaches are equally doomed.

Yet, there is a relevant detail here. ENDBR has a pre-defined/fixed 
opcode, which means that it is predictable from the binary perspective. 
Because of that, compilers already do security optimizations and prevent 
for example the emission of ENDBR's opcode as immediate operands. This 
very same approach can be used by JIT stuff, preventing ENDBRs to be 
emitted as unintended gadgets. Because KCFI hashes aren't predictable, 
you can't (or at least I can't think of a way to) prevent these from 
being emitted as operands, which means that if you have an IBT-able 
machine, you will want to enable it even if you have KCFI.

With this said, the instrumentation for KCFI on IBT-enabled machines 
should be of at least 9 bytes (5 for the hash/mov and 4 for ENDBR, not 
counting the additional 4 bytes we asked for).

>> - Potential performance hit due to making an additional "call" outside
>>   the cache lines of both caller and callee.
> 
> That was all an effort to shrink and simplify, all this CFI stuff is
> massive bloat :/
> 
> If we use %eax instead of %r10d for the hash transfer (as per Joao), 
> and
> use int3 instead of ud2, then we can shrink the fineibt sequence to:
> 
> __cfi_\func:
> 	endbr				# 4
> 	xorl	$0x12345678, %eax	# 5
> 	jz	1f			# 2
> 	int3				# 1
> \func:
> 	...
> 
> Which is 12 bytes, and needs a larger preamble (up from 9 in the 
> current
> proposal).

As per the above-analysis, if we can make FineIBT instrumentation fit in 
12 bytes, this means that the 9 bytes required for KCFI+IBT plus three 
bytes would suffice for having FineIBT (again, if we can make it fit). 
And this would make that call go away.

> 
> If we do the objtool/linker fixup, such that direct calls/jumps will
> *never* hit ENDBR, then we can do something ugly like:
> 
> 	kCFI			FineIBT
> 
> __cfi_\func:			__cfi_\func:
> 	int3				endbr
> 	movl $0x12345678, %rax		xorl $0x12345678, %eax
> 	int3				jz   1f
> 	int3				int3
> \func:
> 	endbr
> __direct_\func:			__direct_\func:
> 	...				...
> 
> which is 12 bytes on both sides and shrinks the preaamble to 8 bytes
> while additionally also supporting kCFI+IBT for those few people that
> don't care about speculation based attacks much.
> 
> But now it's complicated again and requires significant tools work :/
> (also, using int3 isn't ideal).
> 
>> Pros:
>> - FineIBT can be done without read access to the kernel text, which 
>> will
>>   be nice in the exec-only future.
> 
>   - Mostly kills SpectreBHB (because it has the hash check *after*
>     ENDBR).

- Callee-side checks allow you to make an specific function 
coarse-grained without making an indirect call instruction 
coarse-grained. I.e: If you have a binary blob or some function that for 
whatever reason can't have a hash, you just disable the check in this 
function, making it reachable by every indirect call in the binary but 
being reasonably able to measure the risks behind it. If you make an 
indirect call coarse-grained, this means that now this indirect call can 
reach all functions in the binary, including functions like 
"disable_cet" and "disable_super_nice_security_feature". The risk 
impacts of these latter relaxations are much harder to measure, imho 
(yet, I would enjoy hearing counter-arguments, if any).

> 
> So were IBT limits speculation to all sites that have ENDBR, you can
> still target any of them. With FineIBT you loose all sites that don't
> match on hash value, significantly reducing the options.
> 
>> I'd kind of like the "dynamic FineIBT conversion" to be a config 
>> option,
>> at least at first. We could at least do performance comparisons 
>> between
>> them.
> 
> Why would you need a config option for that? Since it is dynamic anyway
> a boot option works fine.
> 
> 
> Also, regardless of all this, it probably makes sense to add an LTO 
> pass
> to remove all unused __cfi_ symbols and endbr instructions, less viable
> targets is more better :-)

We have that for IBT in clang already (I implemented and upstreamed it 
back when you were trying ibt-seal in objtool). I did not find the time 
to test it with the final IBT support but it is in my todo list to take 
a look and perhaps send a RFC here. FWIIW, 
https://reviews.llvm.org/D116070

> 
> I've been doing that with objtool for the IBT builds.

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
@ 2022-05-17  8:32               ` Joao Moreira
  0 siblings, 0 replies; 174+ messages in thread
From: Joao Moreira @ 2022-05-17  8:32 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Kees Cook, Sami Tolvanen, linux-kernel, Josh Poimboeuf, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

>> Cons:
>> - FineIBT does callee-based hash verification, which means any
>>   attacker-constructed memory region just has to have an endbr and 
>> nops at
>>   "shellcode - 9". KCFI would need the region to have the hash at
>>   "shellcode - 6" and an endbr at "shellcode". However, that hash is 
>> well
>>   known, so it's not much protection.
> 
> How would you get the ENDBR there anyway? If you can write code it's
> game over.
> 
+1 here. If you can't keep W^X, both approaches are equally doomed.

Yet, there is a relevant detail here. ENDBR has a pre-defined/fixed 
opcode, which means that it is predictable from the binary perspective. 
Because of that, compilers already do security optimizations and prevent 
for example the emission of ENDBR's opcode as immediate operands. This 
very same approach can be used by JIT stuff, preventing ENDBRs to be 
emitted as unintended gadgets. Because KCFI hashes aren't predictable, 
you can't (or at least I can't think of a way to) prevent these from 
being emitted as operands, which means that if you have an IBT-able 
machine, you will want to enable it even if you have KCFI.

With this said, the instrumentation for KCFI on IBT-enabled machines 
should be of at least 9 bytes (5 for the hash/mov and 4 for ENDBR, not 
counting the additional 4 bytes we asked for).

>> - Potential performance hit due to making an additional "call" outside
>>   the cache lines of both caller and callee.
> 
> That was all an effort to shrink and simplify, all this CFI stuff is
> massive bloat :/
> 
> If we use %eax instead of %r10d for the hash transfer (as per Joao), 
> and
> use int3 instead of ud2, then we can shrink the fineibt sequence to:
> 
> __cfi_\func:
> 	endbr				# 4
> 	xorl	$0x12345678, %eax	# 5
> 	jz	1f			# 2
> 	int3				# 1
> \func:
> 	...
> 
> Which is 12 bytes, and needs a larger preamble (up from 9 in the 
> current
> proposal).

As per the above-analysis, if we can make FineIBT instrumentation fit in 
12 bytes, this means that the 9 bytes required for KCFI+IBT plus three 
bytes would suffice for having FineIBT (again, if we can make it fit). 
And this would make that call go away.

> 
> If we do the objtool/linker fixup, such that direct calls/jumps will
> *never* hit ENDBR, then we can do something ugly like:
> 
> 	kCFI			FineIBT
> 
> __cfi_\func:			__cfi_\func:
> 	int3				endbr
> 	movl $0x12345678, %rax		xorl $0x12345678, %eax
> 	int3				jz   1f
> 	int3				int3
> \func:
> 	endbr
> __direct_\func:			__direct_\func:
> 	...				...
> 
> which is 12 bytes on both sides and shrinks the preaamble to 8 bytes
> while additionally also supporting kCFI+IBT for those few people that
> don't care about speculation based attacks much.
> 
> But now it's complicated again and requires significant tools work :/
> (also, using int3 isn't ideal).
> 
>> Pros:
>> - FineIBT can be done without read access to the kernel text, which 
>> will
>>   be nice in the exec-only future.
> 
>   - Mostly kills SpectreBHB (because it has the hash check *after*
>     ENDBR).

- Callee-side checks allow you to make an specific function 
coarse-grained without making an indirect call instruction 
coarse-grained. I.e: If you have a binary blob or some function that for 
whatever reason can't have a hash, you just disable the check in this 
function, making it reachable by every indirect call in the binary but 
being reasonably able to measure the risks behind it. If you make an 
indirect call coarse-grained, this means that now this indirect call can 
reach all functions in the binary, including functions like 
"disable_cet" and "disable_super_nice_security_feature". The risk 
impacts of these latter relaxations are much harder to measure, imho 
(yet, I would enjoy hearing counter-arguments, if any).

> 
> So were IBT limits speculation to all sites that have ENDBR, you can
> still target any of them. With FineIBT you loose all sites that don't
> match on hash value, significantly reducing the options.
> 
>> I'd kind of like the "dynamic FineIBT conversion" to be a config 
>> option,
>> at least at first. We could at least do performance comparisons 
>> between
>> them.
> 
> Why would you need a config option for that? Since it is dynamic anyway
> a boot option works fine.
> 
> 
> Also, regardless of all this, it probably makes sense to add an LTO 
> pass
> to remove all unused __cfi_ symbols and endbr instructions, less viable
> targets is more better :-)

We have that for IBT in clang already (I implemented and upstreamed it 
back when you were trying ibt-seal in objtool). I did not find the time 
to test it with the final IBT support but it is in my todo list to take 
a look and perhaps send a RFC here. FWIIW, 
https://reviews.llvm.org/D116070

> 
> I've been doing that with objtool for the IBT builds.

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
  2022-05-17  8:05             ` Peter Zijlstra
@ 2022-05-17  8:40               ` Peter Zijlstra
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Zijlstra @ 2022-05-17  8:40 UTC (permalink / raw)
  To: Kees Cook
  Cc: Sami Tolvanen, linux-kernel, Josh Poimboeuf, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Tue, May 17, 2022 at 10:05:17AM +0200, Peter Zijlstra wrote:
> On Mon, May 16, 2022 at 03:59:41PM -0700, Kees Cook wrote:
> 
> > I'm still not convinced about this, but I'm on the fence.
> > 
> > Cons:
> > - FineIBT does callee-based hash verification, which means any
> >   attacker-constructed memory region just has to have an endbr and nops at
> >   "shellcode - 9". KCFI would need the region to have the hash at
> >   "shellcode - 6" and an endbr at "shellcode". However, that hash is well
> >   known, so it's not much protection.
> 
> How would you get the ENDBR there anyway? If you can write code it's
> game over.
> 
> > - Potential performance hit due to making an additional "call" outside
> >   the cache lines of both caller and callee.
> 
> That was all an effort to shrink and simplify, all this CFI stuff is
> massive bloat :/
> 
> If we use %eax instead of %r10d for the hash transfer (as per Joao), and
> use int3 instead of ud2, then we can shrink the fineibt sequence to:
> 
> __cfi_\func:
> 	endbr				# 4
> 	xorl	$0x12345678, %eax	# 5
> 	jz	1f			# 2
> 	int3				# 1
> \func:
> 	...
> 
> Which is 12 bytes, and needs a larger preamble (up from 9 in the current
> proposal).

On all that; perhaps it would be good to have a compiler option to
specify the preamble size. It can enforce the minimum at 7 to have at
least the required:

	movl $0x12345678, %eax
	int3
	int3

but any larger number will just increase the preamble with int3 padding
at the top.

That can go right along with the option to supress endbr when preamble
:-)

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
@ 2022-05-17  8:40               ` Peter Zijlstra
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Zijlstra @ 2022-05-17  8:40 UTC (permalink / raw)
  To: Kees Cook
  Cc: Sami Tolvanen, linux-kernel, Josh Poimboeuf, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Tue, May 17, 2022 at 10:05:17AM +0200, Peter Zijlstra wrote:
> On Mon, May 16, 2022 at 03:59:41PM -0700, Kees Cook wrote:
> 
> > I'm still not convinced about this, but I'm on the fence.
> > 
> > Cons:
> > - FineIBT does callee-based hash verification, which means any
> >   attacker-constructed memory region just has to have an endbr and nops at
> >   "shellcode - 9". KCFI would need the region to have the hash at
> >   "shellcode - 6" and an endbr at "shellcode". However, that hash is well
> >   known, so it's not much protection.
> 
> How would you get the ENDBR there anyway? If you can write code it's
> game over.
> 
> > - Potential performance hit due to making an additional "call" outside
> >   the cache lines of both caller and callee.
> 
> That was all an effort to shrink and simplify, all this CFI stuff is
> massive bloat :/
> 
> If we use %eax instead of %r10d for the hash transfer (as per Joao), and
> use int3 instead of ud2, then we can shrink the fineibt sequence to:
> 
> __cfi_\func:
> 	endbr				# 4
> 	xorl	$0x12345678, %eax	# 5
> 	jz	1f			# 2
> 	int3				# 1
> \func:
> 	...
> 
> Which is 12 bytes, and needs a larger preamble (up from 9 in the current
> proposal).

On all that; perhaps it would be good to have a compiler option to
specify the preamble size. It can enforce the minimum at 7 to have at
least the required:

	movl $0x12345678, %eax
	int3
	int3

but any larger number will just increase the preamble with int3 padding
at the top.

That can go right along with the option to supress endbr when preamble
:-)

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 08/21] psci: Fix the function type for psci_initcall_t
  2022-05-13 20:21   ` Sami Tolvanen
@ 2022-05-17  8:47     ` Mark Rutland
  -1 siblings, 0 replies; 174+ messages in thread
From: Mark Rutland @ 2022-05-17  8:47 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:46PM -0700, Sami Tolvanen wrote:
> Functions called through a psci_initcall_t pointer all have
> non-const arguments. Fix the type definition to avoid tripping
> indirect call checks with CFI_CLANG.
> 
> Reported-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

I'd prefer that we spread the `const` to each of the implementations rather
than dropping it from the type.

I have a local patch for that I can send out shortly.

Thanks,
Mark.

> ---
>  drivers/firmware/psci/psci.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index cfb448eabdaa..6554bf4b8c99 100644
> --- a/drivers/firmware/psci/psci.c
> +++ b/drivers/firmware/psci/psci.c
> @@ -521,7 +521,7 @@ static int __init psci_probe(void)
>  	return 0;
>  }
>  
> -typedef int (*psci_initcall_t)(const struct device_node *);
> +typedef int (*psci_initcall_t)(struct device_node *);
>  
>  /*
>   * PSCI init function for PSCI versions >=0.2
> -- 
> 2.36.0.550.gb090851708-goog
> 

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 08/21] psci: Fix the function type for psci_initcall_t
@ 2022-05-17  8:47     ` Mark Rutland
  0 siblings, 0 replies; 174+ messages in thread
From: Mark Rutland @ 2022-05-17  8:47 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Kees Cook, Josh Poimboeuf, Peter Zijlstra, x86,
	Catalin Marinas, Will Deacon, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:46PM -0700, Sami Tolvanen wrote:
> Functions called through a psci_initcall_t pointer all have
> non-const arguments. Fix the type definition to avoid tripping
> indirect call checks with CFI_CLANG.
> 
> Reported-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

I'd prefer that we spread the `const` to each of the implementations rather
than dropping it from the type.

I have a local patch for that I can send out shortly.

Thanks,
Mark.

> ---
>  drivers/firmware/psci/psci.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index cfb448eabdaa..6554bf4b8c99 100644
> --- a/drivers/firmware/psci/psci.c
> +++ b/drivers/firmware/psci/psci.c
> @@ -521,7 +521,7 @@ static int __init psci_probe(void)
>  	return 0;
>  }
>  
> -typedef int (*psci_initcall_t)(const struct device_node *);
> +typedef int (*psci_initcall_t)(struct device_node *);
>  
>  /*
>   * PSCI init function for PSCI versions >=0.2
> -- 
> 2.36.0.550.gb090851708-goog
> 

_______________________________________________
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] 174+ messages in thread

* RE: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
  2022-05-17  8:40               ` Peter Zijlstra
@ 2022-05-17  8:48                 ` David Laight
  -1 siblings, 0 replies; 174+ messages in thread
From: David Laight @ 2022-05-17  8:48 UTC (permalink / raw)
  To: 'Peter Zijlstra', Kees Cook
  Cc: Sami Tolvanen, linux-kernel, Josh Poimboeuf, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

From: Peter Zijlstra
> Sent: 17 May 2022 09:41
...
> > If we use %eax instead of %r10d for the hash transfer (as per Joao), and
> > use int3 instead of ud2, then we can shrink the fineibt sequence to:
> >
> > __cfi_\func:
> > 	endbr				# 4
> > 	xorl	$0x12345678, %eax	# 5
> > 	jz	1f			# 2
> > 	int3				# 1
> > \func:
> > 	...
> >
> > Which is 12 bytes, and needs a larger preamble (up from 9 in the current
> > proposal).
> 
> On all that; perhaps it would be good to have a compiler option to
> specify the preamble size. It can enforce the minimum at 7 to have at
> least the required:
> 
> 	movl $0x12345678, %eax
> 	int3
> 	int3
> 
> but any larger number will just increase the preamble with int3 padding
> at the top.
> 
> That can go right along with the option to supress endbr when preamble
> :-)

You also need a compiler option to specify the register.
While (I think) %eax is usable in kernel, it isn't in userspace.
It is used in varargs calls to pass (IIRC) the number of fp
args that are passed in registers.

(I can't remember which registers userspace has reserved for
the PLT code? - That might include r10??)

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


^ permalink raw reply	[flat|nested] 174+ messages in thread

* RE: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
@ 2022-05-17  8:48                 ` David Laight
  0 siblings, 0 replies; 174+ messages in thread
From: David Laight @ 2022-05-17  8:48 UTC (permalink / raw)
  To: 'Peter Zijlstra', Kees Cook
  Cc: Sami Tolvanen, linux-kernel, Josh Poimboeuf, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

From: Peter Zijlstra
> Sent: 17 May 2022 09:41
...
> > If we use %eax instead of %r10d for the hash transfer (as per Joao), and
> > use int3 instead of ud2, then we can shrink the fineibt sequence to:
> >
> > __cfi_\func:
> > 	endbr				# 4
> > 	xorl	$0x12345678, %eax	# 5
> > 	jz	1f			# 2
> > 	int3				# 1
> > \func:
> > 	...
> >
> > Which is 12 bytes, and needs a larger preamble (up from 9 in the current
> > proposal).
> 
> On all that; perhaps it would be good to have a compiler option to
> specify the preamble size. It can enforce the minimum at 7 to have at
> least the required:
> 
> 	movl $0x12345678, %eax
> 	int3
> 	int3
> 
> but any larger number will just increase the preamble with int3 padding
> at the top.
> 
> That can go right along with the option to supress endbr when preamble
> :-)

You also need a compiler option to specify the register.
While (I think) %eax is usable in kernel, it isn't in userspace.
It is used in varargs calls to pass (IIRC) the number of fp
args that are passed in registers.

(I can't remember which registers userspace has reserved for
the PLT code? - That might include r10??)

	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] 174+ messages in thread

* Re: [RFC PATCH v2 00/21] KCFI support
  2022-05-13 20:21 ` Sami Tolvanen
@ 2022-05-17  8:57   ` Peter Zijlstra
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Zijlstra @ 2022-05-17  8:57 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Kees Cook, Josh Poimboeuf, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:38PM -0700, Sami Tolvanen wrote:
> KCFI is a proposed forward-edge control-flow integrity scheme for
> Clang, which is more suitable for kernel use than the existing CFI
> scheme used by CONFIG_CFI_CLANG. KCFI doesn't require LTO, doesn't
> alter function references to point to a jump table, and won't break
> function address equality. The latest LLVM patch is here:
> 
>   https://reviews.llvm.org/D119296
> 
> This RFC series replaces the current arm64 CFI implementation with
> KCFI and adds support for x86_64.

You have some weird behaviour vs weak functions (I so hate those)...

100: 0000000000000980     9 FUNC    LOCAL  DEFAULT    2 __cfi_free_initmem
233: 0000000000000989    35 FUNC    WEAK   DEFAULT    2 free_initmem

With the result that on the final link:

   179: 00000000000009b0     9 FUNC    LOCAL  DEFAULT    1 __cfi_free_initmem
  8689: 00000000000007f0     9 FUNC    LOCAL  DEFAULT   65 __cfi_free_initmem
173283: 00000000000007f9   198 FUNC    GLOBAL DEFAULT   65 free_initmem

This is getting me objtool issues (I'll fix them) but perhaps it's
something you can do something about as well.

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 00/21] KCFI support
@ 2022-05-17  8:57   ` Peter Zijlstra
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Zijlstra @ 2022-05-17  8:57 UTC (permalink / raw)
  To: Sami Tolvanen
  Cc: linux-kernel, Kees Cook, Josh Poimboeuf, x86, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Fri, May 13, 2022 at 01:21:38PM -0700, Sami Tolvanen wrote:
> KCFI is a proposed forward-edge control-flow integrity scheme for
> Clang, which is more suitable for kernel use than the existing CFI
> scheme used by CONFIG_CFI_CLANG. KCFI doesn't require LTO, doesn't
> alter function references to point to a jump table, and won't break
> function address equality. The latest LLVM patch is here:
> 
>   https://reviews.llvm.org/D119296
> 
> This RFC series replaces the current arm64 CFI implementation with
> KCFI and adds support for x86_64.

You have some weird behaviour vs weak functions (I so hate those)...

100: 0000000000000980     9 FUNC    LOCAL  DEFAULT    2 __cfi_free_initmem
233: 0000000000000989    35 FUNC    WEAK   DEFAULT    2 free_initmem

With the result that on the final link:

   179: 00000000000009b0     9 FUNC    LOCAL  DEFAULT    1 __cfi_free_initmem
  8689: 00000000000007f0     9 FUNC    LOCAL  DEFAULT   65 __cfi_free_initmem
173283: 00000000000007f9   198 FUNC    GLOBAL DEFAULT   65 free_initmem

This is getting me objtool issues (I'll fix them) but perhaps it's
something you can do something about as well.

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
  2022-05-17  8:48                 ` David Laight
@ 2022-05-17  9:38                   ` Peter Zijlstra
  -1 siblings, 0 replies; 174+ messages in thread
From: Peter Zijlstra @ 2022-05-17  9:38 UTC (permalink / raw)
  To: David Laight
  Cc: Kees Cook, Sami Tolvanen, linux-kernel, Josh Poimboeuf, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Tue, May 17, 2022 at 08:48:41AM +0000, David Laight wrote:
> From: Peter Zijlstra
> > Sent: 17 May 2022 09:41
> ...
> > > If we use %eax instead of %r10d for the hash transfer (as per Joao), and
> > > use int3 instead of ud2, then we can shrink the fineibt sequence to:
> > >
> > > __cfi_\func:
> > > 	endbr				# 4
> > > 	xorl	$0x12345678, %eax	# 5
> > > 	jz	1f			# 2
> > > 	int3				# 1
> > > \func:
> > > 	...
> > >
> > > Which is 12 bytes, and needs a larger preamble (up from 9 in the current
> > > proposal).
> > 
> > On all that; perhaps it would be good to have a compiler option to
> > specify the preamble size. It can enforce the minimum at 7 to have at
> > least the required:
> > 
> > 	movl $0x12345678, %eax
> > 	int3
> > 	int3
> > 
> > but any larger number will just increase the preamble with int3 padding
> > at the top.
> > 
> > That can go right along with the option to supress endbr when preamble
> > :-)
> 
> You also need a compiler option to specify the register.
> While (I think) %eax is usable in kernel, it isn't in userspace.
> It is used in varargs calls to pass (IIRC) the number of fp
> args that are passed in registers.

You're mistaken, the compiler doesn't emit the FineIBT code *at*all*.
That's all patched in later. For kCFI the mov is never executed and is
only there to make it a valid instruction.

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
@ 2022-05-17  9:38                   ` Peter Zijlstra
  0 siblings, 0 replies; 174+ messages in thread
From: Peter Zijlstra @ 2022-05-17  9:38 UTC (permalink / raw)
  To: David Laight
  Cc: Kees Cook, Sami Tolvanen, linux-kernel, Josh Poimboeuf, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Tue, May 17, 2022 at 08:48:41AM +0000, David Laight wrote:
> From: Peter Zijlstra
> > Sent: 17 May 2022 09:41
> ...
> > > If we use %eax instead of %r10d for the hash transfer (as per Joao), and
> > > use int3 instead of ud2, then we can shrink the fineibt sequence to:
> > >
> > > __cfi_\func:
> > > 	endbr				# 4
> > > 	xorl	$0x12345678, %eax	# 5
> > > 	jz	1f			# 2
> > > 	int3				# 1
> > > \func:
> > > 	...
> > >
> > > Which is 12 bytes, and needs a larger preamble (up from 9 in the current
> > > proposal).
> > 
> > On all that; perhaps it would be good to have a compiler option to
> > specify the preamble size. It can enforce the minimum at 7 to have at
> > least the required:
> > 
> > 	movl $0x12345678, %eax
> > 	int3
> > 	int3
> > 
> > but any larger number will just increase the preamble with int3 padding
> > at the top.
> > 
> > That can go right along with the option to supress endbr when preamble
> > :-)
> 
> You also need a compiler option to specify the register.
> While (I think) %eax is usable in kernel, it isn't in userspace.
> It is used in varargs calls to pass (IIRC) the number of fp
> args that are passed in registers.

You're mistaken, the compiler doesn't emit the FineIBT code *at*all*.
That's all patched in later. For kCFI the mov is never executed and is
only there to make it a valid instruction.

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 00/21] KCFI support
  2022-05-17  7:33       ` Sedat Dilek
@ 2022-05-17 18:49         ` Nathan Chancellor
  -1 siblings, 0 replies; 174+ messages in thread
From: Nathan Chancellor @ 2022-05-17 18:49 UTC (permalink / raw)
  To: Sedat Dilek
  Cc: Sami Tolvanen, linux-kernel, Kees Cook, Josh Poimboeuf,
	Peter Zijlstra, x86, Catalin Marinas, Will Deacon, Mark Rutland,
	Nick Desaulniers, Joao Moreira, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Tue, May 17, 2022 at 09:33:47AM +0200, Sedat Dilek wrote:
> Is your tags/kcfi-rfc-v2 the recommended LLVM toolchain for testing kcfi-rfc-v2?
> 
> What I want to ask is if your commit well tested for x86 (and arm64)
> means build and boot on bare metal?

I have run kCFI (v1, I haven't had time to test v2) on x86_64 hardware,
both AMD and Intel. I have only found two failures so far: the i915
issue that I mention below and a failure in the KVM subsystem, which I
can see by just running QEMU:

[  124.344654] CFI failure at kvm_mmu_notifier_invalidate_range_end+0xca/0x177 [kvm] (target: kvm_null_fn+0x0/0x7 [kvm]; expected type: 0x1e2c5b9c)
[  124.344691] WARNING: CPU: 5 PID: 2767 at kvm_mmu_notifier_invalidate_range_end+0xca/0x177 [kvm]
[  124.344708] Modules linked in: ...
[  124.344737] CPU: 5 PID: 2767 Comm: qemu-system-x86 Tainted: P                  5.18.0-rc6-debug-00033-g1d5284aff7cd #1 8c4966c7fb24f3345076747feebac5fb340a4797
[  124.344738] Hardware name: ASUS System Product Name/PRIME Z590M-PLUS, BIOS 1203 10/27/2021
[  124.344738] RIP: 0010:kvm_mmu_notifier_invalidate_range_end+0xca/0x177 [kvm]
[  124.344756] Code: 48 89 da e8 88 16 86 dd 48 85 c0 89 6c 24 0c 74 30 4d 85 f6 74 36 48 c7 c5 19 c8 b4 c0 4c 8b 34 24 81 7d fa 9c 5b 2c 1e 74 02 <0f> 0b 48 89 c7 4c 89 fe 48 89 da e8 b6 16 86 dd 48 85 c0 75 e2 eb
[  124.344757] RSP: 0018:ffffc033039d78e8 EFLAGS: 00010282
[  124.344758] RAX: ffffa0a141ed9450 RBX: 00007fb897e9efff RCX: ffffa0a143c9d850
[  124.344758] RDX: 00007fb897e9efff RSI: 00007fb897e9e000 RDI: ffffc03304499cf8
[  124.344759] RBP: ffffffffc0b4c819 R08: 0000000000000000 R09: 0000000000000000
[  124.344759] R10: 0000000000000000 R11: ffffffffc0b4c639 R12: ffffc03304499000
[  124.344760] R13: ffffc033044a30a0 R14: ffffc033044a3120 R15: 00007fb897e9e000
[  124.344760] FS:  00007fbca4bc3640(0000) GS:ffffa0a87f540000(0000) knlGS:0000000000000000
[  124.344761] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  124.344761] CR2: 0000000000000000 CR3: 0000000119f74006 CR4: 0000000000772ee0
[  124.344762] PKRU: 55555554
[  124.344762] Call Trace:
[  124.344762]  <TASK>
[  124.344763]  __mmu_notifier_invalidate_range_end+0xa1/0xd7
[  124.344764]  wp_page_copy+0x592/0x920
[  124.344766]  __handle_mm_fault+0x820/0x8f0
[  124.344767]  handle_mm_fault+0xe0/0x227
[  124.344768]  __get_user_pages+0x17a/0x430
[  124.344769]  get_user_pages_unlocked+0xd9/0x327
[  124.344770]  hva_to_pfn+0xfa/0x3f7 [kvm 950e483805e01f967a3e331506278d766494a4cc]
[  124.344788]  kvm_faultin_pfn+0xc3/0x2f0 [kvm 950e483805e01f967a3e331506278d766494a4cc]
[  124.344806]  ? fast_page_fault+0x400/0x4c0 [kvm 950e483805e01f967a3e331506278d766494a4cc]
[  124.344823]  direct_page_fault+0x130/0x350 [kvm 950e483805e01f967a3e331506278d766494a4cc]
[  124.344841]  kvm_mmu_page_fault+0x176/0x2f7 [kvm 950e483805e01f967a3e331506278d766494a4cc]
[  124.344858]  vmx_handle_exit+0xe/0x37 [kvm_intel 647f514f18fc365045dc57db46d2bb4930b746eb]
[  124.344863]  vcpu_enter_guest+0xbff/0x1030 [kvm 950e483805e01f967a3e331506278d766494a4cc]
[  124.344881]  vcpu_run+0x65/0x2f0 [kvm 950e483805e01f967a3e331506278d766494a4cc]
[  124.344898]  kvm_arch_vcpu_ioctl_run+0x15f/0x3f7 [kvm 950e483805e01f967a3e331506278d766494a4cc]
[  124.344916]  kvm_vcpu_ioctl+0x547/0x627 [kvm 950e483805e01f967a3e331506278d766494a4cc]
[  124.344933]  ? syscall_exit_to_user_mode+0x24/0x47
[  124.344934]  ? do_syscall_64+0x7a/0x97
[  124.344935]  ? __fget_files+0xa1/0xc0
[  124.344936]  __se_sys_ioctl+0x7c/0xc0
[  124.344937]  do_syscall_64+0x6c/0x97
[  124.344938]  ? do_syscall_64+0x7a/0x97
[  124.344939]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[  124.344940] RIP: 0033:0x7fbca75f7b1f
[  124.344940] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00
[  124.344941] RSP: 002b:00007fbca4bc2550 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[  124.344942] RAX: ffffffffffffffda RBX: 000000000000ae80 RCX: 00007fbca75f7b1f
[  124.344942] RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 000000000000000e
[  124.344943] RBP: 000056351ba661d0 R08: 000056351a74dc48 R09: 0000000000000004
[  124.344943] R10: 004818cf4f129e11 R11: 0000000000000246 R12: 0000000000000000
[  124.344943] R13: 0000000000000000 R14: 00007fbca814f004 R15: 0000000000000000
[  124.344944]  </TASK>
[  124.344945] ---[ end trace 0000000000000000 ]---

I don't do any bare metal testing for the tc-build known good revision
bumps, just QEMU tests with boot-utils.

> Just for the records:
> You definitely need a pre-LLVM-15 toolchain + KCFI sanitizer patch?
> LLVM-14?

The feature won't land in LLVM 14, so there is little point to
backporting and testing it on LLVM 14. This is a work in progress
feature so it has to target the main branch. I have fairly good coverage
of tip of tree locally and we have solid coverage through CI so we'll
know if something major happens, it should be pretty safe to test Sami's
series.

> > > Nathan has a i915 cfi patch in His personal kernel.org Git.
> > > Is this relevant to kcfi?
> >
> > It fixes a type mismatch, so in that sense it's relevant.
> >
> 
> Here the link to patch "drm/i915: Fix CFI violation with show_dynamic_id()":
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/nathan/linux.git/commit/?h=submitted/i915-cfi-fix&id=53735be6dc53453fcfbac658e847b54360e73871

This is now in the i915 tree so that branch is going to disappear:

https://cgit.freedesktop.org/drm/drm-intel/commit/?id=18fb42db05a0b93ab5dd5eab5315e50eaa3ca620

> You say no need to build your kernel with LTO...
> That sounds good.
> Currently, I build my kernels with Clang-14 and CONFIG_LTO_CLANG_THIN=y.
> Does something speak against using CONFIG_LTO_CLANG_THIN=y with KCFI support?
> Build-time?
> Disc-usage?

I wouldn't expect the build time or disk usage to significantly increase
with kCFI. I ran a quick benchmark with Arch Linux's configuration with
ThinLTO then ThinLTO + kCFI on an AMD EPYC 7513:

Benchmark 1: ThinLTO
  Time (abs ≡):        166.036 s               [User: 4687.951 s, System: 1636.767 s]

Benchmark 2: ThinLTO + kCFI
  Time (abs ≡):        168.739 s               [User: 4682.020 s, System: 1638.109 s]

Summary
  'ThinLTO' ran
    1.02 times faster than 'ThinLTO + kCFI'

Cheers,
Nathan

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 00/21] KCFI support
@ 2022-05-17 18:49         ` Nathan Chancellor
  0 siblings, 0 replies; 174+ messages in thread
From: Nathan Chancellor @ 2022-05-17 18:49 UTC (permalink / raw)
  To: Sedat Dilek
  Cc: Sami Tolvanen, linux-kernel, Kees Cook, Josh Poimboeuf,
	Peter Zijlstra, x86, Catalin Marinas, Will Deacon, Mark Rutland,
	Nick Desaulniers, Joao Moreira, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Tue, May 17, 2022 at 09:33:47AM +0200, Sedat Dilek wrote:
> Is your tags/kcfi-rfc-v2 the recommended LLVM toolchain for testing kcfi-rfc-v2?
> 
> What I want to ask is if your commit well tested for x86 (and arm64)
> means build and boot on bare metal?

I have run kCFI (v1, I haven't had time to test v2) on x86_64 hardware,
both AMD and Intel. I have only found two failures so far: the i915
issue that I mention below and a failure in the KVM subsystem, which I
can see by just running QEMU:

[  124.344654] CFI failure at kvm_mmu_notifier_invalidate_range_end+0xca/0x177 [kvm] (target: kvm_null_fn+0x0/0x7 [kvm]; expected type: 0x1e2c5b9c)
[  124.344691] WARNING: CPU: 5 PID: 2767 at kvm_mmu_notifier_invalidate_range_end+0xca/0x177 [kvm]
[  124.344708] Modules linked in: ...
[  124.344737] CPU: 5 PID: 2767 Comm: qemu-system-x86 Tainted: P                  5.18.0-rc6-debug-00033-g1d5284aff7cd #1 8c4966c7fb24f3345076747feebac5fb340a4797
[  124.344738] Hardware name: ASUS System Product Name/PRIME Z590M-PLUS, BIOS 1203 10/27/2021
[  124.344738] RIP: 0010:kvm_mmu_notifier_invalidate_range_end+0xca/0x177 [kvm]
[  124.344756] Code: 48 89 da e8 88 16 86 dd 48 85 c0 89 6c 24 0c 74 30 4d 85 f6 74 36 48 c7 c5 19 c8 b4 c0 4c 8b 34 24 81 7d fa 9c 5b 2c 1e 74 02 <0f> 0b 48 89 c7 4c 89 fe 48 89 da e8 b6 16 86 dd 48 85 c0 75 e2 eb
[  124.344757] RSP: 0018:ffffc033039d78e8 EFLAGS: 00010282
[  124.344758] RAX: ffffa0a141ed9450 RBX: 00007fb897e9efff RCX: ffffa0a143c9d850
[  124.344758] RDX: 00007fb897e9efff RSI: 00007fb897e9e000 RDI: ffffc03304499cf8
[  124.344759] RBP: ffffffffc0b4c819 R08: 0000000000000000 R09: 0000000000000000
[  124.344759] R10: 0000000000000000 R11: ffffffffc0b4c639 R12: ffffc03304499000
[  124.344760] R13: ffffc033044a30a0 R14: ffffc033044a3120 R15: 00007fb897e9e000
[  124.344760] FS:  00007fbca4bc3640(0000) GS:ffffa0a87f540000(0000) knlGS:0000000000000000
[  124.344761] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  124.344761] CR2: 0000000000000000 CR3: 0000000119f74006 CR4: 0000000000772ee0
[  124.344762] PKRU: 55555554
[  124.344762] Call Trace:
[  124.344762]  <TASK>
[  124.344763]  __mmu_notifier_invalidate_range_end+0xa1/0xd7
[  124.344764]  wp_page_copy+0x592/0x920
[  124.344766]  __handle_mm_fault+0x820/0x8f0
[  124.344767]  handle_mm_fault+0xe0/0x227
[  124.344768]  __get_user_pages+0x17a/0x430
[  124.344769]  get_user_pages_unlocked+0xd9/0x327
[  124.344770]  hva_to_pfn+0xfa/0x3f7 [kvm 950e483805e01f967a3e331506278d766494a4cc]
[  124.344788]  kvm_faultin_pfn+0xc3/0x2f0 [kvm 950e483805e01f967a3e331506278d766494a4cc]
[  124.344806]  ? fast_page_fault+0x400/0x4c0 [kvm 950e483805e01f967a3e331506278d766494a4cc]
[  124.344823]  direct_page_fault+0x130/0x350 [kvm 950e483805e01f967a3e331506278d766494a4cc]
[  124.344841]  kvm_mmu_page_fault+0x176/0x2f7 [kvm 950e483805e01f967a3e331506278d766494a4cc]
[  124.344858]  vmx_handle_exit+0xe/0x37 [kvm_intel 647f514f18fc365045dc57db46d2bb4930b746eb]
[  124.344863]  vcpu_enter_guest+0xbff/0x1030 [kvm 950e483805e01f967a3e331506278d766494a4cc]
[  124.344881]  vcpu_run+0x65/0x2f0 [kvm 950e483805e01f967a3e331506278d766494a4cc]
[  124.344898]  kvm_arch_vcpu_ioctl_run+0x15f/0x3f7 [kvm 950e483805e01f967a3e331506278d766494a4cc]
[  124.344916]  kvm_vcpu_ioctl+0x547/0x627 [kvm 950e483805e01f967a3e331506278d766494a4cc]
[  124.344933]  ? syscall_exit_to_user_mode+0x24/0x47
[  124.344934]  ? do_syscall_64+0x7a/0x97
[  124.344935]  ? __fget_files+0xa1/0xc0
[  124.344936]  __se_sys_ioctl+0x7c/0xc0
[  124.344937]  do_syscall_64+0x6c/0x97
[  124.344938]  ? do_syscall_64+0x7a/0x97
[  124.344939]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[  124.344940] RIP: 0033:0x7fbca75f7b1f
[  124.344940] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00
[  124.344941] RSP: 002b:00007fbca4bc2550 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[  124.344942] RAX: ffffffffffffffda RBX: 000000000000ae80 RCX: 00007fbca75f7b1f
[  124.344942] RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 000000000000000e
[  124.344943] RBP: 000056351ba661d0 R08: 000056351a74dc48 R09: 0000000000000004
[  124.344943] R10: 004818cf4f129e11 R11: 0000000000000246 R12: 0000000000000000
[  124.344943] R13: 0000000000000000 R14: 00007fbca814f004 R15: 0000000000000000
[  124.344944]  </TASK>
[  124.344945] ---[ end trace 0000000000000000 ]---

I don't do any bare metal testing for the tc-build known good revision
bumps, just QEMU tests with boot-utils.

> Just for the records:
> You definitely need a pre-LLVM-15 toolchain + KCFI sanitizer patch?
> LLVM-14?

The feature won't land in LLVM 14, so there is little point to
backporting and testing it on LLVM 14. This is a work in progress
feature so it has to target the main branch. I have fairly good coverage
of tip of tree locally and we have solid coverage through CI so we'll
know if something major happens, it should be pretty safe to test Sami's
series.

> > > Nathan has a i915 cfi patch in His personal kernel.org Git.
> > > Is this relevant to kcfi?
> >
> > It fixes a type mismatch, so in that sense it's relevant.
> >
> 
> Here the link to patch "drm/i915: Fix CFI violation with show_dynamic_id()":
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/nathan/linux.git/commit/?h=submitted/i915-cfi-fix&id=53735be6dc53453fcfbac658e847b54360e73871

This is now in the i915 tree so that branch is going to disappear:

https://cgit.freedesktop.org/drm/drm-intel/commit/?id=18fb42db05a0b93ab5dd5eab5315e50eaa3ca620

> You say no need to build your kernel with LTO...
> That sounds good.
> Currently, I build my kernels with Clang-14 and CONFIG_LTO_CLANG_THIN=y.
> Does something speak against using CONFIG_LTO_CLANG_THIN=y with KCFI support?
> Build-time?
> Disc-usage?

I wouldn't expect the build time or disk usage to significantly increase
with kCFI. I ran a quick benchmark with Arch Linux's configuration with
ThinLTO then ThinLTO + kCFI on an AMD EPYC 7513:

Benchmark 1: ThinLTO
  Time (abs ≡):        166.036 s               [User: 4687.951 s, System: 1636.767 s]

Benchmark 2: ThinLTO + kCFI
  Time (abs ≡):        168.739 s               [User: 4682.020 s, System: 1638.109 s]

Summary
  'ThinLTO' ran
    1.02 times faster than 'ThinLTO + kCFI'

Cheers,
Nathan

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 00/21] KCFI support
  2022-05-17  8:57   ` Peter Zijlstra
@ 2022-05-17 20:25     ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-17 20:25 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: LKML, Kees Cook, Josh Poimboeuf, X86 ML, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Tue, May 17, 2022 at 1:58 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Fri, May 13, 2022 at 01:21:38PM -0700, Sami Tolvanen wrote:
> > KCFI is a proposed forward-edge control-flow integrity scheme for
> > Clang, which is more suitable for kernel use than the existing CFI
> > scheme used by CONFIG_CFI_CLANG. KCFI doesn't require LTO, doesn't
> > alter function references to point to a jump table, and won't break
> > function address equality. The latest LLVM patch is here:
> >
> >   https://reviews.llvm.org/D119296
> >
> > This RFC series replaces the current arm64 CFI implementation with
> > KCFI and adds support for x86_64.
>
> You have some weird behaviour vs weak functions (I so hate those)...
>
> 100: 0000000000000980     9 FUNC    LOCAL  DEFAULT    2 __cfi_free_initmem
> 233: 0000000000000989    35 FUNC    WEAK   DEFAULT    2 free_initmem
>
> With the result that on the final link:
>
>    179: 00000000000009b0     9 FUNC    LOCAL  DEFAULT    1 __cfi_free_initmem
>   8689: 00000000000007f0     9 FUNC    LOCAL  DEFAULT   65 __cfi_free_initmem
> 173283: 00000000000007f9   198 FUNC    GLOBAL DEFAULT   65 free_initmem
>
> This is getting me objtool issues (I'll fix them) but perhaps it's
> something you can do something about as well.

Good catch, I'll fix this.

Sami

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 00/21] KCFI support
@ 2022-05-17 20:25     ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-17 20:25 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: LKML, Kees Cook, Josh Poimboeuf, X86 ML, Catalin Marinas,
	Will Deacon, Mark Rutland, Nathan Chancellor, Nick Desaulniers,
	Joao Moreira, Sedat Dilek, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Tue, May 17, 2022 at 1:58 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Fri, May 13, 2022 at 01:21:38PM -0700, Sami Tolvanen wrote:
> > KCFI is a proposed forward-edge control-flow integrity scheme for
> > Clang, which is more suitable for kernel use than the existing CFI
> > scheme used by CONFIG_CFI_CLANG. KCFI doesn't require LTO, doesn't
> > alter function references to point to a jump table, and won't break
> > function address equality. The latest LLVM patch is here:
> >
> >   https://reviews.llvm.org/D119296
> >
> > This RFC series replaces the current arm64 CFI implementation with
> > KCFI and adds support for x86_64.
>
> You have some weird behaviour vs weak functions (I so hate those)...
>
> 100: 0000000000000980     9 FUNC    LOCAL  DEFAULT    2 __cfi_free_initmem
> 233: 0000000000000989    35 FUNC    WEAK   DEFAULT    2 free_initmem
>
> With the result that on the final link:
>
>    179: 00000000000009b0     9 FUNC    LOCAL  DEFAULT    1 __cfi_free_initmem
>   8689: 00000000000007f0     9 FUNC    LOCAL  DEFAULT   65 __cfi_free_initmem
> 173283: 00000000000007f9   198 FUNC    GLOBAL DEFAULT   65 free_initmem
>
> This is getting me objtool issues (I'll fix them) but perhaps it's
> something you can do something about as well.

Good catch, I'll fix this.

Sami

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
  2022-05-17  6:44               ` Peter Zijlstra
@ 2022-05-17 20:36                 ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-17 20:36 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: David Laight, linux-kernel, Kees Cook, Josh Poimboeuf, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Mon, May 16, 2022 at 11:44 PM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Mon, May 16, 2022 at 03:03:02PM -0700, Sami Tolvanen wrote:
> > On Mon, May 16, 2022 at 2:44 PM Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > > On Mon, May 16, 2022 at 09:32:55PM +0000, David Laight wrote:
> > >
> > > > > The compiler always generates this specific instruction sequence.
> > > >
> > > > Yes, but there are several ways to encode 'cmpl imm,-6(reg)'.
> > >
> > > Yes, but we don't care. This *always* uses the 32bit immediate form.
> > > Even if the immediate is small.
> >
> > Yes, that part is not a problem, but it's a valid point that LLVM
> > might not always use r8-r15 here, so I will have to check for the REX
> > prefix before blindly attempting to decode the instruction.
>
> LLVM has always used r11 for indirect calls, will that change?

No, this won't change register allocation, but I will have to ensure
that the compiler won't do any unnecessary register shuffling for the
check itself.

Sami

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
@ 2022-05-17 20:36                 ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-17 20:36 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: David Laight, linux-kernel, Kees Cook, Josh Poimboeuf, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Mon, May 16, 2022 at 11:44 PM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Mon, May 16, 2022 at 03:03:02PM -0700, Sami Tolvanen wrote:
> > On Mon, May 16, 2022 at 2:44 PM Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > > On Mon, May 16, 2022 at 09:32:55PM +0000, David Laight wrote:
> > >
> > > > > The compiler always generates this specific instruction sequence.
> > > >
> > > > Yes, but there are several ways to encode 'cmpl imm,-6(reg)'.
> > >
> > > Yes, but we don't care. This *always* uses the 32bit immediate form.
> > > Even if the immediate is small.
> >
> > Yes, that part is not a problem, but it's a valid point that LLVM
> > might not always use r8-r15 here, so I will have to check for the REX
> > prefix before blindly attempting to decode the instruction.
>
> LLVM has always used r11 for indirect calls, will that change?

No, this won't change register allocation, but I will have to ensure
that the compiler won't do any unnecessary register shuffling for the
check itself.

Sami

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 00/21] KCFI support
  2022-05-17 18:49         ` Nathan Chancellor
@ 2022-05-19  9:01           ` Sedat Dilek
  -1 siblings, 0 replies; 174+ messages in thread
From: Sedat Dilek @ 2022-05-19  9:01 UTC (permalink / raw)
  To: Nathan Chancellor
  Cc: Sami Tolvanen, linux-kernel, Kees Cook, Josh Poimboeuf,
	Peter Zijlstra, x86, Catalin Marinas, Will Deacon, Mark Rutland,
	Nick Desaulniers, Joao Moreira, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Tue, May 17, 2022 at 8:49 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> On Tue, May 17, 2022 at 09:33:47AM +0200, Sedat Dilek wrote:
> > Is your tags/kcfi-rfc-v2 the recommended LLVM toolchain for testing kcfi-rfc-v2?
> >
> > What I want to ask is if your commit well tested for x86 (and arm64)
> > means build and boot on bare metal?
>
> I have run kCFI (v1, I haven't had time to test v2) on x86_64 hardware,
> both AMD and Intel. I have only found two failures so far: the i915
> issue that I mention below and a failure in the KVM subsystem, which I
> can see by just running QEMU:
>

Is there a fix around this issue?

> [  124.344654] CFI failure at kvm_mmu_notifier_invalidate_range_end+0xca/0x177 [kvm] (target: kvm_null_fn+0x0/0x7 [kvm]; expected type: 0x1e2c5b9c)
> [  124.344691] WARNING: CPU: 5 PID: 2767 at kvm_mmu_notifier_invalidate_range_end+0xca/0x177 [kvm]
> [  124.344708] Modules linked in: ...
> [  124.344737] CPU: 5 PID: 2767 Comm: qemu-system-x86 Tainted: P                  5.18.0-rc6-debug-00033-g1d5284aff7cd #1 8c4966c7fb24f3345076747feebac5fb340a4797
> [  124.344738] Hardware name: ASUS System Product Name/PRIME Z590M-PLUS, BIOS 1203 10/27/2021
> [  124.344738] RIP: 0010:kvm_mmu_notifier_invalidate_range_end+0xca/0x177 [kvm]
> [  124.344756] Code: 48 89 da e8 88 16 86 dd 48 85 c0 89 6c 24 0c 74 30 4d 85 f6 74 36 48 c7 c5 19 c8 b4 c0 4c 8b 34 24 81 7d fa 9c 5b 2c 1e 74 02 <0f> 0b 48 89 c7 4c 89 fe 48 89 da e8 b6 16 86 dd 48 85 c0 75 e2 eb
> [  124.344757] RSP: 0018:ffffc033039d78e8 EFLAGS: 00010282
> [  124.344758] RAX: ffffa0a141ed9450 RBX: 00007fb897e9efff RCX: ffffa0a143c9d850
> [  124.344758] RDX: 00007fb897e9efff RSI: 00007fb897e9e000 RDI: ffffc03304499cf8
> [  124.344759] RBP: ffffffffc0b4c819 R08: 0000000000000000 R09: 0000000000000000
> [  124.344759] R10: 0000000000000000 R11: ffffffffc0b4c639 R12: ffffc03304499000
> [  124.344760] R13: ffffc033044a30a0 R14: ffffc033044a3120 R15: 00007fb897e9e000
> [  124.344760] FS:  00007fbca4bc3640(0000) GS:ffffa0a87f540000(0000) knlGS:0000000000000000
> [  124.344761] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [  124.344761] CR2: 0000000000000000 CR3: 0000000119f74006 CR4: 0000000000772ee0
> [  124.344762] PKRU: 55555554
> [  124.344762] Call Trace:
> [  124.344762]  <TASK>
> [  124.344763]  __mmu_notifier_invalidate_range_end+0xa1/0xd7
> [  124.344764]  wp_page_copy+0x592/0x920
> [  124.344766]  __handle_mm_fault+0x820/0x8f0
> [  124.344767]  handle_mm_fault+0xe0/0x227
> [  124.344768]  __get_user_pages+0x17a/0x430
> [  124.344769]  get_user_pages_unlocked+0xd9/0x327
> [  124.344770]  hva_to_pfn+0xfa/0x3f7 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> [  124.344788]  kvm_faultin_pfn+0xc3/0x2f0 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> [  124.344806]  ? fast_page_fault+0x400/0x4c0 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> [  124.344823]  direct_page_fault+0x130/0x350 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> [  124.344841]  kvm_mmu_page_fault+0x176/0x2f7 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> [  124.344858]  vmx_handle_exit+0xe/0x37 [kvm_intel 647f514f18fc365045dc57db46d2bb4930b746eb]
> [  124.344863]  vcpu_enter_guest+0xbff/0x1030 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> [  124.344881]  vcpu_run+0x65/0x2f0 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> [  124.344898]  kvm_arch_vcpu_ioctl_run+0x15f/0x3f7 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> [  124.344916]  kvm_vcpu_ioctl+0x547/0x627 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> [  124.344933]  ? syscall_exit_to_user_mode+0x24/0x47
> [  124.344934]  ? do_syscall_64+0x7a/0x97
> [  124.344935]  ? __fget_files+0xa1/0xc0
> [  124.344936]  __se_sys_ioctl+0x7c/0xc0
> [  124.344937]  do_syscall_64+0x6c/0x97
> [  124.344938]  ? do_syscall_64+0x7a/0x97
> [  124.344939]  entry_SYSCALL_64_after_hwframe+0x44/0xae
> [  124.344940] RIP: 0033:0x7fbca75f7b1f
> [  124.344940] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00
> [  124.344941] RSP: 002b:00007fbca4bc2550 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> [  124.344942] RAX: ffffffffffffffda RBX: 000000000000ae80 RCX: 00007fbca75f7b1f
> [  124.344942] RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 000000000000000e
> [  124.344943] RBP: 000056351ba661d0 R08: 000056351a74dc48 R09: 0000000000000004
> [  124.344943] R10: 004818cf4f129e11 R11: 0000000000000246 R12: 0000000000000000
> [  124.344943] R13: 0000000000000000 R14: 00007fbca814f004 R15: 0000000000000000
> [  124.344944]  </TASK>
> [  124.344945] ---[ end trace 0000000000000000 ]---
>
> I don't do any bare metal testing for the tc-build known good revision
> bumps, just QEMU tests with boot-utils.
>
> > Just for the records:
> > You definitely need a pre-LLVM-15 toolchain + KCFI sanitizer patch?
> > LLVM-14?
>
> The feature won't land in LLVM 14, so there is little point to
> backporting and testing it on LLVM 14. This is a work in progress
> feature so it has to target the main branch. I have fairly good coverage
> of tip of tree locally and we have solid coverage through CI so we'll
> know if something major happens, it should be pretty safe to test Sami's
> series.
>

OK, no backport.

> > > > Nathan has a i915 cfi patch in His personal kernel.org Git.
> > > > Is this relevant to kcfi?
> > >
> > > It fixes a type mismatch, so in that sense it's relevant.
> > >
> >
> > Here the link to patch "drm/i915: Fix CFI violation with show_dynamic_id()":
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/nathan/linux.git/commit/?h=submitted/i915-cfi-fix&id=53735be6dc53453fcfbac658e847b54360e73871
>
> This is now in the i915 tree so that branch is going to disappear:
>
> https://cgit.freedesktop.org/drm/drm-intel/commit/?id=18fb42db05a0b93ab5dd5eab5315e50eaa3ca620
>

Good to know.

> > You say no need to build your kernel with LTO...
> > That sounds good.
> > Currently, I build my kernels with Clang-14 and CONFIG_LTO_CLANG_THIN=y.
> > Does something speak against using CONFIG_LTO_CLANG_THIN=y with KCFI support?
> > Build-time?
> > Disc-usage?
>
> I wouldn't expect the build time or disk usage to significantly increase
> with kCFI. I ran a quick benchmark with Arch Linux's configuration with
> ThinLTO then ThinLTO + kCFI on an AMD EPYC 7513:
>
> Benchmark 1: ThinLTO
>   Time (abs ≡):        166.036 s               [User: 4687.951 s, System: 1636.767 s]
>
> Benchmark 2: ThinLTO + kCFI
>   Time (abs ≡):        168.739 s               [User: 4682.020 s, System: 1638.109 s]
>
> Summary
>   'ThinLTO' ran
>     1.02 times faster than 'ThinLTO + kCFI'
>

Thanks for your feedback.

-Sedat-

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 00/21] KCFI support
@ 2022-05-19  9:01           ` Sedat Dilek
  0 siblings, 0 replies; 174+ messages in thread
From: Sedat Dilek @ 2022-05-19  9:01 UTC (permalink / raw)
  To: Nathan Chancellor
  Cc: Sami Tolvanen, linux-kernel, Kees Cook, Josh Poimboeuf,
	Peter Zijlstra, x86, Catalin Marinas, Will Deacon, Mark Rutland,
	Nick Desaulniers, Joao Moreira, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Tue, May 17, 2022 at 8:49 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> On Tue, May 17, 2022 at 09:33:47AM +0200, Sedat Dilek wrote:
> > Is your tags/kcfi-rfc-v2 the recommended LLVM toolchain for testing kcfi-rfc-v2?
> >
> > What I want to ask is if your commit well tested for x86 (and arm64)
> > means build and boot on bare metal?
>
> I have run kCFI (v1, I haven't had time to test v2) on x86_64 hardware,
> both AMD and Intel. I have only found two failures so far: the i915
> issue that I mention below and a failure in the KVM subsystem, which I
> can see by just running QEMU:
>

Is there a fix around this issue?

> [  124.344654] CFI failure at kvm_mmu_notifier_invalidate_range_end+0xca/0x177 [kvm] (target: kvm_null_fn+0x0/0x7 [kvm]; expected type: 0x1e2c5b9c)
> [  124.344691] WARNING: CPU: 5 PID: 2767 at kvm_mmu_notifier_invalidate_range_end+0xca/0x177 [kvm]
> [  124.344708] Modules linked in: ...
> [  124.344737] CPU: 5 PID: 2767 Comm: qemu-system-x86 Tainted: P                  5.18.0-rc6-debug-00033-g1d5284aff7cd #1 8c4966c7fb24f3345076747feebac5fb340a4797
> [  124.344738] Hardware name: ASUS System Product Name/PRIME Z590M-PLUS, BIOS 1203 10/27/2021
> [  124.344738] RIP: 0010:kvm_mmu_notifier_invalidate_range_end+0xca/0x177 [kvm]
> [  124.344756] Code: 48 89 da e8 88 16 86 dd 48 85 c0 89 6c 24 0c 74 30 4d 85 f6 74 36 48 c7 c5 19 c8 b4 c0 4c 8b 34 24 81 7d fa 9c 5b 2c 1e 74 02 <0f> 0b 48 89 c7 4c 89 fe 48 89 da e8 b6 16 86 dd 48 85 c0 75 e2 eb
> [  124.344757] RSP: 0018:ffffc033039d78e8 EFLAGS: 00010282
> [  124.344758] RAX: ffffa0a141ed9450 RBX: 00007fb897e9efff RCX: ffffa0a143c9d850
> [  124.344758] RDX: 00007fb897e9efff RSI: 00007fb897e9e000 RDI: ffffc03304499cf8
> [  124.344759] RBP: ffffffffc0b4c819 R08: 0000000000000000 R09: 0000000000000000
> [  124.344759] R10: 0000000000000000 R11: ffffffffc0b4c639 R12: ffffc03304499000
> [  124.344760] R13: ffffc033044a30a0 R14: ffffc033044a3120 R15: 00007fb897e9e000
> [  124.344760] FS:  00007fbca4bc3640(0000) GS:ffffa0a87f540000(0000) knlGS:0000000000000000
> [  124.344761] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [  124.344761] CR2: 0000000000000000 CR3: 0000000119f74006 CR4: 0000000000772ee0
> [  124.344762] PKRU: 55555554
> [  124.344762] Call Trace:
> [  124.344762]  <TASK>
> [  124.344763]  __mmu_notifier_invalidate_range_end+0xa1/0xd7
> [  124.344764]  wp_page_copy+0x592/0x920
> [  124.344766]  __handle_mm_fault+0x820/0x8f0
> [  124.344767]  handle_mm_fault+0xe0/0x227
> [  124.344768]  __get_user_pages+0x17a/0x430
> [  124.344769]  get_user_pages_unlocked+0xd9/0x327
> [  124.344770]  hva_to_pfn+0xfa/0x3f7 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> [  124.344788]  kvm_faultin_pfn+0xc3/0x2f0 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> [  124.344806]  ? fast_page_fault+0x400/0x4c0 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> [  124.344823]  direct_page_fault+0x130/0x350 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> [  124.344841]  kvm_mmu_page_fault+0x176/0x2f7 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> [  124.344858]  vmx_handle_exit+0xe/0x37 [kvm_intel 647f514f18fc365045dc57db46d2bb4930b746eb]
> [  124.344863]  vcpu_enter_guest+0xbff/0x1030 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> [  124.344881]  vcpu_run+0x65/0x2f0 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> [  124.344898]  kvm_arch_vcpu_ioctl_run+0x15f/0x3f7 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> [  124.344916]  kvm_vcpu_ioctl+0x547/0x627 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> [  124.344933]  ? syscall_exit_to_user_mode+0x24/0x47
> [  124.344934]  ? do_syscall_64+0x7a/0x97
> [  124.344935]  ? __fget_files+0xa1/0xc0
> [  124.344936]  __se_sys_ioctl+0x7c/0xc0
> [  124.344937]  do_syscall_64+0x6c/0x97
> [  124.344938]  ? do_syscall_64+0x7a/0x97
> [  124.344939]  entry_SYSCALL_64_after_hwframe+0x44/0xae
> [  124.344940] RIP: 0033:0x7fbca75f7b1f
> [  124.344940] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00
> [  124.344941] RSP: 002b:00007fbca4bc2550 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> [  124.344942] RAX: ffffffffffffffda RBX: 000000000000ae80 RCX: 00007fbca75f7b1f
> [  124.344942] RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 000000000000000e
> [  124.344943] RBP: 000056351ba661d0 R08: 000056351a74dc48 R09: 0000000000000004
> [  124.344943] R10: 004818cf4f129e11 R11: 0000000000000246 R12: 0000000000000000
> [  124.344943] R13: 0000000000000000 R14: 00007fbca814f004 R15: 0000000000000000
> [  124.344944]  </TASK>
> [  124.344945] ---[ end trace 0000000000000000 ]---
>
> I don't do any bare metal testing for the tc-build known good revision
> bumps, just QEMU tests with boot-utils.
>
> > Just for the records:
> > You definitely need a pre-LLVM-15 toolchain + KCFI sanitizer patch?
> > LLVM-14?
>
> The feature won't land in LLVM 14, so there is little point to
> backporting and testing it on LLVM 14. This is a work in progress
> feature so it has to target the main branch. I have fairly good coverage
> of tip of tree locally and we have solid coverage through CI so we'll
> know if something major happens, it should be pretty safe to test Sami's
> series.
>

OK, no backport.

> > > > Nathan has a i915 cfi patch in His personal kernel.org Git.
> > > > Is this relevant to kcfi?
> > >
> > > It fixes a type mismatch, so in that sense it's relevant.
> > >
> >
> > Here the link to patch "drm/i915: Fix CFI violation with show_dynamic_id()":
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/nathan/linux.git/commit/?h=submitted/i915-cfi-fix&id=53735be6dc53453fcfbac658e847b54360e73871
>
> This is now in the i915 tree so that branch is going to disappear:
>
> https://cgit.freedesktop.org/drm/drm-intel/commit/?id=18fb42db05a0b93ab5dd5eab5315e50eaa3ca620
>

Good to know.

> > You say no need to build your kernel with LTO...
> > That sounds good.
> > Currently, I build my kernels with Clang-14 and CONFIG_LTO_CLANG_THIN=y.
> > Does something speak against using CONFIG_LTO_CLANG_THIN=y with KCFI support?
> > Build-time?
> > Disc-usage?
>
> I wouldn't expect the build time or disk usage to significantly increase
> with kCFI. I ran a quick benchmark with Arch Linux's configuration with
> ThinLTO then ThinLTO + kCFI on an AMD EPYC 7513:
>
> Benchmark 1: ThinLTO
>   Time (abs ≡):        166.036 s               [User: 4687.951 s, System: 1636.767 s]
>
> Benchmark 2: ThinLTO + kCFI
>   Time (abs ≡):        168.739 s               [User: 4682.020 s, System: 1638.109 s]
>
> Summary
>   'ThinLTO' ran
>     1.02 times faster than 'ThinLTO + kCFI'
>

Thanks for your feedback.

-Sedat-

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 00/21] KCFI support
  2022-05-19  9:01           ` Sedat Dilek
@ 2022-05-19 20:26             ` Nathan Chancellor
  -1 siblings, 0 replies; 174+ messages in thread
From: Nathan Chancellor @ 2022-05-19 20:26 UTC (permalink / raw)
  To: Sedat Dilek
  Cc: Sami Tolvanen, linux-kernel, Kees Cook, Josh Poimboeuf,
	Peter Zijlstra, x86, Catalin Marinas, Will Deacon, Mark Rutland,
	Nick Desaulniers, Joao Moreira, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Thu, May 19, 2022 at 11:01:40AM +0200, Sedat Dilek wrote:
> On Tue, May 17, 2022 at 8:49 PM Nathan Chancellor <nathan@kernel.org> wrote:
> > I have run kCFI (v1, I haven't had time to test v2) on x86_64 hardware,
> > both AMD and Intel. I have only found two failures so far: the i915
> > issue that I mention below and a failure in the KVM subsystem, which I
> > can see by just running QEMU:
> >
> 
> Is there a fix around this issue?

No, I mentioned it offhand to Sami in IRC but I never followed up. This
failure appears to be introduced by commit f922bd9bf33b ("KVM: Move MMU
notifier's mmu_lock acquisition into common helper").

Sami, do you want an issue opened around this somewhere?

> > [  124.344654] CFI failure at kvm_mmu_notifier_invalidate_range_end+0xca/0x177 [kvm] (target: kvm_null_fn+0x0/0x7 [kvm]; expected type: 0x1e2c5b9c)
> > [  124.344691] WARNING: CPU: 5 PID: 2767 at kvm_mmu_notifier_invalidate_range_end+0xca/0x177 [kvm]
> > [  124.344708] Modules linked in: ...
> > [  124.344737] CPU: 5 PID: 2767 Comm: qemu-system-x86 Tainted: P                  5.18.0-rc6-debug-00033-g1d5284aff7cd #1 8c4966c7fb24f3345076747feebac5fb340a4797
> > [  124.344738] Hardware name: ASUS System Product Name/PRIME Z590M-PLUS, BIOS 1203 10/27/2021
> > [  124.344738] RIP: 0010:kvm_mmu_notifier_invalidate_range_end+0xca/0x177 [kvm]
> > [  124.344756] Code: 48 89 da e8 88 16 86 dd 48 85 c0 89 6c 24 0c 74 30 4d 85 f6 74 36 48 c7 c5 19 c8 b4 c0 4c 8b 34 24 81 7d fa 9c 5b 2c 1e 74 02 <0f> 0b 48 89 c7 4c 89 fe 48 89 da e8 b6 16 86 dd 48 85 c0 75 e2 eb
> > [  124.344757] RSP: 0018:ffffc033039d78e8 EFLAGS: 00010282
> > [  124.344758] RAX: ffffa0a141ed9450 RBX: 00007fb897e9efff RCX: ffffa0a143c9d850
> > [  124.344758] RDX: 00007fb897e9efff RSI: 00007fb897e9e000 RDI: ffffc03304499cf8
> > [  124.344759] RBP: ffffffffc0b4c819 R08: 0000000000000000 R09: 0000000000000000
> > [  124.344759] R10: 0000000000000000 R11: ffffffffc0b4c639 R12: ffffc03304499000
> > [  124.344760] R13: ffffc033044a30a0 R14: ffffc033044a3120 R15: 00007fb897e9e000
> > [  124.344760] FS:  00007fbca4bc3640(0000) GS:ffffa0a87f540000(0000) knlGS:0000000000000000
> > [  124.344761] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [  124.344761] CR2: 0000000000000000 CR3: 0000000119f74006 CR4: 0000000000772ee0
> > [  124.344762] PKRU: 55555554
> > [  124.344762] Call Trace:
> > [  124.344762]  <TASK>
> > [  124.344763]  __mmu_notifier_invalidate_range_end+0xa1/0xd7
> > [  124.344764]  wp_page_copy+0x592/0x920
> > [  124.344766]  __handle_mm_fault+0x820/0x8f0
> > [  124.344767]  handle_mm_fault+0xe0/0x227
> > [  124.344768]  __get_user_pages+0x17a/0x430
> > [  124.344769]  get_user_pages_unlocked+0xd9/0x327
> > [  124.344770]  hva_to_pfn+0xfa/0x3f7 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> > [  124.344788]  kvm_faultin_pfn+0xc3/0x2f0 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> > [  124.344806]  ? fast_page_fault+0x400/0x4c0 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> > [  124.344823]  direct_page_fault+0x130/0x350 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> > [  124.344841]  kvm_mmu_page_fault+0x176/0x2f7 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> > [  124.344858]  vmx_handle_exit+0xe/0x37 [kvm_intel 647f514f18fc365045dc57db46d2bb4930b746eb]
> > [  124.344863]  vcpu_enter_guest+0xbff/0x1030 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> > [  124.344881]  vcpu_run+0x65/0x2f0 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> > [  124.344898]  kvm_arch_vcpu_ioctl_run+0x15f/0x3f7 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> > [  124.344916]  kvm_vcpu_ioctl+0x547/0x627 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> > [  124.344933]  ? syscall_exit_to_user_mode+0x24/0x47
> > [  124.344934]  ? do_syscall_64+0x7a/0x97
> > [  124.344935]  ? __fget_files+0xa1/0xc0
> > [  124.344936]  __se_sys_ioctl+0x7c/0xc0
> > [  124.344937]  do_syscall_64+0x6c/0x97
> > [  124.344938]  ? do_syscall_64+0x7a/0x97
> > [  124.344939]  entry_SYSCALL_64_after_hwframe+0x44/0xae
> > [  124.344940] RIP: 0033:0x7fbca75f7b1f
> > [  124.344940] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00
> > [  124.344941] RSP: 002b:00007fbca4bc2550 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> > [  124.344942] RAX: ffffffffffffffda RBX: 000000000000ae80 RCX: 00007fbca75f7b1f
> > [  124.344942] RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 000000000000000e
> > [  124.344943] RBP: 000056351ba661d0 R08: 000056351a74dc48 R09: 0000000000000004
> > [  124.344943] R10: 004818cf4f129e11 R11: 0000000000000246 R12: 0000000000000000
> > [  124.344943] R13: 0000000000000000 R14: 00007fbca814f004 R15: 0000000000000000
> > [  124.344944]  </TASK>
> > [  124.344945] ---[ end trace 0000000000000000 ]---

Cheers,
Nathan

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 00/21] KCFI support
@ 2022-05-19 20:26             ` Nathan Chancellor
  0 siblings, 0 replies; 174+ messages in thread
From: Nathan Chancellor @ 2022-05-19 20:26 UTC (permalink / raw)
  To: Sedat Dilek
  Cc: Sami Tolvanen, linux-kernel, Kees Cook, Josh Poimboeuf,
	Peter Zijlstra, x86, Catalin Marinas, Will Deacon, Mark Rutland,
	Nick Desaulniers, Joao Moreira, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Thu, May 19, 2022 at 11:01:40AM +0200, Sedat Dilek wrote:
> On Tue, May 17, 2022 at 8:49 PM Nathan Chancellor <nathan@kernel.org> wrote:
> > I have run kCFI (v1, I haven't had time to test v2) on x86_64 hardware,
> > both AMD and Intel. I have only found two failures so far: the i915
> > issue that I mention below and a failure in the KVM subsystem, which I
> > can see by just running QEMU:
> >
> 
> Is there a fix around this issue?

No, I mentioned it offhand to Sami in IRC but I never followed up. This
failure appears to be introduced by commit f922bd9bf33b ("KVM: Move MMU
notifier's mmu_lock acquisition into common helper").

Sami, do you want an issue opened around this somewhere?

> > [  124.344654] CFI failure at kvm_mmu_notifier_invalidate_range_end+0xca/0x177 [kvm] (target: kvm_null_fn+0x0/0x7 [kvm]; expected type: 0x1e2c5b9c)
> > [  124.344691] WARNING: CPU: 5 PID: 2767 at kvm_mmu_notifier_invalidate_range_end+0xca/0x177 [kvm]
> > [  124.344708] Modules linked in: ...
> > [  124.344737] CPU: 5 PID: 2767 Comm: qemu-system-x86 Tainted: P                  5.18.0-rc6-debug-00033-g1d5284aff7cd #1 8c4966c7fb24f3345076747feebac5fb340a4797
> > [  124.344738] Hardware name: ASUS System Product Name/PRIME Z590M-PLUS, BIOS 1203 10/27/2021
> > [  124.344738] RIP: 0010:kvm_mmu_notifier_invalidate_range_end+0xca/0x177 [kvm]
> > [  124.344756] Code: 48 89 da e8 88 16 86 dd 48 85 c0 89 6c 24 0c 74 30 4d 85 f6 74 36 48 c7 c5 19 c8 b4 c0 4c 8b 34 24 81 7d fa 9c 5b 2c 1e 74 02 <0f> 0b 48 89 c7 4c 89 fe 48 89 da e8 b6 16 86 dd 48 85 c0 75 e2 eb
> > [  124.344757] RSP: 0018:ffffc033039d78e8 EFLAGS: 00010282
> > [  124.344758] RAX: ffffa0a141ed9450 RBX: 00007fb897e9efff RCX: ffffa0a143c9d850
> > [  124.344758] RDX: 00007fb897e9efff RSI: 00007fb897e9e000 RDI: ffffc03304499cf8
> > [  124.344759] RBP: ffffffffc0b4c819 R08: 0000000000000000 R09: 0000000000000000
> > [  124.344759] R10: 0000000000000000 R11: ffffffffc0b4c639 R12: ffffc03304499000
> > [  124.344760] R13: ffffc033044a30a0 R14: ffffc033044a3120 R15: 00007fb897e9e000
> > [  124.344760] FS:  00007fbca4bc3640(0000) GS:ffffa0a87f540000(0000) knlGS:0000000000000000
> > [  124.344761] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [  124.344761] CR2: 0000000000000000 CR3: 0000000119f74006 CR4: 0000000000772ee0
> > [  124.344762] PKRU: 55555554
> > [  124.344762] Call Trace:
> > [  124.344762]  <TASK>
> > [  124.344763]  __mmu_notifier_invalidate_range_end+0xa1/0xd7
> > [  124.344764]  wp_page_copy+0x592/0x920
> > [  124.344766]  __handle_mm_fault+0x820/0x8f0
> > [  124.344767]  handle_mm_fault+0xe0/0x227
> > [  124.344768]  __get_user_pages+0x17a/0x430
> > [  124.344769]  get_user_pages_unlocked+0xd9/0x327
> > [  124.344770]  hva_to_pfn+0xfa/0x3f7 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> > [  124.344788]  kvm_faultin_pfn+0xc3/0x2f0 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> > [  124.344806]  ? fast_page_fault+0x400/0x4c0 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> > [  124.344823]  direct_page_fault+0x130/0x350 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> > [  124.344841]  kvm_mmu_page_fault+0x176/0x2f7 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> > [  124.344858]  vmx_handle_exit+0xe/0x37 [kvm_intel 647f514f18fc365045dc57db46d2bb4930b746eb]
> > [  124.344863]  vcpu_enter_guest+0xbff/0x1030 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> > [  124.344881]  vcpu_run+0x65/0x2f0 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> > [  124.344898]  kvm_arch_vcpu_ioctl_run+0x15f/0x3f7 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> > [  124.344916]  kvm_vcpu_ioctl+0x547/0x627 [kvm 950e483805e01f967a3e331506278d766494a4cc]
> > [  124.344933]  ? syscall_exit_to_user_mode+0x24/0x47
> > [  124.344934]  ? do_syscall_64+0x7a/0x97
> > [  124.344935]  ? __fget_files+0xa1/0xc0
> > [  124.344936]  __se_sys_ioctl+0x7c/0xc0
> > [  124.344937]  do_syscall_64+0x6c/0x97
> > [  124.344938]  ? do_syscall_64+0x7a/0x97
> > [  124.344939]  entry_SYSCALL_64_after_hwframe+0x44/0xae
> > [  124.344940] RIP: 0033:0x7fbca75f7b1f
> > [  124.344940] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00
> > [  124.344941] RSP: 002b:00007fbca4bc2550 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> > [  124.344942] RAX: ffffffffffffffda RBX: 000000000000ae80 RCX: 00007fbca75f7b1f
> > [  124.344942] RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 000000000000000e
> > [  124.344943] RBP: 000056351ba661d0 R08: 000056351a74dc48 R09: 0000000000000004
> > [  124.344943] R10: 004818cf4f129e11 R11: 0000000000000246 R12: 0000000000000000
> > [  124.344943] R13: 0000000000000000 R14: 00007fbca814f004 R15: 0000000000000000
> > [  124.344944]  </TASK>
> > [  124.344945] ---[ end trace 0000000000000000 ]---

Cheers,
Nathan

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 00/21] KCFI support
  2022-05-19 20:26             ` Nathan Chancellor
@ 2022-05-19 20:41               ` Sami Tolvanen
  -1 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-19 20:41 UTC (permalink / raw)
  To: Nathan Chancellor
  Cc: Sedat Dilek, LKML, Kees Cook, Josh Poimboeuf, Peter Zijlstra,
	X86 ML, Catalin Marinas, Will Deacon, Mark Rutland,
	Nick Desaulniers, Joao Moreira, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Thu, May 19, 2022 at 1:26 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> On Thu, May 19, 2022 at 11:01:40AM +0200, Sedat Dilek wrote:
> > On Tue, May 17, 2022 at 8:49 PM Nathan Chancellor <nathan@kernel.org> wrote:
> > > I have run kCFI (v1, I haven't had time to test v2) on x86_64 hardware,
> > > both AMD and Intel. I have only found two failures so far: the i915
> > > issue that I mention below and a failure in the KVM subsystem, which I
> > > can see by just running QEMU:
> > >
> >
> > Is there a fix around this issue?
>
> No, I mentioned it offhand to Sami in IRC but I never followed up. This
> failure appears to be introduced by commit f922bd9bf33b ("KVM: Move MMU
> notifier's mmu_lock acquisition into common helper").
>
> Sami, do you want an issue opened around this somewhere?

Yes, please file a bug. The ClangBuiltLinux Github is probably the best place.

Sami

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 00/21] KCFI support
@ 2022-05-19 20:41               ` Sami Tolvanen
  0 siblings, 0 replies; 174+ messages in thread
From: Sami Tolvanen @ 2022-05-19 20:41 UTC (permalink / raw)
  To: Nathan Chancellor
  Cc: Sedat Dilek, LKML, Kees Cook, Josh Poimboeuf, Peter Zijlstra,
	X86 ML, Catalin Marinas, Will Deacon, Mark Rutland,
	Nick Desaulniers, Joao Moreira, Steven Rostedt, linux-hardening,
	linux-arm-kernel, llvm

On Thu, May 19, 2022 at 1:26 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> On Thu, May 19, 2022 at 11:01:40AM +0200, Sedat Dilek wrote:
> > On Tue, May 17, 2022 at 8:49 PM Nathan Chancellor <nathan@kernel.org> wrote:
> > > I have run kCFI (v1, I haven't had time to test v2) on x86_64 hardware,
> > > both AMD and Intel. I have only found two failures so far: the i915
> > > issue that I mention below and a failure in the KVM subsystem, which I
> > > can see by just running QEMU:
> > >
> >
> > Is there a fix around this issue?
>
> No, I mentioned it offhand to Sami in IRC but I never followed up. This
> failure appears to be introduced by commit f922bd9bf33b ("KVM: Move MMU
> notifier's mmu_lock acquisition into common helper").
>
> Sami, do you want an issue opened around this somewhere?

Yes, please file a bug. The ClangBuiltLinux Github is probably the best place.

Sami

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
  2022-05-16 12:58         ` Peter Zijlstra
@ 2022-05-20 13:49           ` Matthew Wilcox
  -1 siblings, 0 replies; 174+ messages in thread
From: Matthew Wilcox @ 2022-05-20 13:49 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Sami Tolvanen, linux-kernel, Kees Cook, Josh Poimboeuf, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Mon, May 16, 2022 at 02:58:44PM +0200, Peter Zijlstra wrote:
> @willy, how horribly broken is this xarray usage?

The xarray doesn't work very well as a hash ;-(  It has pretty much
pessimal memory usage if you have a good hash.  You'll end up allocating
essentially the entire 4 billion * ptr_size address space of the hash.
Can you use an rhashtable instead?

> ---
>  arch/x86/include/asm/traps.h            |   1 +
>  arch/x86/kernel/alternative.c           | 316 ++++++++++++++++++++++++++++++++
>  arch/x86/kernel/cpu/common.c            |   5 +
>  arch/x86/kernel/vmlinux.lds.S           |   9 +
>  tools/objtool/check.c                   |  67 ++++++-
>  tools/objtool/include/objtool/objtool.h |   1 +
>  tools/objtool/objtool.c                 |   1 +
>  7 files changed, 399 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/include/asm/traps.h b/arch/x86/include/asm/traps.h
> index 35317c5c551d..a423343cffbc 100644
> --- a/arch/x86/include/asm/traps.h
> +++ b/arch/x86/include/asm/traps.h
> @@ -19,6 +19,7 @@ asmlinkage __visible noinstr struct pt_regs *vc_switch_off_ist(struct pt_regs *e
>  #endif
>  
>  extern bool ibt_selftest(void);
> +extern bool ibt_broken;
>  
>  #ifdef CONFIG_X86_F00F_BUG
>  /* For handling the FOOF bug */
> diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
> index d374cb3cf024..abce4e78a1e0 100644
> --- a/arch/x86/kernel/alternative.c
> +++ b/arch/x86/kernel/alternative.c
> @@ -18,6 +18,9 @@
>  #include <linux/mmu_context.h>
>  #include <linux/bsearch.h>
>  #include <linux/sync_core.h>
> +#include <linux/moduleloader.h>
> +#include <linux/xarray.h>
> +#include <linux/set_memory.h>
>  #include <asm/text-patching.h>
>  #include <asm/alternative.h>
>  #include <asm/sections.h>
> @@ -115,6 +118,7 @@ static void __init_or_module add_nops(void *insns, unsigned int len)
>  }
>  
>  extern s32 __retpoline_sites[], __retpoline_sites_end[];
> +extern s32 __cfi_sites[], __cfi_sites_end[];
>  extern s32 __ibt_endbr_seal[], __ibt_endbr_seal_end[];
>  extern struct alt_instr __alt_instructions[], __alt_instructions_end[];
>  extern s32 __smp_locks[], __smp_locks_end[];
> @@ -549,6 +553,315 @@ void __init_or_module noinline apply_ibt_endbr(s32 *start, s32 *end) { }
>  
>  #endif /* CONFIG_X86_KERNEL_IBT */
>  
> +#ifdef CONFIG_CFI_CLANG
> +/*
> + *  FineIBT                                         kCFI
> + *
> + *  __fineibt_\hash:
> + *    xor     \hash, %r10     # 7
> + *    jz      1f              # 2
> + *    ud2                     # 2
> + *  1:ret                     # 1
> + *    int3                    # 1
> + *
> + *
> + *  __cfi_\sym:                                     __cfi_\sym:
> + *                                                    int3; int3                              # 2
> + *    endbr                   # 4                     mov     \hash, %eax                     # 5
> + *    call    __fineibt_\hash # 5                     int3; int3                              # 2
> + *  \sym:                                           \sym:
> + *  ...                                             ...
> + *
> + *
> + *  caller:                                         caller:
> + *    movl    \hash, %r10d    # 6                     cmpl    \hash, -6(%r11)                 # 8
> + *    sub     $9, %r11        # 4                     je      1f                              # 2
> + *    nop2                    # 2                     ud2                                     # 2
> + *
> + *    call    *%r11           # 3                     call    __x86_indirect_thunk_r11        # 5
> + *    nop2                    # 2
> + */
> +
> +static DEFINE_XARRAY(cfi_hashes);
> +static int nr_cfi_hashes;
> +
> +static u32 decode_cfi_preamble(void *addr)
> +{
> +	u8 *p = addr;
> +
> +	if (p[0] == 0xcc && p[1] == 0xcc &&
> +	    p[2] == 0xb8 &&
> +	    p[7] == 0xcc && p[8] == 0xcc)
> +		return *(u32 *)(addr + 3);
> +
> +	return 0; /* invalid hash value */
> +}
> +
> +static u32 decode_cfi_caller(void *addr)
> +{
> +	u8 *p = addr;
> +
> +	if (((p[0] == 0x41 && p[1] == 0x81) ||
> +	     (p[0] == 0xeb && p[1] == 0x0a)) && p[2] == 0x7b &&
> +	    p[8] == 0x74 && p[9] == 0x02 &&
> +	    p[10] == 0x0f && p[11] == 0x0b)
> +		return *(u32 *)(addr + 4);
> +
> +	return 0; /* invalid hash value */
> +}
> +
> +// .cfi_sites
> +static int cfi_index_hashes(s32 *start, s32 *end)
> +{
> +	s32 *s;
> +
> +	for (s = start; s < end; s++) {
> +		void *addr = (void *)s + *s;
> +		void *xa;
> +		u32 hash;
> +
> +		hash = decode_cfi_preamble(addr);
> +		if (!hash) {
> +			//WARN();
> +			return -EINVAL;
> +		}
> +
> +		xa = xa_store(&cfi_hashes, hash, NULL, GFP_KERNEL);
> +		if (xa_is_err(xa)) {
> +			//WARN();
> +			return xa_err(xa);
> +		}
> +		nr_cfi_hashes++;
> +	}
> +
> +	return 0;
> +}
> +
> +asm (	".pushsection .rodata\n"
> +	"fineibt_template_start:\n"
> +	"	xorl	$0x12345678, %r10d\n"	// 7
> +	"	je	1f\n"			// 2
> +	"	ud2\n"				// 2
> +	"1:	ret\n"				// 1
> +	"	int3\n"
> +	"	int3\n"
> +	"	int3\n"
> +	"	int3\n"				// 4
> +	"fineibt_template_end:\n"
> +	".popsection\n"
> +    );
> +
> +extern u8 fineibt_template_start[];
> +extern u8 fineibt_template_end[];
> +
> +static int cfi_create_fineibt_stubs(void)
> +{
> +	size_t size = 16 * nr_cfi_hashes;
> +	int pages = 1 + ((size - 1) >> PAGE_SHIFT);
> +	void *text, *entry, *xa;
> +	unsigned long hash;
> +	int err = -ENOMEM;
> +
> +	text = module_alloc(size);
> +	if (!text)
> +		return err;
> +
> +	entry = text;
> +	xa_for_each(&cfi_hashes, hash, xa) {
> +
> +		memcpy(entry, fineibt_template_start, 16);
> +		*(u32 *)(entry + 3) = hash;
> +
> +		xa = xa_store(&cfi_hashes, hash, entry, GFP_KERNEL);
> +		if (xa_is_err(xa)) {
> +			err = xa_err(xa);
> +			goto err_alloc;
> +		}
> +		if (xa) {
> +			err = -EINVAL;
> +			goto err_alloc;
> +		}
> +
> +		entry += 16;
> +	}
> +
> +	set_memory_ro((unsigned long)text, pages);
> +	set_memory_x((unsigned long)text, pages);
> +
> +	return 0;
> +
> +err_alloc:
> +	module_memfree(text);
> +	return -EINVAL;
> +}
> +
> +// .retpoline_sites
> +static int cfi_disable_callers(s32 *start, s32 *end)
> +{
> +	/*
> +	 * Disable CFI by patching in a 2 byte JMP, this leaves the hash in
> +	 * tact for later usage. Also see decode_cfi_caller() and
> +	 * cfu_rewrite_callers().
> +	 */
> +	const u8 jmp12[] = { 0xeb, 0x0a };
> +	s32 *s;
> +
> +	for (s = start; s < end; s++) {
> +		void *addr = (void *)s + *s;
> +		u32 hash;
> +
> +		hash = decode_cfi_caller(addr - 12);
> +		if (!hash) {
> +			// WARN();
> +			return -EINVAL;
> +		}
> +
> +		text_poke_early(addr - 12, jmp12, 2);
> +	}
> +
> +	return 0;
> +}
> +
> +asm (	".pushsection .rodata\n"
> +	"fineibt_cfi_start:\n"
> +	"	endbr64\n"
> +	"	call fineibt_caller_start\n"
> +	"fineibt_cfi_end:"
> +	".popsection\n"
> +    );
> +
> +extern u8 fineibt_cfi_start[];
> +extern u8 fineibt_cfi_end[];
> +
> +// .cfi_sites
> +static int cfi_rewrite_cfi(s32 *start, s32 *end)
> +{
> +	s32 *s;
> +
> +	for (s = start; s < end; s++) {
> +		void *dest, *addr = (void *)s + *s;
> +		unsigned long index;
> +		u32 hash;
> +
> +		index = hash = decode_cfi_preamble(addr);
> +		dest = xa_find(&cfi_hashes, &index, hash, XA_PRESENT);
> +
> +		if (WARN_ON_ONCE(index != hash || !dest))
> +			return -EINVAL;
> +
> +		text_poke_early(addr, fineibt_cfi_start,
> +				(fineibt_cfi_end - fineibt_cfi_start));
> +
> +		__text_gen_insn(addr + 4,
> +				CALL_INSN_OPCODE, addr + 4,
> +				dest, CALL_INSN_SIZE);
> +	}
> +
> +	return 0;
> +}
> +
> +asm (	".pushsection .rodata\n"
> +	"fineibt_caller_start:\n"
> +	"	movl	$0x12345678, %r10d\n"
> +	"	sub	$9, %r11\n"
> +	"	.nops	2\n"
> +	"fineibt_caller_end:"
> +	".popsection\n"
> +    );
> +
> +extern u8 fineibt_caller_start[];
> +extern u8 fineibt_caller_end[];
> +
> +// .retpoline_sites
> +static int cfi_rewrite_callers(s32 *start, s32 *end)
> +{
> +	s32 *s;
> +
> +	for (s = start; s < end; s++) {
> +		void *addr = (void *)s + *s;
> +		u32 hash;
> +
> +		hash = decode_cfi_caller(addr - 12);
> +
> +		if (WARN_ON_ONCE(!hash))
> +			return -EINVAL;
> +
> +		text_poke_early(addr - 12, fineibt_caller_start,
> +				(fineibt_caller_end - fineibt_caller_end));
> +
> +		*(u32 *)(addr - 12 + 2) = hash;
> +
> +		/* rely on apply_retpolines() to rewrite the actual call */
> +	}
> +
> +	return 0;
> +}
> +
> +bool __ro_after_init ibt_broken = false;
> +
> +static void apply_fineibt(s32 *start_retpoline, s32 *end_retpoline,
> +			  s32 *start_cfi, s32 *end_cfi)
> +{
> +	int ret;
> +
> +	/* If IBT, use FineIBT */
> +	if (!HAS_KERNEL_IBT || !cpu_feature_enabled(X86_FEATURE_IBT))
> +		return;
> +
> +	/*
> +	 * Find and count all unique hash values.
> +	 */
> +	ret = cfi_index_hashes(start_cfi, end_cfi);
> +	if (ret)
> +		goto err;
> +
> +	/*
> +	 * Allocate module memory and write FineIBT stubs.
> +	 */
> +	ret = cfi_create_fineibt_stubs();
> +	if (ret)
> +		goto err;
> +
> +	/*
> +	 * Rewrite the callers to not use the __cfi_ stubs, such that we might
> +	 * rewrite them. Disables all CFI. If this succeeds but any of the
> +	 * later stages fails, we're CFI-less.
> +	 */
> +	ret = cfi_disable_callers(start_retpoline, end_retpoline);
> +	if (ret)
> +		goto err;
> +
> +	/*
> +	 * Rewrite the __cfi_ stubs from kCFI to FineIBT.
> +	 */
> +	ret = cfi_rewrite_cfi(start_cfi, end_cfi);
> +	if (ret)
> +		goto err;
> +
> +	/*
> +	 * Now that everything is in place; rewrite the callers to FineIBT.
> +	 */
> +	ret = cfi_rewrite_callers(start_retpoline, end_retpoline);
> +	if (ret)
> +		goto err;
> +
> +	return;
> +
> +err:
> +	pr_err("Something went horribly wrong trying to rewrite the CFI implementation.\n");
> +	/* must *NOT* enable IBT */
> +	ibt_broken = true;
> +}
> +
> +#else
> +
> +static void apply_fineibt(s32 *start_retpoline, s32 *end_retpoline,
> +			  s32 *start_cfi, s32 *end_cfi)
> +{
> +}
> +
> +#endif
> +
>  #ifdef CONFIG_SMP
>  static void alternatives_smp_lock(const s32 *start, const s32 *end,
>  				  u8 *text, u8 *text_end)
> @@ -855,6 +1168,9 @@ void __init alternative_instructions(void)
>  	 */
>  	apply_paravirt(__parainstructions, __parainstructions_end);
>  
> +	apply_fineibt(__retpoline_sites, __retpoline_sites_end,
> +		      __cfi_sites, __cfi_sites_end);
> +
>  	/*
>  	 * Rewrite the retpolines, must be done before alternatives since
>  	 * those can rewrite the retpoline thunks.
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index e342ae4db3c4..e4377256b952 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -630,6 +630,11 @@ static __always_inline void setup_cet(struct cpuinfo_x86 *c)
>  	    !cpu_feature_enabled(X86_FEATURE_IBT))
>  		return;
>  
> +#ifdef CONFIG_CFI_CLANG
> +	if (ibt_broken)
> +		return;
> +#endif
> +
>  	wrmsrl(MSR_IA32_S_CET, msr);
>  	cr4_set_bits(X86_CR4_CET);
>  
> diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
> index 7fda7f27e762..72ffc91ddd20 100644
> --- a/arch/x86/kernel/vmlinux.lds.S
> +++ b/arch/x86/kernel/vmlinux.lds.S
> @@ -294,6 +294,15 @@ SECTIONS
>  	}
>  #endif
>  
> +#if defined(CONFIG_CFI_CLANG) && defined(CONFIG_RETPOLINE) && defined(CONFIG_X86_KERNEL_IBT)
> +	. = ALIGN(8);
> +	.cfi_sites : AT(ADDR(.cfi_sites) - LOAD_OFFSET) {
> +		__cfi_sites = .;
> +		*(.cfi_sites)
> +		__cfi_sites_end = .;
> +	}
> +#endif
> +
>  	/*
>  	 * struct alt_inst entries. From the header (alternative.h):
>  	 * "Alternative instructions for different CPU types or capabilities"
> diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> index 88f005ae6dcc..edc8aecf229c 100644
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -797,6 +797,52 @@ static int create_ibt_endbr_seal_sections(struct objtool_file *file)
>  	return 0;
>  }
>  
> +static int create_cfi_sections(struct objtool_file *file)
> +{
> +	struct instruction *insn;
> +	struct section *sec;
> +	int idx;
> +
> +	sec = find_section_by_name(file->elf, ".cfi_sites");
> +	if (sec) {
> +		WARN("file already has .cfi_sites, skipping");
> +		return 0;
> +	}
> +
> +	idx = 0;
> +	list_for_each_entry(insn, &file->cfi_list, call_node)
> +		idx++;
> +
> +	if (!idx)
> +		return 0;
> +
> +	sec = elf_create_section(file->elf, ".cfi_sites", 0,
> +				 sizeof(int), idx);
> +	if (!sec) {
> +		WARN("elf_create_section: .cfi_sites");
> +		return -1;
> +	}
> +
> +	idx = 0;
> +	list_for_each_entry(insn, &file->cfi_list, call_node) {
> +
> +		int *site = (int *)sec->data->d_buf + idx;
> +		*site = 0;
> +
> +		if (elf_add_reloc_to_insn(file->elf, sec,
> +					  idx * sizeof(int),
> +					  R_X86_64_PC32,
> +					  insn->sec, insn->offset)) {
> +			WARN("elf_add_reloc_to_insn: .cfi_sites");
> +			return -1;
> +		}
> +
> +		idx++;
> +	}
> +
> +	return 0;
> +}
> +
>  static int create_mcount_loc_sections(struct objtool_file *file)
>  {
>  	struct section *sec;
> @@ -3301,6 +3347,7 @@ static int validate_branch(struct objtool_file *file, struct symbol *func,
>  {
>  	struct alternative *alt;
>  	struct instruction *next_insn, *prev_insn = NULL;
> +	struct instruction *first_insn = insn;
>  	struct section *sec;
>  	u8 visited;
>  	int ret;
> @@ -3312,8 +3359,19 @@ static int validate_branch(struct objtool_file *file, struct symbol *func,
>  
>  		if (func && insn->func && func != insn->func->pfunc) {
>  			/* Ignore KCFI type preambles, which always fall through */
> -			if (!strncmp(func->name, "__cfi_", 6))
> +			if (!strncmp(func->name, "__cfi_", 6)) {
> +				/*
> +				 * If the function has a __cfi_ preamble, the endbr
> +				 * will live in there.
> +				 */
> +				insn->noendbr = true;
> +				/*
> +				 * The preamble starts with INSN_TRAP,
> +				 * call_node cannot be used.
> +				 */
> +				list_add_tail(&first_insn->call_node, &file->cfi_list);
>  				return 0;
> +			}
>  
>  			WARN("%s() falls through to next function %s()",
>  			     func->name, insn->func->name);
> @@ -3953,6 +4011,13 @@ int check(struct objtool_file *file)
>  		warnings += ret;
>  	}
>  
> +	if (ibt && retpoline) {
> +		ret = create_cfi_sections(file);
> +		if (ret < 0)
> +			goto out;
> +		warnings += ret;
> +	}
> +
>  	if (stats) {
>  		printf("nr_insns_visited: %ld\n", nr_insns_visited);
>  		printf("nr_cfi: %ld\n", nr_cfi);
> diff --git a/tools/objtool/include/objtool/objtool.h b/tools/objtool/include/objtool/objtool.h
> index a6e72d916807..93f52e275fa6 100644
> --- a/tools/objtool/include/objtool/objtool.h
> +++ b/tools/objtool/include/objtool/objtool.h
> @@ -27,6 +27,7 @@ struct objtool_file {
>  	struct list_head static_call_list;
>  	struct list_head mcount_loc_list;
>  	struct list_head endbr_list;
> +	struct list_head cfi_list;
>  	bool ignore_unreachables, hints, rodata;
>  
>  	unsigned int nr_endbr;
> diff --git a/tools/objtool/objtool.c b/tools/objtool/objtool.c
> index 843ff3c2f28e..16ed3613b0e2 100644
> --- a/tools/objtool/objtool.c
> +++ b/tools/objtool/objtool.c
> @@ -129,6 +129,7 @@ struct objtool_file *objtool_open_read(const char *_objname)
>  	INIT_LIST_HEAD(&file.static_call_list);
>  	INIT_LIST_HEAD(&file.mcount_loc_list);
>  	INIT_LIST_HEAD(&file.endbr_list);
> +	INIT_LIST_HEAD(&file.cfi_list);
>  	file.ignore_unreachables = no_unreachable;
>  	file.hints = false;
>  

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
@ 2022-05-20 13:49           ` Matthew Wilcox
  0 siblings, 0 replies; 174+ messages in thread
From: Matthew Wilcox @ 2022-05-20 13:49 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Sami Tolvanen, linux-kernel, Kees Cook, Josh Poimboeuf, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Mon, May 16, 2022 at 02:58:44PM +0200, Peter Zijlstra wrote:
> @willy, how horribly broken is this xarray usage?

The xarray doesn't work very well as a hash ;-(  It has pretty much
pessimal memory usage if you have a good hash.  You'll end up allocating
essentially the entire 4 billion * ptr_size address space of the hash.
Can you use an rhashtable instead?

> ---
>  arch/x86/include/asm/traps.h            |   1 +
>  arch/x86/kernel/alternative.c           | 316 ++++++++++++++++++++++++++++++++
>  arch/x86/kernel/cpu/common.c            |   5 +
>  arch/x86/kernel/vmlinux.lds.S           |   9 +
>  tools/objtool/check.c                   |  67 ++++++-
>  tools/objtool/include/objtool/objtool.h |   1 +
>  tools/objtool/objtool.c                 |   1 +
>  7 files changed, 399 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/include/asm/traps.h b/arch/x86/include/asm/traps.h
> index 35317c5c551d..a423343cffbc 100644
> --- a/arch/x86/include/asm/traps.h
> +++ b/arch/x86/include/asm/traps.h
> @@ -19,6 +19,7 @@ asmlinkage __visible noinstr struct pt_regs *vc_switch_off_ist(struct pt_regs *e
>  #endif
>  
>  extern bool ibt_selftest(void);
> +extern bool ibt_broken;
>  
>  #ifdef CONFIG_X86_F00F_BUG
>  /* For handling the FOOF bug */
> diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
> index d374cb3cf024..abce4e78a1e0 100644
> --- a/arch/x86/kernel/alternative.c
> +++ b/arch/x86/kernel/alternative.c
> @@ -18,6 +18,9 @@
>  #include <linux/mmu_context.h>
>  #include <linux/bsearch.h>
>  #include <linux/sync_core.h>
> +#include <linux/moduleloader.h>
> +#include <linux/xarray.h>
> +#include <linux/set_memory.h>
>  #include <asm/text-patching.h>
>  #include <asm/alternative.h>
>  #include <asm/sections.h>
> @@ -115,6 +118,7 @@ static void __init_or_module add_nops(void *insns, unsigned int len)
>  }
>  
>  extern s32 __retpoline_sites[], __retpoline_sites_end[];
> +extern s32 __cfi_sites[], __cfi_sites_end[];
>  extern s32 __ibt_endbr_seal[], __ibt_endbr_seal_end[];
>  extern struct alt_instr __alt_instructions[], __alt_instructions_end[];
>  extern s32 __smp_locks[], __smp_locks_end[];
> @@ -549,6 +553,315 @@ void __init_or_module noinline apply_ibt_endbr(s32 *start, s32 *end) { }
>  
>  #endif /* CONFIG_X86_KERNEL_IBT */
>  
> +#ifdef CONFIG_CFI_CLANG
> +/*
> + *  FineIBT                                         kCFI
> + *
> + *  __fineibt_\hash:
> + *    xor     \hash, %r10     # 7
> + *    jz      1f              # 2
> + *    ud2                     # 2
> + *  1:ret                     # 1
> + *    int3                    # 1
> + *
> + *
> + *  __cfi_\sym:                                     __cfi_\sym:
> + *                                                    int3; int3                              # 2
> + *    endbr                   # 4                     mov     \hash, %eax                     # 5
> + *    call    __fineibt_\hash # 5                     int3; int3                              # 2
> + *  \sym:                                           \sym:
> + *  ...                                             ...
> + *
> + *
> + *  caller:                                         caller:
> + *    movl    \hash, %r10d    # 6                     cmpl    \hash, -6(%r11)                 # 8
> + *    sub     $9, %r11        # 4                     je      1f                              # 2
> + *    nop2                    # 2                     ud2                                     # 2
> + *
> + *    call    *%r11           # 3                     call    __x86_indirect_thunk_r11        # 5
> + *    nop2                    # 2
> + */
> +
> +static DEFINE_XARRAY(cfi_hashes);
> +static int nr_cfi_hashes;
> +
> +static u32 decode_cfi_preamble(void *addr)
> +{
> +	u8 *p = addr;
> +
> +	if (p[0] == 0xcc && p[1] == 0xcc &&
> +	    p[2] == 0xb8 &&
> +	    p[7] == 0xcc && p[8] == 0xcc)
> +		return *(u32 *)(addr + 3);
> +
> +	return 0; /* invalid hash value */
> +}
> +
> +static u32 decode_cfi_caller(void *addr)
> +{
> +	u8 *p = addr;
> +
> +	if (((p[0] == 0x41 && p[1] == 0x81) ||
> +	     (p[0] == 0xeb && p[1] == 0x0a)) && p[2] == 0x7b &&
> +	    p[8] == 0x74 && p[9] == 0x02 &&
> +	    p[10] == 0x0f && p[11] == 0x0b)
> +		return *(u32 *)(addr + 4);
> +
> +	return 0; /* invalid hash value */
> +}
> +
> +// .cfi_sites
> +static int cfi_index_hashes(s32 *start, s32 *end)
> +{
> +	s32 *s;
> +
> +	for (s = start; s < end; s++) {
> +		void *addr = (void *)s + *s;
> +		void *xa;
> +		u32 hash;
> +
> +		hash = decode_cfi_preamble(addr);
> +		if (!hash) {
> +			//WARN();
> +			return -EINVAL;
> +		}
> +
> +		xa = xa_store(&cfi_hashes, hash, NULL, GFP_KERNEL);
> +		if (xa_is_err(xa)) {
> +			//WARN();
> +			return xa_err(xa);
> +		}
> +		nr_cfi_hashes++;
> +	}
> +
> +	return 0;
> +}
> +
> +asm (	".pushsection .rodata\n"
> +	"fineibt_template_start:\n"
> +	"	xorl	$0x12345678, %r10d\n"	// 7
> +	"	je	1f\n"			// 2
> +	"	ud2\n"				// 2
> +	"1:	ret\n"				// 1
> +	"	int3\n"
> +	"	int3\n"
> +	"	int3\n"
> +	"	int3\n"				// 4
> +	"fineibt_template_end:\n"
> +	".popsection\n"
> +    );
> +
> +extern u8 fineibt_template_start[];
> +extern u8 fineibt_template_end[];
> +
> +static int cfi_create_fineibt_stubs(void)
> +{
> +	size_t size = 16 * nr_cfi_hashes;
> +	int pages = 1 + ((size - 1) >> PAGE_SHIFT);
> +	void *text, *entry, *xa;
> +	unsigned long hash;
> +	int err = -ENOMEM;
> +
> +	text = module_alloc(size);
> +	if (!text)
> +		return err;
> +
> +	entry = text;
> +	xa_for_each(&cfi_hashes, hash, xa) {
> +
> +		memcpy(entry, fineibt_template_start, 16);
> +		*(u32 *)(entry + 3) = hash;
> +
> +		xa = xa_store(&cfi_hashes, hash, entry, GFP_KERNEL);
> +		if (xa_is_err(xa)) {
> +			err = xa_err(xa);
> +			goto err_alloc;
> +		}
> +		if (xa) {
> +			err = -EINVAL;
> +			goto err_alloc;
> +		}
> +
> +		entry += 16;
> +	}
> +
> +	set_memory_ro((unsigned long)text, pages);
> +	set_memory_x((unsigned long)text, pages);
> +
> +	return 0;
> +
> +err_alloc:
> +	module_memfree(text);
> +	return -EINVAL;
> +}
> +
> +// .retpoline_sites
> +static int cfi_disable_callers(s32 *start, s32 *end)
> +{
> +	/*
> +	 * Disable CFI by patching in a 2 byte JMP, this leaves the hash in
> +	 * tact for later usage. Also see decode_cfi_caller() and
> +	 * cfu_rewrite_callers().
> +	 */
> +	const u8 jmp12[] = { 0xeb, 0x0a };
> +	s32 *s;
> +
> +	for (s = start; s < end; s++) {
> +		void *addr = (void *)s + *s;
> +		u32 hash;
> +
> +		hash = decode_cfi_caller(addr - 12);
> +		if (!hash) {
> +			// WARN();
> +			return -EINVAL;
> +		}
> +
> +		text_poke_early(addr - 12, jmp12, 2);
> +	}
> +
> +	return 0;
> +}
> +
> +asm (	".pushsection .rodata\n"
> +	"fineibt_cfi_start:\n"
> +	"	endbr64\n"
> +	"	call fineibt_caller_start\n"
> +	"fineibt_cfi_end:"
> +	".popsection\n"
> +    );
> +
> +extern u8 fineibt_cfi_start[];
> +extern u8 fineibt_cfi_end[];
> +
> +// .cfi_sites
> +static int cfi_rewrite_cfi(s32 *start, s32 *end)
> +{
> +	s32 *s;
> +
> +	for (s = start; s < end; s++) {
> +		void *dest, *addr = (void *)s + *s;
> +		unsigned long index;
> +		u32 hash;
> +
> +		index = hash = decode_cfi_preamble(addr);
> +		dest = xa_find(&cfi_hashes, &index, hash, XA_PRESENT);
> +
> +		if (WARN_ON_ONCE(index != hash || !dest))
> +			return -EINVAL;
> +
> +		text_poke_early(addr, fineibt_cfi_start,
> +				(fineibt_cfi_end - fineibt_cfi_start));
> +
> +		__text_gen_insn(addr + 4,
> +				CALL_INSN_OPCODE, addr + 4,
> +				dest, CALL_INSN_SIZE);
> +	}
> +
> +	return 0;
> +}
> +
> +asm (	".pushsection .rodata\n"
> +	"fineibt_caller_start:\n"
> +	"	movl	$0x12345678, %r10d\n"
> +	"	sub	$9, %r11\n"
> +	"	.nops	2\n"
> +	"fineibt_caller_end:"
> +	".popsection\n"
> +    );
> +
> +extern u8 fineibt_caller_start[];
> +extern u8 fineibt_caller_end[];
> +
> +// .retpoline_sites
> +static int cfi_rewrite_callers(s32 *start, s32 *end)
> +{
> +	s32 *s;
> +
> +	for (s = start; s < end; s++) {
> +		void *addr = (void *)s + *s;
> +		u32 hash;
> +
> +		hash = decode_cfi_caller(addr - 12);
> +
> +		if (WARN_ON_ONCE(!hash))
> +			return -EINVAL;
> +
> +		text_poke_early(addr - 12, fineibt_caller_start,
> +				(fineibt_caller_end - fineibt_caller_end));
> +
> +		*(u32 *)(addr - 12 + 2) = hash;
> +
> +		/* rely on apply_retpolines() to rewrite the actual call */
> +	}
> +
> +	return 0;
> +}
> +
> +bool __ro_after_init ibt_broken = false;
> +
> +static void apply_fineibt(s32 *start_retpoline, s32 *end_retpoline,
> +			  s32 *start_cfi, s32 *end_cfi)
> +{
> +	int ret;
> +
> +	/* If IBT, use FineIBT */
> +	if (!HAS_KERNEL_IBT || !cpu_feature_enabled(X86_FEATURE_IBT))
> +		return;
> +
> +	/*
> +	 * Find and count all unique hash values.
> +	 */
> +	ret = cfi_index_hashes(start_cfi, end_cfi);
> +	if (ret)
> +		goto err;
> +
> +	/*
> +	 * Allocate module memory and write FineIBT stubs.
> +	 */
> +	ret = cfi_create_fineibt_stubs();
> +	if (ret)
> +		goto err;
> +
> +	/*
> +	 * Rewrite the callers to not use the __cfi_ stubs, such that we might
> +	 * rewrite them. Disables all CFI. If this succeeds but any of the
> +	 * later stages fails, we're CFI-less.
> +	 */
> +	ret = cfi_disable_callers(start_retpoline, end_retpoline);
> +	if (ret)
> +		goto err;
> +
> +	/*
> +	 * Rewrite the __cfi_ stubs from kCFI to FineIBT.
> +	 */
> +	ret = cfi_rewrite_cfi(start_cfi, end_cfi);
> +	if (ret)
> +		goto err;
> +
> +	/*
> +	 * Now that everything is in place; rewrite the callers to FineIBT.
> +	 */
> +	ret = cfi_rewrite_callers(start_retpoline, end_retpoline);
> +	if (ret)
> +		goto err;
> +
> +	return;
> +
> +err:
> +	pr_err("Something went horribly wrong trying to rewrite the CFI implementation.\n");
> +	/* must *NOT* enable IBT */
> +	ibt_broken = true;
> +}
> +
> +#else
> +
> +static void apply_fineibt(s32 *start_retpoline, s32 *end_retpoline,
> +			  s32 *start_cfi, s32 *end_cfi)
> +{
> +}
> +
> +#endif
> +
>  #ifdef CONFIG_SMP
>  static void alternatives_smp_lock(const s32 *start, const s32 *end,
>  				  u8 *text, u8 *text_end)
> @@ -855,6 +1168,9 @@ void __init alternative_instructions(void)
>  	 */
>  	apply_paravirt(__parainstructions, __parainstructions_end);
>  
> +	apply_fineibt(__retpoline_sites, __retpoline_sites_end,
> +		      __cfi_sites, __cfi_sites_end);
> +
>  	/*
>  	 * Rewrite the retpolines, must be done before alternatives since
>  	 * those can rewrite the retpoline thunks.
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index e342ae4db3c4..e4377256b952 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -630,6 +630,11 @@ static __always_inline void setup_cet(struct cpuinfo_x86 *c)
>  	    !cpu_feature_enabled(X86_FEATURE_IBT))
>  		return;
>  
> +#ifdef CONFIG_CFI_CLANG
> +	if (ibt_broken)
> +		return;
> +#endif
> +
>  	wrmsrl(MSR_IA32_S_CET, msr);
>  	cr4_set_bits(X86_CR4_CET);
>  
> diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
> index 7fda7f27e762..72ffc91ddd20 100644
> --- a/arch/x86/kernel/vmlinux.lds.S
> +++ b/arch/x86/kernel/vmlinux.lds.S
> @@ -294,6 +294,15 @@ SECTIONS
>  	}
>  #endif
>  
> +#if defined(CONFIG_CFI_CLANG) && defined(CONFIG_RETPOLINE) && defined(CONFIG_X86_KERNEL_IBT)
> +	. = ALIGN(8);
> +	.cfi_sites : AT(ADDR(.cfi_sites) - LOAD_OFFSET) {
> +		__cfi_sites = .;
> +		*(.cfi_sites)
> +		__cfi_sites_end = .;
> +	}
> +#endif
> +
>  	/*
>  	 * struct alt_inst entries. From the header (alternative.h):
>  	 * "Alternative instructions for different CPU types or capabilities"
> diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> index 88f005ae6dcc..edc8aecf229c 100644
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -797,6 +797,52 @@ static int create_ibt_endbr_seal_sections(struct objtool_file *file)
>  	return 0;
>  }
>  
> +static int create_cfi_sections(struct objtool_file *file)
> +{
> +	struct instruction *insn;
> +	struct section *sec;
> +	int idx;
> +
> +	sec = find_section_by_name(file->elf, ".cfi_sites");
> +	if (sec) {
> +		WARN("file already has .cfi_sites, skipping");
> +		return 0;
> +	}
> +
> +	idx = 0;
> +	list_for_each_entry(insn, &file->cfi_list, call_node)
> +		idx++;
> +
> +	if (!idx)
> +		return 0;
> +
> +	sec = elf_create_section(file->elf, ".cfi_sites", 0,
> +				 sizeof(int), idx);
> +	if (!sec) {
> +		WARN("elf_create_section: .cfi_sites");
> +		return -1;
> +	}
> +
> +	idx = 0;
> +	list_for_each_entry(insn, &file->cfi_list, call_node) {
> +
> +		int *site = (int *)sec->data->d_buf + idx;
> +		*site = 0;
> +
> +		if (elf_add_reloc_to_insn(file->elf, sec,
> +					  idx * sizeof(int),
> +					  R_X86_64_PC32,
> +					  insn->sec, insn->offset)) {
> +			WARN("elf_add_reloc_to_insn: .cfi_sites");
> +			return -1;
> +		}
> +
> +		idx++;
> +	}
> +
> +	return 0;
> +}
> +
>  static int create_mcount_loc_sections(struct objtool_file *file)
>  {
>  	struct section *sec;
> @@ -3301,6 +3347,7 @@ static int validate_branch(struct objtool_file *file, struct symbol *func,
>  {
>  	struct alternative *alt;
>  	struct instruction *next_insn, *prev_insn = NULL;
> +	struct instruction *first_insn = insn;
>  	struct section *sec;
>  	u8 visited;
>  	int ret;
> @@ -3312,8 +3359,19 @@ static int validate_branch(struct objtool_file *file, struct symbol *func,
>  
>  		if (func && insn->func && func != insn->func->pfunc) {
>  			/* Ignore KCFI type preambles, which always fall through */
> -			if (!strncmp(func->name, "__cfi_", 6))
> +			if (!strncmp(func->name, "__cfi_", 6)) {
> +				/*
> +				 * If the function has a __cfi_ preamble, the endbr
> +				 * will live in there.
> +				 */
> +				insn->noendbr = true;
> +				/*
> +				 * The preamble starts with INSN_TRAP,
> +				 * call_node cannot be used.
> +				 */
> +				list_add_tail(&first_insn->call_node, &file->cfi_list);
>  				return 0;
> +			}
>  
>  			WARN("%s() falls through to next function %s()",
>  			     func->name, insn->func->name);
> @@ -3953,6 +4011,13 @@ int check(struct objtool_file *file)
>  		warnings += ret;
>  	}
>  
> +	if (ibt && retpoline) {
> +		ret = create_cfi_sections(file);
> +		if (ret < 0)
> +			goto out;
> +		warnings += ret;
> +	}
> +
>  	if (stats) {
>  		printf("nr_insns_visited: %ld\n", nr_insns_visited);
>  		printf("nr_cfi: %ld\n", nr_cfi);
> diff --git a/tools/objtool/include/objtool/objtool.h b/tools/objtool/include/objtool/objtool.h
> index a6e72d916807..93f52e275fa6 100644
> --- a/tools/objtool/include/objtool/objtool.h
> +++ b/tools/objtool/include/objtool/objtool.h
> @@ -27,6 +27,7 @@ struct objtool_file {
>  	struct list_head static_call_list;
>  	struct list_head mcount_loc_list;
>  	struct list_head endbr_list;
> +	struct list_head cfi_list;
>  	bool ignore_unreachables, hints, rodata;
>  
>  	unsigned int nr_endbr;
> diff --git a/tools/objtool/objtool.c b/tools/objtool/objtool.c
> index 843ff3c2f28e..16ed3613b0e2 100644
> --- a/tools/objtool/objtool.c
> +++ b/tools/objtool/objtool.c
> @@ -129,6 +129,7 @@ struct objtool_file *objtool_open_read(const char *_objname)
>  	INIT_LIST_HEAD(&file.static_call_list);
>  	INIT_LIST_HEAD(&file.mcount_loc_list);
>  	INIT_LIST_HEAD(&file.endbr_list);
> +	INIT_LIST_HEAD(&file.cfi_list);
>  	file.ignore_unreachables = no_unreachable;
>  	file.hints = false;
>  

_______________________________________________
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] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
  2022-05-16 20:37             ` Peter Zijlstra
@ 2022-05-25 20:02               ` Kees Cook
  -1 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-25 20:02 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Sami Tolvanen, linux-kernel, Josh Poimboeuf, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Mon, May 16, 2022 at 10:37:23PM +0200, Peter Zijlstra wrote:
> On Mon, May 16, 2022 at 12:39:19PM -0700, Sami Tolvanen wrote:
> 
> > > > With the current compiler patch, LLVM sets up function arguments after
> > > > the CFI check. if it's a problem, we can look into changing that.
> > >
> > > Yes, please fix that. Again see that same patch for why this is a
> > > problem. Objtool can trivially find retpoline calls, but finding this
> > > kCFI gadget is going to be hard work. If you ensure they're
> > > unconditionally stuck together, then the problem goes away find one,
> > > finds the other.
> > 
> > You can use .kcfi_traps to locate the check right now, but I agree,
> > it's not quite ideal.
> 
> Oohh, indeed.
> [...]

Hi Peter,

Sami investigated moving the CFI check after arg setup, and found that
to do it means making LLVM's CFI logic no longer both architecture
and call-type agnostic. The CFI logic needs put at a lower level,
requiring it be done in per-architecture code, and then additionally
per-call-type. (And by per-call-type, AIUI, this means various types of
indirect calls: standard, tail-call, etc.) Sami has it all working for
x86, but I'm concerned about the risk/benefit in doing it this way. I
only see down-sides:

- Linux cannot enable CFI for a new architecture without also
  implementing it within LLVM first.

- LLVM CFI code becomes more complex, making it harder to
  maintain/bug-fix/etc.

I actually see the first issue as the larger problem: I want to make it
easy for the kernel to use CFI, rather than harder. :P The first user
of CFI already cleared the way for other architectures by adjusting the
bulk of core kernel code, etc, so adding another architecture should be
as trivial as possible, and not require yet newer releases of LLVM, etc,
etc.

So, since using .kcfi_traps already solves the issue for finding the
checks, can we not require moving the CFI check? I think it would be a
mistake to have to do that.

-Kees

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 174+ messages in thread

* Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
@ 2022-05-25 20:02               ` Kees Cook
  0 siblings, 0 replies; 174+ messages in thread
From: Kees Cook @ 2022-05-25 20:02 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Sami Tolvanen, linux-kernel, Josh Poimboeuf, x86,
	Catalin Marinas, Will Deacon, Mark Rutland, Nathan Chancellor,
	Nick Desaulniers, Joao Moreira, Sedat Dilek, Steven Rostedt,
	linux-hardening, linux-arm-kernel, llvm

On Mon, May 16, 2022 at 10:37:23PM +0200, Peter Zijlstra wrote:
> On Mon, May 16, 2022 at 12:39:19PM -0700, Sami Tolvanen wrote:
> 
> > > > With the current compiler patch, LLVM sets up function arguments after
> > > > the CFI check. if it's a problem, we can look into changing that.
> > >
> > > Yes, please fix that. Again see that same patch for why this is a
> > > problem. Objtool can trivially find retpoline calls, but finding this
> > > kCFI gadget is going to be hard work. If you ensure they're
> > > unconditionally stuck together, then the problem goes away find one,
> > > finds the other.
> > 
> > You can use .kcfi_traps to locate the check right now, but I agree,
> > it's not quite ideal.
> 
> Oohh, indeed.
> [...]

Hi Peter,

Sami investigated moving the CFI check after arg setup, and found that
to do it means making LLVM's CFI logic no longer both architecture
and call-type agnostic. The CFI logic needs put at a lower level,
requiring it be done in per-architecture code, and then additionally
per-call-type. (And by per-call-type, AIUI, this means various types of
indirect calls: standard, tail-call, etc.) Sami has it all working for
x86, but I'm concerned about the risk/benefit in doing it this way. I
only see down-sides:

- Linux cannot enable CFI for a new architecture without also
  implementing it within LLVM first.

- LLVM CFI code becomes more complex, making it harder to
  maintain/bug-fix/etc.

I actually see the first issue as the larger problem: I want to make it
easy for the kernel to use CFI, rather than harder. :P The first user
of CFI already cleared the way for other architectures by adjusting the
bulk of core kernel code, etc, so adding another architecture should be
as trivial as possible, and not require yet newer releases of LLVM, etc,
etc.

So, since using .kcfi_traps already solves the issue for finding the
checks, can we not require moving the CFI check? I think it would be a
mistake to have to do that.

-Kees

-- 
Kees Cook

_______________________________________________
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] 174+ messages in thread

end of thread, other threads:[~2022-05-25 20:04 UTC | newest]

Thread overview: 174+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-13 20:21 [RFC PATCH v2 00/21] KCFI support Sami Tolvanen
2022-05-13 20:21 ` Sami Tolvanen
2022-05-13 20:21 ` [RFC PATCH v2 01/21] efi/libstub: Filter out CC_FLAGS_CFI Sami Tolvanen
2022-05-13 20:21   ` Sami Tolvanen
2022-05-14 21:42   ` Kees Cook
2022-05-14 21:42     ` Kees Cook
2022-05-16 15:44     ` Sami Tolvanen
2022-05-16 15:44       ` Sami Tolvanen
2022-05-13 20:21 ` [RFC PATCH v2 02/21] arm64/vdso: " Sami Tolvanen
2022-05-13 20:21   ` Sami Tolvanen
2022-05-14 21:42   ` Kees Cook
2022-05-14 21:42     ` Kees Cook
2022-05-13 20:21 ` [RFC PATCH v2 03/21] kallsyms: Ignore __kcfi_typeid_ Sami Tolvanen
2022-05-13 20:21   ` Sami Tolvanen
2022-05-14 21:43   ` Kees Cook
2022-05-14 21:43     ` Kees Cook
2022-05-13 20:21 ` [RFC PATCH v2 04/21] cfi: Remove CONFIG_CFI_CLANG_SHADOW Sami Tolvanen
2022-05-13 20:21   ` Sami Tolvanen
2022-05-14 21:43   ` Kees Cook
2022-05-14 21:43     ` Kees Cook
2022-05-13 20:21 ` [RFC PATCH v2 05/21] cfi: Drop __CFI_ADDRESSABLE Sami Tolvanen
2022-05-13 20:21   ` Sami Tolvanen
2022-05-14 21:44   ` Kees Cook
2022-05-14 21:44     ` Kees Cook
2022-05-13 20:21 ` [RFC PATCH v2 06/21] cfi: Switch to -fsanitize=kcfi Sami Tolvanen
2022-05-13 20:21   ` Sami Tolvanen
2022-05-14 21:46   ` Kees Cook
2022-05-14 21:46     ` Kees Cook
2022-05-15  3:41   ` Kees Cook
2022-05-15  3:41     ` Kees Cook
2022-05-13 20:21 ` [RFC PATCH v2 07/21] cfi: Add type helper macros Sami Tolvanen
2022-05-13 20:21   ` Sami Tolvanen
2022-05-14 21:49   ` Kees Cook
2022-05-14 21:49     ` Kees Cook
2022-05-16 12:28     ` Rasmus Villemoes
2022-05-16 12:28       ` Rasmus Villemoes
2022-05-16 16:23       ` Sami Tolvanen
2022-05-16 16:23         ` Sami Tolvanen
2022-05-16 16:04     ` Sami Tolvanen
2022-05-16 16:04       ` Sami Tolvanen
2022-05-13 20:21 ` [RFC PATCH v2 08/21] psci: Fix the function type for psci_initcall_t Sami Tolvanen
2022-05-13 20:21   ` Sami Tolvanen
2022-05-14 21:50   ` Kees Cook
2022-05-14 21:50     ` Kees Cook
2022-05-16 15:44     ` Sami Tolvanen
2022-05-16 15:44       ` Sami Tolvanen
2022-05-17  8:47   ` Mark Rutland
2022-05-17  8:47     ` Mark Rutland
2022-05-13 20:21 ` [RFC PATCH v2 09/21] arm64: Add types to indirect called assembly functions Sami Tolvanen
2022-05-13 20:21   ` Sami Tolvanen
2022-05-14 21:50   ` Kees Cook
2022-05-14 21:50     ` Kees Cook
2022-05-13 20:21 ` [RFC PATCH v2 10/21] arm64: Add CFI error handling Sami Tolvanen
2022-05-13 20:21   ` Sami Tolvanen
2022-05-14 21:51   ` Kees Cook
2022-05-14 21:51     ` Kees Cook
2022-05-16 16:24     ` Sami Tolvanen
2022-05-16 16:24       ` Sami Tolvanen
2022-05-13 20:21 ` [RFC PATCH v2 11/21] arm64: Drop unneeded __nocfi attributes Sami Tolvanen
2022-05-13 20:21   ` Sami Tolvanen
2022-05-14 21:54   ` Kees Cook
2022-05-14 21:54     ` Kees Cook
2022-05-16 16:28     ` Sami Tolvanen
2022-05-16 16:28       ` Sami Tolvanen
2022-05-13 20:21 ` [RFC PATCH v2 12/21] treewide: Drop function_nocfi Sami Tolvanen
2022-05-13 20:21   ` Sami Tolvanen
2022-05-14 21:54   ` Kees Cook
2022-05-14 21:54     ` Kees Cook
2022-05-13 20:21 ` [RFC PATCH v2 13/21] treewide: Drop WARN_ON_FUNCTION_MISMATCH Sami Tolvanen
2022-05-13 20:21   ` Sami Tolvanen
2022-05-14 21:54   ` Kees Cook
2022-05-14 21:54     ` Kees Cook
2022-05-13 20:21 ` [RFC PATCH v2 14/21] treewide: Drop __cficanonical Sami Tolvanen
2022-05-13 20:21   ` Sami Tolvanen
2022-05-14 21:56   ` Kees Cook
2022-05-14 21:56     ` Kees Cook
2022-05-16 16:32     ` Sami Tolvanen
2022-05-16 16:32       ` Sami Tolvanen
2022-05-13 20:21 ` [RFC PATCH v2 15/21] objtool: Don't warn about __cfi_ preambles falling through Sami Tolvanen
2022-05-13 20:21   ` Sami Tolvanen
2022-05-14 21:56   ` Kees Cook
2022-05-14 21:56     ` Kees Cook
2022-05-13 20:21 ` [RFC PATCH v2 16/21] x86/tools/relocs: Ignore __kcfi_typeid_ relocations Sami Tolvanen
2022-05-13 20:21   ` Sami Tolvanen
2022-05-14 21:57   ` Kees Cook
2022-05-14 21:57     ` Kees Cook
2022-05-13 20:21 ` [RFC PATCH v2 17/21] x86: Add types to indirectly called assembly functions Sami Tolvanen
2022-05-13 20:21   ` Sami Tolvanen
2022-05-14 21:58   ` Kees Cook
2022-05-14 21:58     ` Kees Cook
2022-05-13 20:21 ` [RFC PATCH v2 18/21] x86/purgatory: Disable CFI Sami Tolvanen
2022-05-13 20:21   ` Sami Tolvanen
2022-05-14 21:58   ` Kees Cook
2022-05-14 21:58     ` Kees Cook
2022-05-13 20:21 ` [RFC PATCH v2 19/21] x86/vdso: " Sami Tolvanen
2022-05-13 20:21   ` Sami Tolvanen
2022-05-14 21:58   ` Kees Cook
2022-05-14 21:58     ` Kees Cook
2022-05-13 20:21 ` [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG Sami Tolvanen
2022-05-13 20:21   ` Sami Tolvanen
2022-05-14 22:02   ` Kees Cook
2022-05-14 22:02     ` Kees Cook
2022-05-16 18:57     ` Sami Tolvanen
2022-05-16 18:57       ` Sami Tolvanen
2022-05-15  3:19   ` Kees Cook
2022-05-15  3:19     ` Kees Cook
2022-05-16  8:32   ` David Laight
2022-05-16  8:32     ` David Laight
2022-05-16 16:39     ` Sami Tolvanen
2022-05-16 16:39       ` Sami Tolvanen
2022-05-16 21:32       ` David Laight
2022-05-16 21:32         ` David Laight
2022-05-16 21:44         ` Peter Zijlstra
2022-05-16 21:44           ` Peter Zijlstra
2022-05-16 22:03           ` Sami Tolvanen
2022-05-16 22:03             ` Sami Tolvanen
2022-05-17  6:44             ` Peter Zijlstra
2022-05-17  6:44               ` Peter Zijlstra
2022-05-17 20:36               ` Sami Tolvanen
2022-05-17 20:36                 ` Sami Tolvanen
2022-05-17  7:56             ` David Laight
2022-05-17  7:56               ` David Laight
2022-05-16  9:54   ` Peter Zijlstra
2022-05-16  9:54     ` Peter Zijlstra
2022-05-16 11:45     ` Peter Zijlstra
2022-05-16 11:45       ` Peter Zijlstra
2022-05-16 12:58       ` Peter Zijlstra
2022-05-16 12:58         ` Peter Zijlstra
2022-05-20 13:49         ` Matthew Wilcox
2022-05-20 13:49           ` Matthew Wilcox
2022-05-16 17:15     ` Sami Tolvanen
2022-05-16 17:15       ` Sami Tolvanen
2022-05-16 18:30       ` Peter Zijlstra
2022-05-16 18:30         ` Peter Zijlstra
2022-05-16 19:39         ` Sami Tolvanen
2022-05-16 19:39           ` Sami Tolvanen
2022-05-16 20:37           ` Peter Zijlstra
2022-05-16 20:37             ` Peter Zijlstra
2022-05-25 20:02             ` Kees Cook
2022-05-25 20:02               ` Kees Cook
2022-05-16 22:59         ` Kees Cook
2022-05-16 22:59           ` Kees Cook
2022-05-17  8:05           ` Peter Zijlstra
2022-05-17  8:05             ` Peter Zijlstra
2022-05-17  8:32             ` Joao Moreira
2022-05-17  8:32               ` Joao Moreira
2022-05-17  8:40             ` Peter Zijlstra
2022-05-17  8:40               ` Peter Zijlstra
2022-05-17  8:48               ` David Laight
2022-05-17  8:48                 ` David Laight
2022-05-17  9:38                 ` Peter Zijlstra
2022-05-17  9:38                   ` Peter Zijlstra
2022-05-13 20:21 ` [RFC PATCH v2 21/21] init: Drop __nocfi from __init Sami Tolvanen
2022-05-13 20:21   ` Sami Tolvanen
2022-05-14 22:03   ` Kees Cook
2022-05-14 22:03     ` Kees Cook
2022-05-16 17:16     ` Sami Tolvanen
2022-05-16 17:16       ` Sami Tolvanen
     [not found] ` <CA+icZUWr+-HjMvY1VZf+nqjTadxSTDciux0Y5Y-+p_j4o7CmXg@mail.gmail.com>
2022-05-16 17:57   ` [RFC PATCH v2 00/21] KCFI support Sami Tolvanen
2022-05-16 17:57     ` Sami Tolvanen
2022-05-17  7:33     ` Sedat Dilek
2022-05-17  7:33       ` Sedat Dilek
2022-05-17 18:49       ` Nathan Chancellor
2022-05-17 18:49         ` Nathan Chancellor
2022-05-19  9:01         ` Sedat Dilek
2022-05-19  9:01           ` Sedat Dilek
2022-05-19 20:26           ` Nathan Chancellor
2022-05-19 20:26             ` Nathan Chancellor
2022-05-19 20:41             ` Sami Tolvanen
2022-05-19 20:41               ` Sami Tolvanen
2022-05-17  8:57 ` Peter Zijlstra
2022-05-17  8:57   ` Peter Zijlstra
2022-05-17 20:25   ` Sami Tolvanen
2022-05-17 20:25     ` Sami Tolvanen

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.