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 AF7A1C433EF for ; Wed, 13 Apr 2022 14:00:10 +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=89FYs9x9UhGvPElzZ6UH7FDaJud9PQa8/d+nbT6uFYE=; b=k3APbfF0cszPV8 p4IDefM3EK9k0gw6rQGvoeXPamRmtr3LQf6Ez3AvKPFAqS7Bitrnm2xxWdJOJw494MOhbsosRDGZ3 Ahts7aoVK2JXGGTc/Ee/1lmWJbV9rU0a9Mrg1KA5Nb24541kgRYEnM7q2WNcLUpi7zx4+WZi3nLjn ewQAoAxk2ejbMTrn0LwBj+cmQdL9GJROTR1OA8IshDDLrjjoOrW7BtY8Cfr7YlTCaL8Yv136SHZ0K IYgbU0DO+OnKYRKnzn/65RoGT5IFDgqT/EbubaIU1Z0ezQ6FDCvSIvSUHbfrV1AfcP1uVRhXaWjUv qqdf/NPqnaNnVvfci5Nw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nedWY-001Ir2-Ns; Wed, 13 Apr 2022 13:59:10 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nedWV-001Ipk-HO for linux-arm-kernel@lists.infradead.org; Wed, 13 Apr 2022 13:59:09 +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 797E31595; Wed, 13 Apr 2022 06:59:04 -0700 (PDT) Received: from FVFF77S0Q05N (unknown [10.57.75.153]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 435003F5A1; Wed, 13 Apr 2022 06:59:01 -0700 (PDT) Date: Wed, 13 Apr 2022 14:58:54 +0100 From: Mark Rutland To: Kalesh Singh Cc: Fuad Tabba , Will Deacon , Marc Zyngier , Quentin Perret , Suren Baghdasaryan , "Cc: Android Kernel" , James Morse , Alexandru Elisei , Suzuki K Poulose , Catalin Marinas , Mark Brown , Masami Hiramatsu , Peter Collingbourne , "Madhavan T. Venkataraman" , Stephen Boyd , Andrew Walbran , Andrew Scull , Ard Biesheuvel , "moderated list:ARM64 PORT (AARCH64 ARCHITECTURE)" , kvmarm , LKML Subject: Re: [PATCH v6 7/8] KVM: arm64: Unwind and dump nVHE HYP stacktrace Message-ID: References: <20220314200148.2695206-1-kaleshsingh@google.com> <20220314200148.2695206-8-kaleshsingh@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220413_065907_664609_5ECAC88D X-CRM114-Status: GOOD ( 20.66 ) 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 Hi Kalesh, Sorry for the radiosilence. I see that in v7 you've dropped the stacktrace bits for now; I'm just commenting here fot future reference. On Thu, Mar 31, 2022 at 12:22:05PM -0700, Kalesh Singh wrote: > Hi everyone, > > There has been expressed interest in having hypervisor stack unwinding > in production Android builds. > > The current design targets NVHE_EL2_DEBUG enabled builds and is not > suitable for production environments, since this config disables host > stage-2 protection on hyp_panic() which breaks security guarantees. > The benefit of this approach is that the stack unwinding can happen at > EL1 and allows us to reuse most of the unwinding logic from the host > kernel unwinder. > > Proposal for how this can be done without disabling host stage-2 protection: > - The host allocates a "panic_info" page and shares it with the hypervisor. > - On hyp_panic(), the hypervisor can unwind and dump its stack > addresses to the shared page. > - The host can read out this information and symbolize these addresses. > > This would allow for getting hyp stack traces in production while > preserving the security model. The downside being that the core > unwinding logic would be duplicated at EL2. > > Are there any objections to making this change? I'm fine with the concept of splitting the unwind and logging steps; this is akin to doing: stack_trace_save_tsk(...); ... stack_trace_print(...); ... and I'm fine with having a stack_trace_save_hyp(...) variant. However, I would like to ensure that we're reusing logic rather than duplicating it wholesale. There are some changes I would like to make to the stacktrace code in the near future that might make that a bit easier, e.g. reworking the stack transition checks to be table-driven, and factoring out the way we handle return trampolines. I'll Cc you on changes to the stacktrace code. There are some preparatory cleanups I'd like to get out of the way first which I'll send shortly. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel