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 X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 774C2C2D0EF for ; Fri, 17 Apr 2020 15:46:25 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 459512223C for ; Fri, 17 Apr 2020 15:46:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="HkxF8Qc8" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 459512223C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject: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=5w4Hcu2UdbV6DEOgvdjoBnKZvdgRTjbVgMtJxysWIgo=; b=HkxF8Qc83Sq3uE VTjDSDiO8slXq6YeGHy2bXEIUYVVe1E/ojxrazj80PuH6ezTvNJIALvDWW/IgZFc/d5m743Dl3Yr2 axJoI1tuuKbVGBzyFOSjMjPIEafoTYbSWpqLnII8nQTpyCuKBaA4+af5G+3ewWZcq4q6Zc0XtDaWI ZMMJbttxCqK7McwEUDJUOAvNTBY04PhK7uK3mH7SA/UNFXAd9YaNBc0BAVgG1DEUcFDL7D/weESPR JkQCjNTvrgAMveyJmOLfcOMFp9YxAYI9RawQ/w/bT3h98SnG57Lh0YzzYYmIkRorkXwUZ6BYb+55O DxLdJeTNkv+5Q5N6y2mQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jPTCC-0005JF-Fn; Fri, 17 Apr 2020 15:46:24 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jPTC8-0005IY-Cl for linux-arm-kernel@lists.infradead.org; Fri, 17 Apr 2020 15:46:22 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6F0C81FB; Fri, 17 Apr 2020 08:46:19 -0700 (PDT) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 920063F73D; Fri, 17 Apr 2020 08:46:16 -0700 (PDT) Date: Fri, 17 Apr 2020 16:46:14 +0100 From: Mark Rutland To: Peter Zijlstra Subject: Re: [PATCH v11 04/12] scs: disable when function graph tracing is enabled Message-ID: <20200417154613.GB9529@lakrids.cambridge.arm.com> References: <20191018161033.261971-1-samitolvanen@google.com> <20200416161245.148813-1-samitolvanen@google.com> <20200416161245.148813-5-samitolvanen@google.com> <20200417100039.GS20730@hirez.programming.kicks-ass.net> <20200417144620.GA9529@lakrids.cambridge.arm.com> <20200417152645.GH20730@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200417152645.GH20730@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.11.1+11 (2f07cb52) (2018-12-01) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200417_084620_890438_637FC975 X-CRM114-Status: GOOD ( 23.89 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Juri Lelli , kernel-hardening@lists.openwall.com, Catalin Marinas , Will Deacon , Marc Zyngier , Masahiro Yamada , clang-built-linux@googlegroups.com, Ingo Molnar , Sami Tolvanen , Laura Abbott , Dave Martin , Kees Cook , Jann Horn , Steven Rostedt , linux-arm-kernel@lists.infradead.org, Michal Marek , Ard Biesheuvel , Nick Desaulniers , linux-kernel@vger.kernel.org, Miguel Ojeda , James Morse , Masami Hiramatsu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Apr 17, 2020 at 05:26:45PM +0200, Peter Zijlstra wrote: > On Fri, Apr 17, 2020 at 03:46:21PM +0100, Mark Rutland wrote: > > > > diff --git a/arch/Kconfig b/arch/Kconfig > > > > index 691a552c2cc3..c53cb9025ad2 100644 > > > > --- a/arch/Kconfig > > > > +++ b/arch/Kconfig > > > > @@ -542,6 +542,7 @@ config ARCH_SUPPORTS_SHADOW_CALL_STACK > > > > > > > > config SHADOW_CALL_STACK > > > > bool "Clang Shadow Call Stack" > > > > + depends on DYNAMIC_FTRACE_WITH_REGS || !FUNCTION_GRAPH_TRACER > > > > depends on ARCH_SUPPORTS_SHADOW_CALL_STACK > > > > help > > > > This option enables Clang's Shadow Call Stack, which uses a > > > > > AFAICT you also need to kill KRETPROBES, which plays similar games. > > > > Hmm... how does KREPROBES work? If you can only mess with the return > > address when probing the first instruction in the function, it'll just > > work for SCS or pointer authentication, as the LR is used at that > > instant. If KRETPROBES tries to mess with the return address elsewhere > > it'd be broken today... > > To be fair, I've not looked at the arm64 implementation. x86 does gross > things like ftrace does. On x86 ftrace_graph and kretprobe also can't > be on at the same time for the same function, there's some yuck around > there. I can imagine the same holds true for us there. > Rostedt was recently talking about cleaning some of that up. > > But if kretprobe can work on arm64, then ftrace_graph can too, but I > think that links back to what you said earlier, you didn't want more > ftrace variants or something. I just want to avoid yet another implementation of the underlying mechanism. For DYNAMIC_FTRACE_WITH_REGS we can mess with the LR before pauth or SCS sees it, so those definitely work. If KRETPROBES works by messing with the LR at the instnat the function is entered, that should work similarly. If it works by replacing the RET it should also work out since any pauth/SCS work will have been undone by that point. If it attempts to mess with the return address in the middle of a function then it's not reliable today. I'll take a look, since > > > And doesn't BPF also do stuff like this? > > > > Can BPF mess with return addresses now!? > > At least on x86 I think it does. But what do I know, I can't operate > that stuff. Rostedt might know. Sounds like I might need to do some digging... Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel