Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp4080163ioo; Wed, 25 May 2022 14:32:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwMmf3iO8XOkX3hBngVRMZGX0OLQbORrOrsQkLA6+9OCSEDU/l9o62ooGzMY6hm1Y++L38j X-Received: by 2002:a05:6402:2752:b0:41c:b898:19a6 with SMTP id z18-20020a056402275200b0041cb89819a6mr37177650edd.30.1653514320976; Wed, 25 May 2022 14:32:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653514320; cv=none; d=google.com; s=arc-20160816; b=arA120Csw0J8NAKeEsfFtWVVUW8ECgn4XfKPzlJrbI+0AKAqaNpaMZPgilUjluwTy4 6OHcMDM+oLPzgGqE+uZf3Bts1hXxpoFyxyVaMwcFyyTFjIsu9jGdgxHr5QENB+UqDTVB VWH6+Fn1NCEM1QNxBRAM4+zUQaYKZ7RGzzSSTakSAUAA8DxAo6nsb8xdXWSVGyUxtfgf TwryWuq8W9iW8Wc1g5DrMXJdC++rkw6rak52oBWebIhehv+CUnXzG7I5uEScoX/y3ucM ticZ78SN3MtvhZoL3PeLuXnxzHO/mtbkIhKdSCbzN45vgONGBTQBg/fIlx5stbYfXUiu Q+rw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=AWaeHfIqso2uarSrq2voc6y6tcqWng3SnNIxku0tA0k=; b=01rbvnS+5CZsZHgJ29xdmwMlCTFXsY7zRYEpAFE362PaFYMa1dGaDtYAzwmxRAlz6o zMQwPmlypvX3r566p4b+tEEveLZb2wN3BzqST75o0s+EcAi7jvl0R1vZMdSji2uTzD82 muEQd+iUTAqWVlSlBzDv8a8VgSWXGB5zUeuewUGty2kPlbSqjF32AEKxSIp0QtEHQlvz e1ODcIOOIdxT5G1Sm1XQymA/G/1+CEArBQSyOkIZOVlEPWBMFuGeW1F98frxYyMS9eaH CJOAUkbetIr4BmX5sR3LhjelK7JZPOXcqCM0JmOPexRzLoFn3JcPlm4g379IEVlAeRsp o4Pg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=ezecxoS1; 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=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ez21-20020a1709070bd500b006feff0cc10asi4988083ejc.949.2022.05.25.14.31.26; Wed, 25 May 2022 14:32:00 -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=@chromium.org header.s=google header.b=ezecxoS1; 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=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240253AbiEYUCh (ORCPT + 99 others); Wed, 25 May 2022 16:02:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52492 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235258AbiEYUCc (ORCPT ); Wed, 25 May 2022 16:02:32 -0400 Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2297368319 for ; Wed, 25 May 2022 13:02:32 -0700 (PDT) Received: by mail-pj1-x1034.google.com with SMTP id ge11so879415pjb.0 for ; Wed, 25 May 2022 13:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=AWaeHfIqso2uarSrq2voc6y6tcqWng3SnNIxku0tA0k=; b=ezecxoS1sA3vkGGfwUxIzhGQpcMdwdQ/B9z2SvvAPRmDulRg7UxU9szNANvQ24Y57r ivBiwI1khWN3D600by1SoMY+gQ2uvqvLzdj6JqyC3GStB1oKR0vo010PlPD/Ov4uDDMX PcNzCUpi4CzTj7LRLePIkozu7t9ZfSWN2y7Ik= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=AWaeHfIqso2uarSrq2voc6y6tcqWng3SnNIxku0tA0k=; b=rCWyDbMY5o8yddO79/2tQHhthud9SmMQGaOEiODJIY4ltU6z5wkFV9PLoGAwSyFSpz dui2KammNApDUNzi3pwA0rYhztU3ajccD2PWaZ4gSus/rg4HMQZ08A877ihJ/Eu3WOPg VaP/fJ6VW0BqSWgHJ18SQn9sUFd2PnHMp1DjPHCpfsRj9delKZ5d68B37aj4V1/fhSJF SeG9GXMO2R3RCoZEi3eWwejRZIGyD1qM+DzYXCFZluOcUmhPLmf1GTMPtN3Q4SfX2qv8 SVACINfCsXr9JVHzs81duU6aDG1iq5Km7N6NIPf19lp3zm8ilvsg6oN1MY6X26T0j3zx 290Q== X-Gm-Message-State: AOAM533H5JmCgQ0qfFaHd3uMmdIj8GQa7VciehC9tIEtLURwCjZ1Pxhh 1+6OexP/6bdFUqwjZ8heGhO/Nw== X-Received: by 2002:a17:90b:4b82:b0:1e0:c609:69d7 with SMTP id lr2-20020a17090b4b8200b001e0c60969d7mr2258619pjb.119.1653508951535; Wed, 25 May 2022 13:02:31 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id f13-20020a056a00228d00b0050dc762819esm11876635pfe.120.2022.05.25.13.02.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 May 2022 13:02:29 -0700 (PDT) Date: Wed, 25 May 2022 13:02:28 -0700 From: Kees Cook To: Peter Zijlstra Cc: Sami Tolvanen , linux-kernel@vger.kernel.org, Josh Poimboeuf , x86@kernel.org, Catalin Marinas , Will Deacon , Mark Rutland , Nathan Chancellor , Nick Desaulniers , Joao Moreira , Sedat Dilek , Steven Rostedt , linux-hardening@vger.kernel.org, linux-arm-kernel@lists.infradead.org, llvm@lists.linux.dev Subject: Re: [RFC PATCH v2 20/21] x86: Add support for CONFIG_CFI_CLANG Message-ID: <202205251241.FDC27BC9@keescook> References: <20220513202159.1550547-1-samitolvanen@google.com> <20220513202159.1550547-21-samitolvanen@google.com> <20220516183047.GM76023@worktop.programming.kicks-ass.net> <20220516203723.GN76023@worktop.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220516203723.GN76023@worktop.programming.kicks-ass.net> X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 10:37:23PM +0200, Peter Zijlstra wrote: > On Mon, May 16, 2022 at 12:39:19PM -0700, Sami Tolvanen wrote: > > > > > With the current compiler patch, LLVM sets up function arguments after > > > > the CFI check. if it's a problem, we can look into changing that. > > > > > > Yes, please fix that. Again see that same patch for why this is a > > > problem. Objtool can trivially find retpoline calls, but finding this > > > kCFI gadget is going to be hard work. If you ensure they're > > > unconditionally stuck together, then the problem goes away find one, > > > finds the other. > > > > You can use .kcfi_traps to locate the check right now, but I agree, > > it's not quite ideal. > > Oohh, indeed. > [...] Hi Peter, Sami investigated moving the CFI check after arg setup, and found that to do it means making LLVM's CFI logic no longer both architecture and call-type agnostic. The CFI logic needs put at a lower level, requiring it be done in per-architecture code, and then additionally per-call-type. (And by per-call-type, AIUI, this means various types of indirect calls: standard, tail-call, etc.) Sami has it all working for x86, but I'm concerned about the risk/benefit in doing it this way. I only see down-sides: - Linux cannot enable CFI for a new architecture without also implementing it within LLVM first. - LLVM CFI code becomes more complex, making it harder to maintain/bug-fix/etc. I actually see the first issue as the larger problem: I want to make it easy for the kernel to use CFI, rather than harder. :P The first user of CFI already cleared the way for other architectures by adjusting the bulk of core kernel code, etc, so adding another architecture should be as trivial as possible, and not require yet newer releases of LLVM, etc, etc. So, since using .kcfi_traps already solves the issue for finding the checks, can we not require moving the CFI check? I think it would be a mistake to have to do that. -Kees -- Kees Cook