Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp804621iog; Fri, 17 Jun 2022 14:10:33 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vYohg4Da8aW6X6OQuWq1bTEHJNso36DZCB7POzJVF9SzJj9b6h1YR3O6v0ziKIJlM8JRRH X-Received: by 2002:a17:907:1c8d:b0:6f2:eb2:1cd6 with SMTP id nb13-20020a1709071c8d00b006f20eb21cd6mr10705735ejc.568.1655500233154; Fri, 17 Jun 2022 14:10:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655500233; cv=none; d=google.com; s=arc-20160816; b=jZGRQN42NbcYwf3eHoO9hWwF3ujKmnW7lb5UtWmNG+MWEYu5PeC/e76lqmztVjAuvz 2o/Rpn4BlVh0AnKsYGkFaKygSMP2i9yyNfnGk7bkRFh7Tlhayv0cGQRuMpkMlqjNo5EG N9msFZHQAxuj1fb9POK1PyCWJVbn19iZoFajWduSZr0yw5KDC9C5XZj++/nK6bjK9qmu gm+h7iAqqsZh1Fjm+O2xGyv4w4LG0hy431bCoimj7cUrstd9IvtqueNECpUYqfCI1ACt tVpFQhO9gVqQAoduW27R2EZC4sia7S9TqF6nYGnuGzfpsfCOYfFfJg4dBQrcV67B9Nyk eR7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:to:from :dkim-signature:dkim-filter; bh=7x/ixErefSqMKfios87LlUDWmbSdZZSR+nkVTJ31BrI=; b=UUywx5jg6rDkJQ/3U/QhhB3tmiAyKd+EhDachyjdDrN25b/Y1ONnhxzSUjJkovzTvw pGNyBa6I3vdgd48ZiGcmN4+JjJO83ilpI6EO686hmZy7ANXTHuwk0UBzVDTNhd02qnrx hfAtLFjJwcfwdyq/puZtKad7yhmYeaez9JwDaJFO+eSB1Y2aw90RmZ2W0VAWowbeJRNb AR3UFizaaBwqiIkApSuPJFzLoQcqelKpfeedLswun5pvf9yU4k4Ak5FEFaDFPCKqZ1nY vgjOKMQoBUavK35/CA0NihXfRq9FQPSH4ESyzbKV1y/6PGLEj6BghV83rqWcrJjrIIZQ VWvw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=UeqJoc88; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a2-20020a509b42000000b004351fbc9afcsi2958353edj.466.2022.06.17.14.10.08; Fri, 17 Jun 2022 14:10:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=UeqJoc88; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1383613AbiFQVHk (ORCPT + 99 others); Fri, 17 Jun 2022 17:07:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40246 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1383503AbiFQVH2 (ORCPT ); Fri, 17 Jun 2022 17:07:28 -0400 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 5DC595E15E; Fri, 17 Jun 2022 14:07:28 -0700 (PDT) Received: from x64host.home (unknown [47.189.24.195]) by linux.microsoft.com (Postfix) with ESMTPSA id 6D5BC20C34A1; Fri, 17 Jun 2022 14:07:27 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 6D5BC20C34A1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1655500048; bh=7x/ixErefSqMKfios87LlUDWmbSdZZSR+nkVTJ31BrI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=UeqJoc88rxPGi6hsZMue1vIjsyJIWaPJUsIJ1SZnONmfYv53h4WZnwEvV9vTrfGgI oqOI2awBLVDelSz6ov5Lwt9WrUlRKlrj4UiSBpj7GchdLJsqhm0yjw2lkwc7h2DVDl S41LOKACplLnZA4YXs66rNexex89jU8BRRcZ2OBE= From: madvenka@linux.microsoft.com To: broonie@kernel.org, mark.rutland@arm.com, jpoimboe@redhat.com, ardb@kernel.org, nobuta.keiya@fujitsu.com, sjitindarsingh@gmail.com, catalin.marinas@arm.com, will@kernel.org, jamorris@linux.microsoft.com, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, madvenka@linux.microsoft.com Subject: [PATCH v15 4/6] arm64: Introduce stack trace reliability checks in the unwinder Date: Fri, 17 Jun 2022 16:07:15 -0500 Message-Id: <20220617210717.27126-5-madvenka@linux.microsoft.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220617210717.27126-1-madvenka@linux.microsoft.com> References: <20220617210717.27126-1-madvenka@linux.microsoft.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-19.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_PASS,T_FILL_THIS_FORM_SHORT,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: "Madhavan T. Venkataraman" There are some kernel features and conditions that make a stack trace unreliable. Callers may require the unwinder to detect these cases. E.g., livepatch. Introduce a new function called unwind_check_reliability() that will detect these cases and set a flag in the stack frame. Call unwind_check_reliability() for every frame in unwind(). Introduce the first reliability check in unwind_check_reliability() - If a return PC is not a valid kernel text address, consider the stack trace unreliable. It could be some generated code. Other reliability checks will be added in the future. Let unwind() return a boolean to indicate if the stack trace is reliable. Signed-off-by: Madhavan T. Venkataraman Reviewed-by: Mark Brown --- arch/arm64/kernel/stacktrace.c | 31 +++++++++++++++++++++++++++++-- 1 file changed, 29 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c index c749129aba5a..5ef2ce217324 100644 --- a/arch/arm64/kernel/stacktrace.c +++ b/arch/arm64/kernel/stacktrace.c @@ -44,6 +44,8 @@ * @final_fp: Pointer to the final frame. * * @failed: Unwind failed. + * + * @reliable: Stack trace is reliable. */ struct unwind_state { unsigned long fp; @@ -57,6 +59,7 @@ struct unwind_state { struct task_struct *task; unsigned long final_fp; bool failed; + bool reliable; }; static void unwind_init_common(struct unwind_state *state, @@ -80,6 +83,7 @@ static void unwind_init_common(struct unwind_state *state, state->prev_fp = 0; state->prev_type = STACK_TYPE_UNKNOWN; state->failed = false; + state->reliable = true; /* Stack trace terminates here. */ state->final_fp = (unsigned long)task_pt_regs(task)->stackframe; @@ -242,11 +246,34 @@ static void notrace unwind_next(struct unwind_state *state) } NOKPROBE_SYMBOL(unwind_next); -static void notrace unwind(struct unwind_state *state, +/* + * Check the stack frame for conditions that make further unwinding unreliable. + */ +static void unwind_check_reliability(struct unwind_state *state) +{ + if (state->fp == state->final_fp) { + /* Final frame; no more unwind, no need to check reliability */ + return; + } + + /* + * If the PC is not a known kernel text address, then we cannot + * be sure that a subsequent unwind will be reliable, as we + * don't know that the code follows our unwind requirements. + */ + if (!__kernel_text_address(state->pc)) + state->reliable = false; +} + +static bool notrace unwind(struct unwind_state *state, stack_trace_consume_fn consume_entry, void *cookie) { - while (unwind_continue(state, consume_entry, cookie)) + unwind_check_reliability(state); + while (unwind_continue(state, consume_entry, cookie)) { unwind_next(state); + unwind_check_reliability(state); + } + return !state->failed && state->reliable; } NOKPROBE_SYMBOL(unwind); -- 2.25.1