From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C3F98C433F5 for ; Wed, 25 May 2022 20:04:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=QP2i+Nu9REv9xs2ERUHb1u319H2+z1EA32CpBVgEC14=; b=t6+9l2Z3aueVyx Nk0F37phuhoGTAWPIoj1kSBp7qsYi1RdTeOz4hDfWG16VSSi7y9KYa7gAnpNCo8UIWp1N4MZdgNn4 0dB+px9cWvDKSwzF4XV883u+GHKlSqmzSjx9YqVk1PFYG6OzflSFpm6Cep/2tV4FRn6xguYLOKaib pgat0H/30fAZCiyOVAEYYNF4bO023dXvLldL/GotFMJAyEfTm9J+jyVbLe6bEJlPGEUQZiApIFdka E/OU6F2Nc7FJQgoaH1LJDzY7N1nmL73StsY8VkyJ3B7gNtKwAgOCHQ/fOLCTr4Zr3XQhci5saNAGL 1KzdSbAAUxkwbAoyK8nw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ntxDO-00CbRP-Gz; Wed, 25 May 2022 20:02:42 +0000 Received: from mail-pj1-x102c.google.com ([2607:f8b0:4864:20::102c]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ntxDK-00CbN1-P7 for linux-arm-kernel@lists.infradead.org; Wed, 25 May 2022 20:02:40 +0000 Received: by mail-pj1-x102c.google.com with SMTP id u12-20020a17090a1d4c00b001df78c7c209so2575641pju.1 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=gR8JPozimNgyHxol7/89fh/rD+abm42JBQKFXpDA6rbPVtk+W6dFhGcN4xl2DnnMCr 86Zybw5DfzIJnTI+NWhVF2Dboc6IvXv2MSLtBXuySaQn9oGWqLVMAGbZPTERKBOz8cad WIGc++ytGSzAf8V/aFQsMYw0+QlurxFMr0+eCJHYvBOdiSwIxncotKaysEwd7uRuQJ92 YAZGc1LR26XZ2DYPbdy4trgL+e4IYKUnamoNZTePyHvwWTjdLXkPypMvnn+pfHgy1u77 /dWCXj1y2K+pXGG7ao9RBg+3Bf2mwzjvYh/EkhJFF7W3QV+sXirr8l9gu+puEaIxp1BC 1CvA== X-Gm-Message-State: AOAM5314vvJ9N/YWeDmPmEEmuJ49vHzLCGEQwgKfNhJbk+JhJ8kKg+D1 0D/kcpJjnS4l6Nn0doSydmAIig== X-Google-Smtp-Source: ABdhPJyhTlIBPpX3HR10hM9NOmXQk/4SBxH2F1TSa7CgOZddaoOpxfLS37lZuJOm1uIRUa88qkEuyw== 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-Disposition: inline In-Reply-To: <20220516203723.GN76023@worktop.programming.kicks-ass.net> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220525_130238_835572_D394A77E X-CRM114-Status: GOOD ( 25.59 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel