Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp155579iob; Mon, 2 May 2022 15:46:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwXDoy1MLZV+uI2FsaVnZCMuG+QE9SVi8ag2tkMv7idR2ra4ybGjAluuBq0CUkgFRT++C02 X-Received: by 2002:a2e:b894:0:b0:250:5ced:75bd with SMTP id r20-20020a2eb894000000b002505ced75bdmr3221928ljp.53.1651531603481; Mon, 02 May 2022 15:46:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651531603; cv=none; d=google.com; s=arc-20160816; b=E3Luw8pha0WnY7PPf+iditYcnE7lyPRmLX082+tYYKU05378DyMsx/fi+M27awEyYm JSdSYRSO/FomzbDel92gwHYzX9wdJrL1W0sM9ZnY06p95X9YNrWuYNsCkOefg8O7rV7z 3/JoSNzAyYGB+fmiaRZgeleHIldk3X7zWAqFyY0t/HPxFwHKn+Ph6p6hcM3tOdOXvoMh dR/j0UyJsD/751Ssh+/lN9BLylkY8DBLrGP2T+/s0vXF1se9DLy5Al2Bd4c6m23EPBx4 nWTWupj8mfyTq4WQSzZTpHUgqUdOtNYXXXJHpaLrdmeYuFEj9rnyhLKkiKhvHwqo5gPn oxIg== 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:in-reply-to:references:mime-version :dkim-signature; bh=ea1oEhzhMj8grWxQC5SgcBArE4/rXmfoEAuZM9GaSnk=; b=XESSfkF+IAWVUbIg2Ga6nxhFfJiof7jWEPQb7L8Q9fI5HlNiciVYxatOWI9vlIFE/4 udF7rN15AX/UVIQXZ4UhiSHu2t/9D6/Imm1RSkNAYYmNSUZb3RIPeNJYcarvy9NKra4k boynnByhJ4v1MDhx3WAtbCRFGPQDWE51VaUpPpzrRJQsnLpu63UB8Cy6L1VCb5Mp4OCf ETdQTWVCDtH5pzukmqMZ+lA9KHA9Ew+fp/BKms6Xh1dEGQHwfD+9WBHJYNX4kHZYRwxZ 12oSrFdN1oIeCzEZvMtHiVjOr3rS0OHdJLv4v9no23Koex3k1qqeCblLpFzxzlVzfdeC 2HBw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=e8jLUWg6; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f5-20020a05651232c500b0047208384a3csi16404213lfg.127.2022.05.02.15.46.16; Mon, 02 May 2022 15:46:43 -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=@google.com header.s=20210112 header.b=e8jLUWg6; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236020AbiEBP1E (ORCPT + 99 others); Mon, 2 May 2022 11:27:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59470 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238609AbiEBP1D (ORCPT ); Mon, 2 May 2022 11:27:03 -0400 Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AAF1513CC9 for ; Mon, 2 May 2022 08:23:30 -0700 (PDT) Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-2f7c57ee6feso151623327b3.2 for ; Mon, 02 May 2022 08:23:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ea1oEhzhMj8grWxQC5SgcBArE4/rXmfoEAuZM9GaSnk=; b=e8jLUWg60Xj2yGbY7ch7OqYrOgajvXWhT4iTIr2BEfGc4+9NKE3qXx5Xs7EWsTT9GL OeGOmR0vut0qQzy7JH/IrH9ka8nmoGFb2Gvyc23nt5LdSRcK5YcEOi9gq0tuIX1LeJ8F dgO5NTyqgBNIjtZfsGM/MVGmXurbMVjBLSFRbguI2sjEXBxprRb2lYwaWk3ntkRBUDU5 w3d7TRfSKPgIEQBDgV73myrvp6CyIfvHo0gPoeiO3QhVlTaXfe6T8J6DfnjHgI0tJoXs /uqM+NbLt9VQB70/97KqEMc8frtLzcwZYPKAQP5xl9ZKUvDReHs43KuwvnY0KNe0WvE5 DjCg== 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:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ea1oEhzhMj8grWxQC5SgcBArE4/rXmfoEAuZM9GaSnk=; b=ueXjcX0Vfv3v4Wce+xdXI1VnJUxglSxNDsDYw3Pit9nZ34cGxH63bCc5EeHNdgbs// ajMe6CDAz5lSNyX4tOvD5rt+MXc+ItmOAAE3yNs6AlXHLl28KjwcNkc0yIgZDptlciJ2 UucRXIyBbnfuSA+172giRbdsoQnpnFjYiH688fT4EJB5LL9MsjRaituPpqHvB2JP/+xH eBqC8uJsiMfQSqxiKZ2msV8BZLid7z38cd78bB0Lzz0elSWCcgm7rnztmJ+g6NoOJv8+ iFVolZ+/iFPS1l58WG7sU9yvjF0xk5YmJPNBqDtvSEdw7l+iCUxa7YvztRjjleCUGCtm rXEA== X-Gm-Message-State: AOAM5312oMhQz8awoCbxZ/KWmOupdLlobeHqn2JSr1wJ3Lficn8tX25e yCF9amsLVAI01+JJOe217bC+E++9Yn0WAzut7UpWqw== X-Received: by 2002:a81:a93:0:b0:2f4:d65a:d44e with SMTP id 141-20020a810a93000000b002f4d65ad44emr11108924ywk.243.1651505009686; Mon, 02 May 2022 08:23:29 -0700 (PDT) MIME-Version: 1.0 References: <20220429203644.2868448-1-samitolvanen@google.com> <202204291545.47C6A97EA2@keescook> In-Reply-To: From: Sami Tolvanen Date: Mon, 2 May 2022 08:22:57 -0700 Message-ID: Subject: Re: [RFC PATCH 00/21] KCFI support To: Peter Zijlstra Cc: Kees Cook , Mark Rutland , Josh Poimboeuf , Will Deacon , Catalin Marinas , Nathan Chancellor , Nick Desaulniers , Joao Moreira , Sedat Dilek , Steven Rostedt , LKML , X86 ML , linux-hardening@vger.kernel.org, linux-arm-kernel , llvm@lists.linux.dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL 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 Sat, Apr 30, 2022 at 2:02 AM Peter Zijlstra wrote= : > > On Fri, Apr 29, 2022 at 03:53:12PM -0700, Kees Cook wrote: > > On Fri, Apr 29, 2022 at 01:36:23PM -0700, 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. > > > > =F0=9F=8E=89 :) > > > > > The latest LLVM patches are here: > > > > > > https://reviews.llvm.org/D119296 > > > https://reviews.llvm.org/D124211 > > > > > > [...] > > > To test this series, you'll need to compile your own Clang toolchain > > > with the patches linked above. You can also find the complete source > > > tree here: > > > > > > https://github.com/samitolvanen/llvm-project/commits/kcfi-rfc > > > > And note that this RFC is seeking to break a bit of a circular dependen= cy > > with regard to the design of __builtin_kcfi_call_unchecked (D124211 > > above), as the implementation has gone around a few times in review wit= hin > > LLVM, and we want to make sure that kernel folks are okay with what was > > settled on. If there are no objections on the kernel side, then we can > > land the KCFI patches, as this is basically the only remaining blocker. > > So aside from the static_call usage, was there any other? Not at the moment, and it looks like we can get rid of that too. > Anyway, I think I hate that __builtin, I'd *much* rather see a variable > attribute or qualifier for this, such that one can mark a function > pointer as not doing CFI. > > I simply doesn't make sense to have a builtin that operates on an > expression. The whole thing is about indirect calls, IOW function > pointers. I also thought an attribute would be more convenient, but the compiler folks prefer a built-in: https://reviews.llvm.org/D122673 Sami