All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Kees Cook <keescook@chromium.org>
Cc: Sami Tolvanen <samitolvanen@google.com>,
	linux-kernel@vger.kernel.org,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	x86@kernel.org, Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Joao Moreira <joao@overdrivepizza.com>,
	Sedat Dilek <sedat.dilek@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-hardening@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, llvm@lists.linux.dev
Subject: Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
Date: Tue, 17 May 2022 10:05:17 +0200	[thread overview]
Message-ID: <YoNXPVQRvIFS81aW@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <202205161531.3339CA95@keescook>

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.

WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Kees Cook <keescook@chromium.org>
Cc: Sami Tolvanen <samitolvanen@google.com>,
	linux-kernel@vger.kernel.org,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	x86@kernel.org, Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Joao Moreira <joao@overdrivepizza.com>,
	Sedat Dilek <sedat.dilek@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-hardening@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, llvm@lists.linux.dev
Subject: Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG
Date: Tue, 17 May 2022 10:05:17 +0200	[thread overview]
Message-ID: <YoNXPVQRvIFS81aW@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <202205161531.3339CA95@keescook>

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

  reply	other threads:[~2022-05-17  8:05 UTC|newest]

Thread overview: 174+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YoNXPVQRvIFS81aW@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=catalin.marinas@arm.com \
    --cc=joao@overdrivepizza.com \
    --cc=jpoimboe@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=mark.rutland@arm.com \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=rostedt@goodmis.org \
    --cc=samitolvanen@google.com \
    --cc=sedat.dilek@gmail.com \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.