Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp4095572iob; Tue, 17 May 2022 13:57:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwmWNcs6tp6DbF94o0617NuyaWNEE2JE4lEbpsUdfJDV+vHEBlsXO3ZXY+b2uL7MGgERbnE X-Received: by 2002:a17:906:478c:b0:6f4:e6c6:526f with SMTP id cw12-20020a170906478c00b006f4e6c6526fmr21575969ejc.41.1652821045275; Tue, 17 May 2022 13:57:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652821045; cv=none; d=google.com; s=arc-20160816; b=yU64Rh/G0ZYmnnkn2gGupWv+G4b56oC93sGG142BnkSydYdZ1PlTTJGwmhDKvcFnQO 3nXGdSIz59+hW2ZUuWQI9sSeG3x442Iswi5upO5HdOUs0rJW79BsYPD3/5MHmjnreZOJ VzH7kx9qtPNz11DbP5R4O9HtIFcSLiU+7LShs+OcbmxGubmTn53amltxhKYYcDI34C1X PKnNzsAJBoKxZ6DcLnlflPIGgZX7qUyDBkkCTSdAVnvnHzRHIouNc6WFx6UUBZBc6eAF VgPWP/UYN0sjz+NHEC9JPUSLoHxpOajjW6b6vht7jllxiDie7T5DXzNTvB8rAXPXcIRW lczQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:reply-to:in-reply-to:references:mime-version :dkim-signature; bh=pEIcGVNsbeP6EiKjnzSjTr7kPW4tfGTBsDC1SnKAcwM=; b=aDxf2qe2ud4QDmXd/kacTVzjmENH/V9pK3ExG6hJQhep4gm45b/jTPO0/DO7iqjRq+ 6cacDIvlBJoRHAdlbtVsuCZ9qKqlt0IyApSkvn0xOkMvv4u1sTssPnP/YPLJtgJoZQOu NvI1gfjtH/TqxUaWuyC0lFoMN5BpEE/1Ls5epZBI2iAseRIBV1KT2xdwIZQy1/A3G0Cx Jw64nuu6+DbFRmp5VBlcUwPpEQNXCDJSC2LKwCh9QBU2j8GtgWH4ewEBxKLb6kuf/IT6 PqNthujK56pNVajnrtZYo/QUuMcSOnRQcz9c3AUqycAcwplaKgpnAogPByC49mcL5+wa K35w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b="AWgu/vGI"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id js5-20020a17090797c500b006f39e6a26b0si565793ejc.252.2022.05.17.13.56.37; Tue, 17 May 2022 13:57:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b="AWgu/vGI"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241622AbiEQHhF (ORCPT + 99 others); Tue, 17 May 2022 03:37:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36728 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241698AbiEQHfr (ORCPT ); Tue, 17 May 2022 03:35:47 -0400 Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6386E49CA8; Tue, 17 May 2022 00:34:24 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id s6so7281627ilp.9; Tue, 17 May 2022 00:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=pEIcGVNsbeP6EiKjnzSjTr7kPW4tfGTBsDC1SnKAcwM=; b=AWgu/vGIkG8SmK3kIloR1l6q55qvAy1lBIHmOz8KORVQPGImI9XQpuXsSewqtqK4dY AhJuZcWVYo2jdg5ieemepA284NKyMoJ8SDzMFb/B36gaJgd5p69vb+m3LABO/YVtbrtf n6v8I7qGuiH4GdumG8EsJ+0e/nbhe8akw3iEC4oblawPKLd29OgOzARUx9xeYM2yCNR7 HqbkoJQ+I13WPVx6ZsHls7+ypCXVOk3/tPt0JUP+vqdY85PWOj+7DAbYm8jzeBx9vKBD lTwBelAoH0dqeTRw2yh3z0YH7gmQOtRiPHxGx9UZEj+VOYhaoVrkej3TEfVDv2frlzEk xA+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=pEIcGVNsbeP6EiKjnzSjTr7kPW4tfGTBsDC1SnKAcwM=; b=zlH8fmcZO4U5cmDfcH6hTpFQ1QKvXLA1TKLfTWE6EsBoRqPbzw7c1/7uW6pgMrWedu 8W9c4lA68FFcvNNMNnmxmM8gErn1VE6FSE+ezA5EdwP/6URd1r5WWVW4n3Le63fwlGkB 7T8HG/utk3Rk0w6OnipmY63886WTbuYxlAU9CrazLDpSHcow9dUirTsOPi6GMgnsBA4i 9FIO+23MPPGuPOCDO2cl0m+gx46DSavPrtAIiUN7w3Oqp0Sy61x3X/1Nems4d9TYEAZ5 aARUxckjb3NqQLapsvDmqujCVS9n4avtZ7lAbEzDjpYbJA2L6UE3RB5Nz7JOBSMLHC8q zbBQ== X-Gm-Message-State: AOAM531ipZqzwAYakFRtnui3PjI62T+AgNisUOvTgjqC8JdDWmIRJEp3 drSQ/QPbZySCrjps+oelp37zAhEIG3nzPgej6QI= X-Received: by 2002:a05:6e02:1a88:b0:2d1:f00:78b0 with SMTP id k8-20020a056e021a8800b002d10f0078b0mr7010341ilv.20.1652772863639; Tue, 17 May 2022 00:34:23 -0700 (PDT) MIME-Version: 1.0 References: <20220513202159.1550547-1-samitolvanen@google.com> In-Reply-To: Reply-To: sedat.dilek@gmail.com From: Sedat Dilek Date: Tue, 17 May 2022 09:33:47 +0200 Message-ID: Subject: Re: [RFC PATCH v2 00/21] KCFI support To: Sami Tolvanen Cc: linux-kernel@vger.kernel.org, Kees Cook , Josh Poimboeuf , Peter Zijlstra , x86@kernel.org, Catalin Marinas , Will Deacon , Mark Rutland , Nathan Chancellor , Nick Desaulniers , Joao Moreira , Steven Rostedt , linux-hardening@vger.kernel.org, linux-arm-kernel@lists.infradead.org, llvm@lists.linux.dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 16, 2022 at 7:57 PM Sami Tolvanen wro= te: > > On Mon, May 16, 2022 at 10:31 AM Sedat Dilek wrot= e: > >> 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=3D1 --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 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 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 =3D '08f70adedb775ce6d41a1f8ad75c4bac225efb5b' +GOOD_REVISION =3D '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-rf= c-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=E2=80=99s 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=E2=80=99s no longer need= ed, > 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= =3Dsubmitted/i915-cfi-fix&id=3D53735be6dc53453fcfbac658e847b54360e73871 > > To distinguish between clang-cfi we should use different kbuild variabl= es 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=3Dy. Does something speak against using CONFIG_LTO_CLANG_THIN=3Dy with KCFI supp= ort? Build-time? Disc-usage? Thanks for answering my questions. - Sedat -