From: Kees Cook <keescook@chromium.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Russell King <linux@armlinux.org.uk>,
Sami Tolvanen <samitolvanen@google.com>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Ard Biesheuvel <ardb@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
linux-arm-kernel@lists.infradead.org, llvm@lists.linux.dev
Subject: Re: [PATCH v4 0/8] CFI for ARM32 using LLVM
Date: Thu, 4 Apr 2024 14:27:25 -0700 [thread overview]
Message-ID: <202404041427.E2A40D1@keescook> (raw)
In-Reply-To: <20240328-arm32-cfi-v4-0-a11046139125@linaro.org>
On Thu, Mar 28, 2024 at 09:19:23AM +0100, Linus Walleij wrote:
> This is a first patch set to support CLANG CFI (Control Flow
> Integrity) on ARM32.
>
> For information about what CFI is, see:
> https://clang.llvm.org/docs/ControlFlowIntegrity.html
>
> For the kernel KCFI flavor, see:
> https://lwn.net/Articles/898040/
>
> The base changes required to bring up KCFI on ARM32 was mostly
> related to the use of custom vtables in the kernel, combined
> with defines to call into these vtable members directly from
> sites where they are used.
>
> We annotate all assembly calls that are called directly from
> C with SYM_TYPED_FUNC_START()/SYM_FUNC_END() so it is easy
> to see while reading the assembly that these functions are
> called from C and can have CFI prototype information prefixed
> to them.
>
> As protype prefix information is just some random bytes, it is
> not possible to "fall through" into an assembly function that
> is tagged with SYM_TYPED_FUNC_START(): there will be some
> binary noise in front of the function so this design pattern
> needs to be explicitly avoided at each site where it occurred.
>
> The approach to binding the calls to C is two-fold:
>
> - Either convert the affected vtable struct to C and provide
> per-CPU prototypes for all the calls (done for TLB, cache)
> or:
>
> - Provide prototypes in a special files just for CFI and tag
> all these functions addressable.
>
> The permissive mode handles the new breakpoint type (0x03) that
> LLVM CLANG is emitting.
>
> To runtime-test the patches:
> - Enable CONFIG_LKDTM
> - echo CFI_FORWARD_PROTO > /sys/kernel/debug/provoke-crash/DIRECT
>
> The patch set has been booted to userspace on the following
> test platforms:
>
> - Arm Versatile (QEMU)
> - Arm Versatile Express (QEMU)
> - multi_v7 booted on Versatile Express (QEMU)
> - Footbridge Netwinder (SA110 ARMv4)
> - Ux500 (ARMv7 SMP)
> - Gemini (FA526)
>
> I am not saying there will not be corner cases that we need
> to fix in addition to this, but it is enough to get started.
> Looking at what was fixed for arm64 I am a bit weary that
> e.g. BPF might need something to trampoline properly.
>
> But hopefullt people can get to testing it and help me fix
> remaining issues before the final version, or we can fix it
> in-tree.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
For the series:
Tested-by: Kees Cook <keescook@chromium.org>
Thanks for making this work!
--
Kees Cook
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-04-04 21:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-28 8:19 [PATCH v4 0/8] CFI for ARM32 using LLVM Linus Walleij
2024-03-28 8:19 ` [PATCH v4 1/8] ARM: bugs: Check in the vtable instead of defined aliases Linus Walleij
2024-03-28 8:19 ` [PATCH v4 2/8] ARM: ftrace: Define ftrace_stub_graph Linus Walleij
2024-03-28 8:19 ` [PATCH v4 3/8] ARM: mm: Make tlbflush routines CFI safe Linus Walleij
2024-03-28 8:19 ` [PATCH v4 5/8] ARM: mm: Define prototypes for all per-processor calls Linus Walleij
2024-03-28 8:19 ` [PATCH v4 6/8] ARM: lib: Annotate loop delay instructions for CFI Linus Walleij
2024-03-28 8:19 ` [PATCH v4 7/8] ARM: hw_breakpoint: Handle CFI breakpoints Linus Walleij
2024-04-04 21:26 ` Kees Cook
2024-03-28 8:19 ` [PATCH v4 8/8] ARM: Support CLANG CFI Linus Walleij
2024-04-04 21:27 ` Kees Cook [this message]
2024-04-12 7:38 ` [PATCH v4 0/8] CFI for ARM32 using LLVM Linus Walleij
2024-04-12 22:07 ` Nathan Chancellor
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=202404041427.E2A40D1@keescook \
--to=keescook@chromium.org \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=llvm@lists.linux.dev \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=samitolvanen@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).