Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp1448202pxb; Thu, 14 Apr 2022 06:31:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzZ1kPFjbNMuZp5RBMBnKhw4vDSDbQcjE4+QHQO/NgrwhwM/OCNzCJT78mYVQLtJiKRZo/0 X-Received: by 2002:a17:902:7610:b0:158:89a5:fc5a with SMTP id k16-20020a170902761000b0015889a5fc5amr12900079pll.116.1649943079516; Thu, 14 Apr 2022 06:31:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649943079; cv=none; d=google.com; s=arc-20160816; b=du4ZJTAMYWz0crcL95UlkNnKJrIJSS/Y1kB/rSdINwO36kfKjAcImd8WyFQgFtMS2J ba2D41LCycMYF7TytcDi27s0kt4CQgnXiO1GQlb8p8aBamYZwbn2GVQU5g+uYljYs1mW DlsXVKzmstgoAKLjhKa3FLsax65zoxL275hCZxnwYJvEs37SZOlREU37lmefiWWFLJbx wACJ/3tDoTxVbzu5ggnyQmVtzVWaiLqPJjHwHcenIt+KRB+YMob0GzrY3GFEMV6FMx/S tXns2UxRaal9S+UKcm5j3UL1/Ua90dkIP4kR0nLd2E2wz7OQlmarOv2hu1+R8MXlDNwK pplg== 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:cc:to:from :dkim-signature; bh=1W/iPGxZZe0dTxtRIT/L4inWkaCNOxDFyHeQ0vhNfa0=; b=U40d5JNIB0kezHGDgIMs9uGx/bZOa5PZGJsLQ9x5dsvp7q0TaAVuBECFUBZLkqvZv7 xt/Qsj7HvDQJOdswTwPvuRIwtdZPyIwi6mUuNz6pekvrmWQPHS3WbUm6rqtffSiWzy71 Ri6/v4B1yA3j9vYyG6S8kJWG51CnzHs8cLV1583YMPuMoRwfcbp27We3sJpynz6wQcl+ PUAx/lyjnVO2vQGYs+nACS1VnetLnK5+5du0nD0fywZk/XiYcI+pB4kPrGqPm+iI33Hi tD1NzGAloGm735tqLiwlvJezpD36IiDXoim69rjOAPsRScmnaqk6ZvPWgPpp7jRLsNZN P9hQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=gnwkJMKP; 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.dev Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j37-20020a634a65000000b0039911b180a7si8535314pgl.93.2022.04.14.06.31.03; Thu, 14 Apr 2022 06:31:19 -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.dev header.s=key1 header.b=gnwkJMKP; 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.dev Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238356AbiDMTao (ORCPT + 99 others); Wed, 13 Apr 2022 15:30:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36102 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238349AbiDMTal (ORCPT ); Wed, 13 Apr 2022 15:30:41 -0400 Received: from out2.migadu.com (out2.migadu.com [IPv6:2001:41d0:2:aacc::]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 50B5F73071 for ; Wed, 13 Apr 2022 12:28:19 -0700 (PDT) X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1649878096; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1W/iPGxZZe0dTxtRIT/L4inWkaCNOxDFyHeQ0vhNfa0=; b=gnwkJMKPPygIVkZ/9Wh1mh3OT1cMRRjuS5qS8IK6a6j48F8Mu3vVEr6wfetKEVn+G0kwVH VpnSFOGe6lHZ16nJIfVYj83+P9+IFGSaJ9oP5g4LZ79gI0ZQ4hAcFfPGXw47pP2GkGazjs X7uQvydkAJIrVzsEfjwJGtTH9md0qaI= From: andrey.konovalov@linux.dev To: Marco Elver , Alexander Potapenko , Mark Rutland Cc: Andrey Konovalov , Dmitry Vyukov , Andrey Ryabinin , kasan-dev@googlegroups.com, Catalin Marinas , Will Deacon , Vincenzo Frascino , Sami Tolvanen , linux-arm-kernel@lists.infradead.org, Peter Collingbourne , Evgenii Stepanov , Florian Mayer , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrey Konovalov Subject: [PATCH v3 2/3] kasan, arm64: implement stack_trace_save_shadow Date: Wed, 13 Apr 2022 21:26:45 +0200 Message-Id: <78cd352296ceb14da1d0136ff7d0a6818e594ab7.1649877511.git.andreyknvl@google.com> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: linux.dev X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE 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: Andrey Konovalov Implement stack_trace_save_shadow() that collects stack traces based on the Shadow Call Stack (SCS) for arm64 by copiing the frames from SCS. The implementation is best-effort and thus has limitations. stack_trace_save_shadow() fully handles task and softirq contexts, which are both processed on the per-task SCS. For hardirqs, the support is limited: stack_trace_save_shadow() does not collect the task part of the stack trace. For KASAN, this is not a problem, as stack depot only saves the interrupt part of the stack anyway. Otherwise, stack_trace_save_shadow() also takes a best-effort approach with a focus on performance. Thus, it: - Does not try to collect stack traces from other exceptions like SDEI. - Does not try to recover frames modified by KRETPROBES or by FTRACE. However, stack_trace_save_shadow() does strip PTR_AUTH tags to avoid leaking them in stack traces. The -ENOSYS return value is deliberatly used to match stack_trace_save_tsk_reliable(). Signed-off-by: Andrey Konovalov --- mm/kasan/common.c | 62 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 62 insertions(+) diff --git a/mm/kasan/common.c b/mm/kasan/common.c index d9079ec11f31..23b30fa6e270 100644 --- a/mm/kasan/common.c +++ b/mm/kasan/common.c @@ -30,6 +30,68 @@ #include "kasan.h" #include "../slab.h" +#ifdef CONFIG_SHADOW_CALL_STACK +#include +#include + +/* + * Collect the stack trace from the Shadow Call Stack in a best-effort manner: + * + * - Do not collect the task part of the stack trace when in a hardirq. + * - Do not collect stack traces from other exception levels like SDEI. + * - Do not recover frames modified by KRETPROBES or by FTRACE. + * + * Note that marking the function with __noscs leads to unnacceptable + * performance impact, as helper functions stop being inlined. + */ +static inline int stack_trace_save_shadow(unsigned long *store, + unsigned int size) +{ + unsigned long *scs_top, *scs_base, *frame; + unsigned int len = 0; + + /* Get the SCS base. */ + if (in_task() || in_serving_softirq()) { + /* Softirqs reuse the task SCS area. */ + scs_base = task_scs(current); + } else if (in_hardirq()) { + /* Hardirqs use a per-CPU SCS area. */ + scs_base = *this_cpu_ptr(&irq_shadow_call_stack_ptr); + } else { + /* Ignore other exception levels. */ + return 0; + } + + /* + * Get the SCS pointer. + * + * Note that this assembly might be placed before the function's + * prologue. In this case, the last stack frame will be lost. This is + * acceptable: the lost frame will correspond to an internal KASAN + * function, which is not relevant to identify the external call site. + */ + asm volatile("mov %0, x18" : "=&r" (scs_top)); + + /* The top SCS slot is empty. */ + scs_top -= 1; + + for (frame = scs_top; frame >= scs_base; frame--) { + if (len >= size) + break; + /* Do not leak PTR_AUTH tags in stack traces. */ + store[len++] = ptrauth_strip_insn_pac(*frame); + } + + return len; +} +#else /* CONFIG_SHADOW_CALL_STACK */ +static inline int stack_trace_save_shadow(unsigned long *store, + unsigned int size) +{ + return -ENOSYS; +} +#endif /* CONFIG_SHADOW_CALL_STACK */ + depot_stack_handle_t kasan_save_stack(gfp_t flags, bool can_alloc) { unsigned long entries[KASAN_STACK_DEPTH]; -- 2.25.1