From patchwork Wed Apr 13 19:26:43 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: andrey.konovalov@linux.dev X-Patchwork-Id: 12812551 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 5FD73C433F5 for ; Wed, 13 Apr 2022 19:47:20 +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:MIME-Version:Message-Id:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=qb9IUQkP/AN4EeMBwikhWU9YwaLrZ1lhMJyL7VWhbRk=; b=sKWkM2mOwBamJL QZQRXr5m/GKY/aChcH911TcOGnAheRj//Ai2govIQyFnRYF4d6uUeejvFnd1bMx5P46UEzjIK1VB0 ONucD1NcfbTKH0FpaeBslm1A6Wp94Bv8gEoMpKbP85OesG0D3wfvPRSG6OTvXTZB5mu4yQ/8fMa8o vUW8/ydxsoaOpvDDI/v926eHuw1JRh9ZjeepHYDTurXCHRLU5e62DakDmtIgrbYwDL0mJq3edspr2 IbSBs1YdJ9xvoB97IY40FqB/+HAwIEi4fNJtdSAf9aYqhIoX3wobP6h2x3H5xR/UXEawxNn+GoZLi OQWk56T443H7OEnSr+pw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1neiwH-002Yzt-CT; Wed, 13 Apr 2022 19:46:05 +0000 Received: from out2.migadu.com ([2001:41d0:2:aacc::]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1neifA-002RO8-F7 for linux-arm-kernel@lists.infradead.org; Wed, 13 Apr 2022 19:28:26 +0000 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=1649878094; 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; bh=L2z4Q/1rfqvzlgKK/+Q8dR7Hr7nD3d/L3KDR+0LUxPU=; b=ZvRioLZbeDyL4poeadGgM2c8Po2yBKxCKpGbpWnDtBTp34qUgzhusba/LG+/a/YwJellq0 Z892c6X/MEaC7LAR5WuUDf/FvNuwCTgizZXrHwgPxfm7DJWldynpomv9Etgx46bEu/yTO4 TCy+al8B7eu/+lHMiLrkDnNJNV2av8o= 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 0/3] kasan, arm64, scs: collect stack traces from Shadow Call Stack Date: Wed, 13 Apr 2022 21:26:43 +0200 Message-Id: MIME-Version: 1.0 X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: linux.dev X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220413_122824_824765_EFD47E35 X-CRM114-Status: GOOD ( 13.60 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org From: Andrey Konovalov Currently, when saving alloc and free stack traces, KASAN uses the normal stack trace collection routines, which rely on the unwinder. Instead of invoking the unwinder, collect the stack trace by copying frames from the Shadow Call Stack. This reduces boot time by ~30% for all KASAN modes when Shadow Call Stack is enabled. See below for the details of how the measurements were performed. Stack staces are collected from the Shadow Call Stack via a new stack_trace_save_shadow() interface. Note that the implementation is best-effort and only works in certain contexts. See patch #3 for details. --- Changes ======= v2->v3: - Limit hardirq and drop SDEI support for performance and simplicity. - Move stack_trace_save_shadow() implementation back to mm/kasan: it's not mature enough to be used as a system-wide stack trace collection replacement. - Clarify -ENOSYS return value from stack_trace_save_shadow(). - Don't rename nr_entries to size in kasan_save_stack(). - Check return value of stack_trace_save_shadow() instead of checking CONFIG_HAVE_SHADOW_STACKTRACE in kasan_save_stack(). v1->v2: - Provide a kernel-wide stack_trace_save_shadow() interface for collecting stack traces from shadow stack. - Use ptrauth_strip_insn_pac() and READ_ONCE_NOCHECK, see the comments. - Get SCS pointer from x18, as per-task value is meant to save the SCS value on CPU switches. - Collect stack frames from SDEI and IRQ contexts. Perf ==== To measure performance impact, I used QEMU in full system emulation mode on an x86-64 host. As proposed by Mark, I passed no filesystem to QEMU and booted with panic=-1: qemu-system-aarch64 \ -machine virt,mte=on -cpu max \ -m 2G -smp 1 -nographic \ -kernel ./xbins/Image \ -append "console=ttyAMA0 earlyprintk=serial panic=-1" \ -no-shutdown -no-reboot Just in case, the QEMU version is: $ qemu-system-aarch64 --version QEMU emulator version 6.2.94 (v5.2.0-rc3-12124-g81c7ed41a1) Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers Then, I recorded the timestamp of when the "Kernel panic" line was printed to the kernel log. The measurements were done on 5 kernel flavors: master (mainline commit a19944809fe99): master-no-stack-traces (stack trace collection commented out) master-no-stack-depot (saving to stack depot commented out) up-scs-stacks-v3 (collecting stack traces from SCS) up-scs-stacks-v3-noscs (up-scs-stacks-v3 with __noscs marking) (The last flavor is included just for the record: it produces an unexpected slowdown. The likely reason is that helper functions stop getting inlined.) All the branches can be found here: https://github.com/xairy/linux/branches/all The measurements were performed for Generic and HW_TAGS KASAN modes. The .configs are here (essentially, defconfig + SCS + KASAN): Generic KASAN: https://gist.github.com/xairy/d527ad31c0b54898512c92898d62beed HW_TAGS KASAN: https://gist.github.com/xairy/390e4ef0140de3f4f9a49efe20708d21 The results: Generic KASAN ------------- master-no-stack-traces: 8.03 master: 11.55 (+43.8%) master-no-stack-depot: 11.53 (+43.5%) up-scs-stacks-v3: 8.31 (+3.4%) up-scs-stacks-v3-noscs: 9.11 (+13.4%) HW_TAGS KASAN ------------- master-no-stack-traces: 3.31 master: 5.01 (+51%) master-no-stack-depot: 4.85 (+47%) up-scs-stacks-v3: 3.49 (+5.4%) up-scs-stacks-v3-noscs: 4.27 (+29%) The deviation for all numbers above is ~0.05. As can be seen, the up-scs-stacks-v3 flavor results in a significantly faster boot compared to master. Andrey Konovalov (3): arm64, scs: expose irq_shadow_call_stack_ptr kasan, arm64: implement stack_trace_save_shadow kasan: use stack_trace_save_shadow arch/arm64/include/asm/scs.h | 10 +++++- arch/arm64/kernel/irq.c | 4 +-- arch/arm64/kernel/sdei.c | 3 -- mm/kasan/common.c | 66 +++++++++++++++++++++++++++++++++++- 4 files changed, 75 insertions(+), 8 deletions(-)