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=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no 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 88286C433ED for ; Thu, 8 Apr 2021 19:32:06 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 235A961008 for ; Thu, 8 Apr 2021 19:32:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 235A961008 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=XrDoOESCYFoen8BBUNzOI7Z/MVHclC5r8Mh0Y0GRFXc=; b=iS9f3n9EDsBDOoKkQFEJ7T8QG 7Cbr9TKj04kqXHVRpwuanvK2pOqendIN5k9p/ILBgGdlNtR1SU27y2v0hZOgJf3vrfZGZ1ktrMCF8 XMOZesNJIJ2Khk4ZeWCb+fRfi+VVaMh8SQ+5iAj7nGaYTg1x3DJWTwlIqGKOUJy0tLsmBBltcxuH6 vcFVXPJMwRvLyINXy2CbJAXX9o1eoecUYFP5PpASZY7PilAMszctvjVHVkxDVN9uZDWp9x2PPavvx AgRja+AUxNxd+KJZYUNpujHW4Ym6vAVWVY15Io1EO05SZO4UM/hUFRa+v7Wh9Ics1HjnixmUHAFhD jgbEZ/EZw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lUaM5-0096cg-6j; Thu, 08 Apr 2021 19:30:17 +0000 Received: from linux.microsoft.com ([13.77.154.182]) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lUaM0-0096bd-El for linux-arm-kernel@lists.infradead.org; Thu, 08 Apr 2021 19:30:14 +0000 Received: from [192.168.254.32] (unknown [47.187.194.202]) by linux.microsoft.com (Postfix) with ESMTPSA id 5962520B5680; Thu, 8 Apr 2021 12:30:10 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 5962520B5680 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1617910211; bh=3M5BMX+Zn5t7e8aETm0F+/O3ZB2bGm4K7Wqo9smI+i4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Z+sb3f5JKfsvhpPgLoP5GjIJ9A/O5lAeMwoQAinyOQS8WMOjXqmf4Sna67uaFiu6y Hr5k/4UU7bcF6t+VmGWAUKm+FPbHWyvK1QiCqyCiFD8ZtkyybbWomU84D+S+GQaxt7 Vgaj2TaJZu3Piw1UBbpBPXgddUB/Fhr2PRGG41IA= Subject: Re: [RFC PATCH v2 1/4] arm64: Implement infrastructure for stack trace reliability checks To: Mark Brown Cc: mark.rutland@arm.com, jpoimboe@redhat.com, jthierry@redhat.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd> <20210405204313.21346-1-madvenka@linux.microsoft.com> <20210405204313.21346-2-madvenka@linux.microsoft.com> <20210408171715.GQ4516@sirena.org.uk> From: "Madhavan T. Venkataraman" Message-ID: <69b6924b-88f6-6c40-7b18-8cdf15d92bd1@linux.microsoft.com> Date: Thu, 8 Apr 2021 14:30:09 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210408171715.GQ4516@sirena.org.uk> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210408_203012_795398_137BAE31 X-CRM114-Status: GOOD ( 23.98 ) 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 4/8/21 12:17 PM, Mark Brown wrote: > On Mon, Apr 05, 2021 at 03:43:10PM -0500, madvenka@linux.microsoft.com wrote: > >> These checks will involve checking the return PC to see if it falls inside >> any special functions where the stack trace is considered unreliable. >> Implement the infrastructure needed for this. > > Following up again based on an off-list discussion with Mark Rutland: > while I think this is a reasonable implementation for specifically > listing functions that cause problems we could make life easier for > ourselves by instead using annotations at the call sites to put things > into sections which indicate that they're unsafe for unwinding, we can > then check for any address in one of those sections (or possibly do the > reverse and check for any address in a section we specifically know is > safe) rather than having to enumerate problematic functions in the > unwinder. This also has the advantage of not having a list that's > separate to the functions themselves so it's less likely that the > unwinder will get out of sync with the rest of the code as things evolve. > > We already have SYM_CODE_START() annotations in the code for assembly > functions that aren't using the standard calling convention which should > help a lot here, we could add a variant of that for things that we know > are safe on stacks (like those we expect to find at the bottom of > stacks). > As I already mentioned before, I like the idea of sections. The only reason that I did not try it was that I have to address FTRACE trampolines and the kretprobe_trampoline (and optprobes in the future). I have the following options: 1. Create a common section (I will have to come up with an appropriate name) and put all such functions in that one section. 2. Create one section for each logical type (exception section, ftrace section and kprobe section) or some such. 3. Use the section idea only for the el1 exceptions. For the others use the current special_functions[] approach. Which one do you and Mark Rutland prefer? Or, is there another choice? Madhavan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel