linux-hardening - Re: [RFC PATCH v2 00/21] KCFI support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 17 May 2022 09:33:47 +0200
From:   Sedat Dilek <sedat.dilek@...il.com>
To:     Sami Tolvanen <samitolvanen@...gle.com>
Cc:     linux-kernel@...r.kernel.org, Kees Cook <keescook@...omium.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>, x86@...nel.org,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Joao Moreira <joao@...rdrivepizza.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        linux-hardening@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, llvm@...ts.linux.dev
Subject: Re: [RFC PATCH v2 00/21] KCFI support

On Mon, May 16, 2022 at 7:57 PM Sami Tolvanen <samitolvanen@...gle.com> wrote:
>
> On Mon, May 16, 2022 at 10:31 AM Sedat Dilek <sedat.dilek@...il.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@...nel.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@...nel.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 -