All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kenton Groombridge <me@concord.sh>
To: Sami Tolvanen <samitolvanen@google.com>
Cc: linux-kernel@vger.kernel.org, Kees Cook <keescook@chromium.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	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 00/21] KCFI support
Date: Sat, 30 Apr 2022 12:07:50 -0400	[thread overview]
Message-ID: <20220430160750.ov7ddsq2vzibwrju@bubbles> (raw)
In-Reply-To: <20220429203644.2868448-1-samitolvanen@google.com>


[-- Attachment #1.1: Type: text/plain, Size: 1010 bytes --]

On 22/04/29 01:36PM, 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 patches are here:
> 
>   https://reviews.llvm.org/D119296
>   https://reviews.llvm.org/D124211

Many thanks for continuing to work on this! As a user who has been
following the evolution of this patch series for a while now, I have a
couple of burning questions:

1) The LLVM patch says that kCFI is not compatible with execute-only
memory. Is there a plan ahead for kCFI if and when execute-only memory
is implemented?

2) kCFI only checks indirect calls while Clang's traditional CFI has
more schemes like bad cast checking and so on. Are there any major
security tradeoffs as a result of this?

V/R

Kenton Groombridge

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Kenton Groombridge <me@concord.sh>
To: Sami Tolvanen <samitolvanen@google.com>
Cc: linux-kernel@vger.kernel.org, Kees Cook <keescook@chromium.org>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	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 00/21] KCFI support
Date: Sat, 30 Apr 2022 12:07:50 -0400	[thread overview]
Message-ID: <20220430160750.ov7ddsq2vzibwrju@bubbles> (raw)
In-Reply-To: <20220429203644.2868448-1-samitolvanen@google.com>

[-- Attachment #1: Type: text/plain, Size: 1010 bytes --]

On 22/04/29 01:36PM, 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 patches are here:
> 
>   https://reviews.llvm.org/D119296
>   https://reviews.llvm.org/D124211

Many thanks for continuing to work on this! As a user who has been
following the evolution of this patch series for a while now, I have a
couple of burning questions:

1) The LLVM patch says that kCFI is not compatible with execute-only
memory. Is there a plan ahead for kCFI if and when execute-only memory
is implemented?

2) kCFI only checks indirect calls while Clang's traditional CFI has
more schemes like bad cast checking and so on. Are there any major
security tradeoffs as a result of this?

V/R

Kenton Groombridge

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

  parent reply	other threads:[~2022-04-30 16:09 UTC|newest]

Thread overview: 100+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-29 20:36 [RFC PATCH 00/21] KCFI support Sami Tolvanen
2022-04-29 20:36 ` Sami Tolvanen
2022-04-29 20:36 ` [RFC PATCH 01/21] efi/libstub: Filter out CC_FLAGS_CFI Sami Tolvanen
2022-04-29 20:36   ` Sami Tolvanen
2022-04-29 20:36 ` [RFC PATCH 02/21] arm64/vdso: " Sami Tolvanen
2022-04-29 20:36   ` Sami Tolvanen
2022-04-29 20:36 ` [RFC PATCH 03/21] kallsyms: Ignore __kcfi_typeid_ Sami Tolvanen
2022-04-29 20:36   ` Sami Tolvanen
2022-04-29 20:36 ` [RFC PATCH 04/21] cfi: Remove CONFIG_CFI_CLANG_SHADOW Sami Tolvanen
2022-04-29 20:36   ` Sami Tolvanen
2022-04-29 20:36 ` [RFC PATCH 05/21] cfi: Drop __CFI_ADDRESSABLE Sami Tolvanen
2022-04-29 20:36   ` Sami Tolvanen
2022-04-29 20:36 ` [RFC PATCH 06/21] cfi: Switch to -fsanitize=kcfi Sami Tolvanen
2022-04-29 20:36   ` Sami Tolvanen
2022-04-30  9:09   ` Peter Zijlstra
2022-04-30  9:09     ` Peter Zijlstra
2022-04-29 20:36 ` [RFC PATCH 07/21] cfi: Add type helper macros Sami Tolvanen
2022-04-29 20:36   ` Sami Tolvanen
2022-04-29 20:36 ` [RFC PATCH 08/21] arm64/crypto: Add types to indirect called assembly functions Sami Tolvanen
2022-04-29 20:36   ` Sami Tolvanen
2022-04-29 20:36 ` [RFC PATCH 09/21] arm64: Add CFI error handling Sami Tolvanen
2022-04-29 20:36   ` Sami Tolvanen
2022-05-05 15:44   ` Mark Rutland
2022-05-05 15:44     ` Mark Rutland
2022-05-05 16:23     ` Sami Tolvanen
2022-05-05 16:23       ` Sami Tolvanen
2022-04-29 20:36 ` [RFC PATCH 10/21] treewide: Drop function_nocfi Sami Tolvanen
2022-04-29 20:36   ` Sami Tolvanen
2022-05-05 16:30   ` Mark Rutland
2022-05-05 16:30     ` Mark Rutland
2022-05-05 16:51     ` Sami Tolvanen
2022-05-05 16:51       ` Sami Tolvanen
2022-05-05 18:03       ` Mark Rutland
2022-05-05 18:03         ` Mark Rutland
2022-04-29 20:36 ` [RFC PATCH 11/21] treewide: Drop WARN_ON_FUNCTION_MISMATCH Sami Tolvanen
2022-04-29 20:36   ` Sami Tolvanen
2022-04-29 20:36 ` [RFC PATCH 12/21] treewide: Drop __cficanonical Sami Tolvanen
2022-04-29 20:36   ` Sami Tolvanen
2022-04-29 20:36 ` [RFC PATCH 13/21] cfi: Add the cfi_unchecked macro Sami Tolvanen
2022-04-29 20:36   ` Sami Tolvanen
2022-04-29 20:36 ` [RFC PATCH 14/21] treewide: static_call: Pass call arguments to the macro Sami Tolvanen
2022-04-29 20:36   ` Sami Tolvanen
2022-04-29 23:21   ` Peter Zijlstra
2022-04-29 23:21     ` Peter Zijlstra
2022-04-30  0:49     ` Sami Tolvanen
2022-04-30  0:49       ` Sami Tolvanen
2022-05-02  7:46       ` Peter Zijlstra
2022-05-02  7:46         ` Peter Zijlstra
2022-04-29 20:36 ` [RFC PATCH 15/21] static_call: Use cfi_unchecked Sami Tolvanen
2022-04-29 20:36   ` Sami Tolvanen
2022-04-29 23:23   ` Peter Zijlstra
2022-04-29 23:23     ` Peter Zijlstra
2022-04-29 20:36 ` [RFC PATCH 16/21] objtool: Add support for CONFIG_CFI_CLANG Sami Tolvanen
2022-04-29 20:36   ` Sami Tolvanen
2022-04-29 23:30   ` Peter Zijlstra
2022-04-29 23:30     ` Peter Zijlstra
2022-04-30  1:00     ` Sami Tolvanen
2022-04-30  1:00       ` Sami Tolvanen
2022-04-29 20:36 ` [RFC PATCH 17/21] x86/tools/relocs: Ignore __kcfi_typeid_ relocations Sami Tolvanen
2022-04-29 20:36   ` Sami Tolvanen
2022-04-29 20:36 ` [RFC PATCH 18/21] x86: Add types to indirect called assembly functions Sami Tolvanen
2022-04-29 20:36   ` Sami Tolvanen
2022-04-29 20:36 ` [RFC PATCH 19/21] x86/purgatory: Disable CFI Sami Tolvanen
2022-04-29 20:36   ` Sami Tolvanen
2022-04-29 20:36 ` [RFC PATCH 20/21] x86/vdso: " Sami Tolvanen
2022-04-29 20:36   ` Sami Tolvanen
2022-04-29 20:36 ` [RFC PATCH 21/21] x86: Add support for CONFIG_CFI_CLANG Sami Tolvanen
2022-04-29 20:36   ` Sami Tolvanen
2022-04-30  9:24   ` Peter Zijlstra
2022-04-30  9:24     ` Peter Zijlstra
2022-05-02 15:20     ` Sami Tolvanen
2022-05-02 15:20       ` Sami Tolvanen
2022-04-29 22:53 ` [RFC PATCH 00/21] KCFI support Kees Cook
2022-04-29 22:53   ` Kees Cook
2022-04-30  9:02   ` Peter Zijlstra
2022-04-30  9:02     ` Peter Zijlstra
2022-05-02 15:22     ` Sami Tolvanen
2022-05-02 15:22       ` Sami Tolvanen
2022-05-02 19:55       ` Peter Zijlstra
2022-05-02 19:55         ` Peter Zijlstra
2022-05-03 22:35         ` Peter Collingbourne
2022-05-03 22:35           ` Peter Collingbourne
2022-05-04  7:34           ` Peter Zijlstra
2022-05-04  7:34             ` Peter Zijlstra
2022-04-30 16:07 ` Kenton Groombridge [this message]
2022-04-30 16:07   ` Kenton Groombridge
2022-05-02 15:31   ` Sami Tolvanen
2022-05-02 15:31     ` Sami Tolvanen
2022-05-04 16:17 ` Mark Rutland
2022-05-04 16:17   ` Mark Rutland
2022-05-04 16:41   ` Sami Tolvanen
2022-05-04 16:41     ` Sami Tolvanen
2022-05-04 20:17     ` Sami Tolvanen
2022-05-04 20:17       ` Sami Tolvanen
2022-05-05 12:36       ` Mark Rutland
2022-05-05 12:36         ` Mark Rutland
2022-05-05 16:00         ` Sami Tolvanen
2022-05-05 16:00           ` Sami Tolvanen
2022-05-05 17:14           ` Mark Rutland
2022-05-05 17:14             ` Mark Rutland

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=20220430160750.ov7ddsq2vzibwrju@bubbles \
    --to=me@concord.sh \
    --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=peterz@infradead.org \
    --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.