Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp2355252ybh; Fri, 24 Jul 2020 10:40:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx85HNQsxFZyZR8X9Tl0vyVqL1glU6vJ7+XR0YFkf0n79ZILzZNfvmW0HA9w1nDGPrUnk9Y X-Received: by 2002:aa7:c656:: with SMTP id z22mr10308897edr.101.1595612417603; Fri, 24 Jul 2020 10:40:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595612417; cv=none; d=google.com; s=arc-20160816; b=ZfRs4ecu6e9YMmK+LfXBQzmfubrFgP7/EhB8GJq2c5j0vBb9KdYwj/Sms6GdY9RLHG jbHSHyyb7LBNxlSlTBC5LSQu9EKLQXjgPB57mU/+YGy750p7Nr7kOzmI33qkm93/ViAs Lrq/t3u2SDNrL8OZfTtCYRXzHPuIF5394C4YhVelAFyyiZ+f/QTs9Cn3OrHOQG+ZV8fG rLAmV45vKz2MxBcRQYej96kUuJ//Fl7dmXnofoUEwmICShUpykjZV93qrE0KhoIATQca uFWgsJuASnBmgMmv7rXG6lebibZuFbB+zbmN8rzcYpBH7TXLx7I2Axj6xljdTia6VW8a Q/1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=YRPGxUeguCGjLYxX3OgPrVNtiOUWSFqHpOzzax4ku4k=; b=qqN3kBnl5v6cGPxM47cdbHqb25FsVdqDOtuM3qK+vV1HLdUOB6YznldtqTm5t0CFMA wdcmSCAZwWV66nKJsiS3ONuaaQbUUuf8QmL4XuLnDwLENn/+6rMDX/rcBSeOoihuRu45 9GI2Srz/+2vEOoEcCzOHMxBRiKnqjdn/8OCkTzgHAiUFqTarUoCkQF7M6MuBZj/cg5nZ FBj25LPmoG1lHj1xSvfV2TKnrG+6f9wGCAzDjotX264VUv8hvWondQ57ERs9ozAz0YJe 0MuTXLg1ydgLKQp8+Zm8kcN2EoYdNwsCCqLIvVKiAHudbr7ZP7GS3ydlqkNJJr2HD26z xlvw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id jp14si937908ejb.93.2020.07.24.10.39.55; Fri, 24 Jul 2020 10:40:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726719AbgGXRg7 (ORCPT + 99 others); Fri, 24 Jul 2020 13:36:59 -0400 Received: from mail.kernel.org ([198.145.29.99]:47670 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726381AbgGXRg6 (ORCPT ); Fri, 24 Jul 2020 13:36:58 -0400 Received: from oasis.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 03EC92067D; Fri, 24 Jul 2020 17:36:57 +0000 (UTC) Date: Fri, 24 Jul 2020 13:36:56 -0400 From: Steven Rostedt To: Oscar Carter Cc: Ingo Molnar , Kees Cook , linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com, Jann Horn Subject: Re: [PATCH v2 2/2] kernel/trace: Remove function callback casts Message-ID: <20200724133656.76c75629@oasis.local.home> In-Reply-To: <20200724171418.GB3123@ubuntu> References: <20200719155033.24201-1-oscar.carter@gmx.com> <20200719155033.24201-3-oscar.carter@gmx.com> <20200721140545.445f0258@oasis.local.home> <20200724161921.GA3123@ubuntu> <20200724123528.36ea9c9e@oasis.local.home> <20200724171418.GB3123@ubuntu> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 24 Jul 2020 19:14:18 +0200 Oscar Carter wrote: > > The linker trick should only affect architectures that don't implement > > the needed features. I can make it so the linker trick is only applied > > to those archs, and other archs that want more protection only need to > > add these features to their architectures. > > > It's much less intrusive than this patch. > > Sorry, but I don't understand your proposal. What features an arch need to > add if want the CFI protection? The better question is, what features should an arch add to not need the linker trick ;-) That is, they need to change it so that they add the two parameters that is expected by the ftrace core code. Once they do that, then they don't need to use the linker trick, and no function typecast is needed. In other-words, if they support the ftrace_ops and regs passing, they can define ARCH_SUPPORTS_FTRACE_OPS. Note, they don't even really need to support the regs, (can just send NULL), if they don't have HAVE_DYNAMIC_FTRACE_WITH_REGS. Which BTW, is supported by the following architectures: arm arm64 csky parisc powerpc riscv s390 x86 All of the above architectures should not even be hitting the code that does the function cast. What architecture are you doing all this for? -- Steve