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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 6EDF6C433ED for ; Fri, 9 Apr 2021 22:56:21 +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 E2DDF610E7 for ; Fri, 9 Apr 2021 22:56:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E2DDF610E7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.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: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=zLGqCFmJyWWLuzZj6l/aiRDarYrxriPdZWJXoMYDl5U=; b=pMRdMYLA4HDCqD+PlTtgVL599 szVvrC17WmpHz77ILBxe7RIm1PK7MEaDLFt6pTFsju17XgFoDQ+Rmad2p582xjnz2e9+S31Wm9AHO WuYcEZ8WoVREgYPazF5UTMgdzzkmZFxWsKjjAJQS2w0yAWS8uv0bj91WKGq00ImQ4p2QdB821zmc5 njq2rGElL8fRkVsyqVBa+c6WwL62Xp0ADgJe2OviFWC3kgMUqHcdmPiglvPmeWxfLH+xWz1KDEntu UjgJdCc7wzOx6R6LqPr3Aux8XGbc513R/EcT3R3bMjAOvtVslABqg6JnQAUisi4fzr5tlKCKMN1zd pj9Haem5g==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lV00l-001f6e-K1; Fri, 09 Apr 2021 22:54:08 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lV00N-001f4H-PD for linux-arm-kernel@desiato.infradead.org; Fri, 09 Apr 2021 22:53:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Jf6jPmlzNbpAjoJ0oKjh2RDzB4kN600asH4kKxtngY8=; b=R+8Gagc/qzmOa3QbqKqIjMxNFJ S7Aw5Kwv/pijFd/E+iJTgOl5ugY0hJRApFOoVLjClpICqBYbMK8bDff1aG2QjkpdFINFI4fuWHS5i d5KZ6awQ368KvMzOmom0I7JftaJoRQCeV8HFvoootEu1GuhDAEoZoHqFLZo3/078YaR5JFp9jYk+H Rm+4qq7SguEOTANFnuMvfkc/C1avk0SV4E5po2WwoR4X6fjXUaErZe7OUe5UvJvjy28HrkdFbrSQU L1xpggMws6fOqY8ABf5OUOxCve9lvpxYro50eDMhPY27TkXdiSk8v4tGsxt9LB1osUxsHXnjY4D9U O5Eld3WA==; Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lV00K-004qKc-DK for linux-arm-kernel@lists.infradead.org; Fri, 09 Apr 2021 22:53:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1618008810; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Jf6jPmlzNbpAjoJ0oKjh2RDzB4kN600asH4kKxtngY8=; b=gHnbDRYQtrDQGu90Dn4sugTiO6+p00FfGcsp1Y8V6VIBt5XUIT/vMmDP0KRIYFCDs5q0MZ UjzAJMLXs9Q+K2fKvYCSmM1KhVq3sRn+bYqoHCKWay4aqyeOWX2MOYeJgyDe/423u2Motb 4k/4UVkM83tsqf7lrXqECaVTOOnEsLo= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-547-k-qExt-ANg2MUVpDE77G1g-1; Fri, 09 Apr 2021 18:53:28 -0400 X-MC-Unique: k-qExt-ANg2MUVpDE77G1g-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4B760189C446; Fri, 9 Apr 2021 22:53:27 +0000 (UTC) Received: from treble (ovpn-112-2.rdu2.redhat.com [10.10.112.2]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0E1E45D9E3; Fri, 9 Apr 2021 22:53:22 +0000 (UTC) Date: Fri, 9 Apr 2021 17:53:21 -0500 From: Josh Poimboeuf To: "Madhavan T. Venkataraman" Cc: Mark Rutland , broonie@kernel.org, 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, Peter Zijlstra Subject: Re: [RFC PATCH v2 0/4] arm64: Implement stack trace reliability checks Message-ID: <20210409225321.2czbawz6p2aquf5m@treble> References: <705993ccb34a611c75cdae0a8cb1b40f9b218ebd> <20210405204313.21346-1-madvenka@linux.microsoft.com> <20210409120859.GA51636@C02TD0UTHF1T.local> <20210409213741.kqmwyajoppuqrkge@treble> <8c30ec5f-b51e-494f-5f6c-d2f012135f69@linux.microsoft.com> <20210409223227.rvf6tfhvgnpzmabn@treble> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210409223227.rvf6tfhvgnpzmabn@treble> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210409_155332_550841_B50AA518 X-CRM114-Status: GOOD ( 20.80 ) 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 Fri, Apr 09, 2021 at 05:32:27PM -0500, Josh Poimboeuf wrote: > On Fri, Apr 09, 2021 at 05:05:58PM -0500, Madhavan T. Venkataraman wrote: > > > FWIW, over the years we've had zero issues with encoding the frame > > > pointer on x86. After you save pt_regs, you encode the frame pointer to > > > point to it. Ideally in the same macro so it's hard to overlook. > > > > > > > I had the same opinion. In fact, in my encoding scheme, I have additional > > checks to make absolutely sure that it is a true encoding and not stack > > corruption. The chances of all of those values accidentally matching are, > > well, null. > > Right, stack corruption -- which is already exceedingly rare -- would > have to be combined with a miracle or two in order to come out of the > whole thing marked as 'reliable' :-) > > And really, we already take a similar risk today by "trusting" the frame > pointer value on the stack to a certain extent. Oh yeah, I forgot to mention some more benefits of encoding the frame pointer (or marking pt_regs in some other way): a) Stack addresses can be printed properly: '%pS' for printing regs->pc and '%pB' for printing call returns. Using '%pS' for call returns (as arm64 seems to do today) will result in printing the wrong function when you have tail calls to noreturn functions on the stack (which is actually quite common for calls to panic(), die(), etc). More details: https://lkml.kernel.org/r/20210403155948.ubbgtwmlsdyar7yp@treble b) Stack dumps to the console can dump the exception registers they find along the way. This is actually quite nice for debugging. -- Josh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel