From patchwork Mon Apr 25 11:55:55 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Rutland X-Patchwork-Id: 12825649 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 252E5C433EF for ; Mon, 25 Apr 2022 11:57:31 +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=IlHlM4DOlKuvi29se5/Fsjq5G46boaMtZyJp8cm90X4=; b=LiFQkXUkb32sh9 m+vz/FJGILqCHafzZGE4YlX9/1ybBDFr14zqou1bG+pNUV+91Gus4NrfiNt0671U1Hl4l5EWCDV/5 K8/lVm4yn6z8QElSwtvUjpLNRA5LJOMGjVPVsWDphWSDgSHolX55zGlnCU0OedD0W6w5UMP3U6X3/ 5oRWgCdmYTj5/jf4XTZbI0SpR74Qo3xZH+bWPGUCiM3+aMFhct2Qb1SgWK9OxzJl0isuSc0Zyzxlw zt1b2dF8ZdH1XFgeYmrtNNSyd0Xd1i7Ec2EFOwKy/QcWr//EKp37nLlzpH3nDuVlf3TN0nGXwtRxq 8Uz71i1Z1l1vYCMVnucQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nixKC-009NpC-Fs; Mon, 25 Apr 2022 11:56:16 +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 1nixK8-009Nnv-PF for linux-arm-kernel@lists.infradead.org; Mon, 25 Apr 2022 11:56:14 +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 CDAC51FB; Mon, 25 Apr 2022 04:56:10 -0700 (PDT) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 93A383F73B; Mon, 25 Apr 2022 04:56:09 -0700 (PDT) From: Mark Rutland To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: akpm@linux-foundation.org, alex.popov@linux.com, catalin.marinas@arm.com, keescook@chromium.org, luto@kernel.org, mark.rutland@arm.com, will@kernel.org Subject: [PATCH 0/8] stackleak: fixes and rework Date: Mon, 25 Apr 2022 12:55:55 +0100 Message-Id: <20220425115603.781311-1-mark.rutland@arm.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220425_045612_901160_269B1BBF X-CRM114-Status: GOOD ( 15.08 ) 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 This series reworks the stackleak code. The first patch fixes some latent issues on arm64, and the subsequent patches improve the code to improve clarity and permit better code generation. I started working on this as a tangent from rework to arm64's stacktrace code. Looking at users of the `on_*_stack()` helpers I noticed that the assembly generated for stackleak was particularly awful as it performed a lot of redundant work and also called instrumentable code, which isn't sound. The first patch fixes the major issues on arm64, and is Cc'd to stable for backporting. The second patch is a trivial optimization for when stackleak is dynamically disabled. The subsequent patches rework the way stackleak manipulates the stack boundary values. This is partically for clarity (e.g. with separate 'low' and 'high' boundary variables), and also permits the compiler to generate more optimal assembly by generating the high and low bounds from the same base. Patch 5 changes the way that `current->lowest_stack` is reset prior to return to userspace. The existing code uses an undocumented offset relative to the top of the stack which doesn't make much sense (as thie sometimes falls within the task's pt_regs, or sometimes adds 600+ bytes to erase upon the next exit to userspace). For now I've removed the offset entirely. Patch 7 adds stackleak_erase_on_task_stack() and stackleak_erase_off_task_stack() that can be used when a caller knows they're always on or off the task stack respectively, avoiding redundant logic to check this and generate the high boundary value. On arm64 we always call stackleak_erase() while on the task stack, so this is used in patch 8. Testing the series on arm64 with a QEMU HVF VM on an M1 Macbook Pro with a few microbenchmarks shows a small but measureable improvement when stackleak is enabled (relative to v5.18-rc1): * Calling getpid 1^22 times in a loop (avg 50 runs) Before: 0.652099387 seconds ( +- 0.13% ) After: 0.641005661 seconds ( +- 0.13% ) ~1.7% time decrease * perf bench sched pipe (single run) Before: 2.138 seconds total After: 2.118 seconds total ~0.93% time decrease I also tested "perf bench sched messaging" but the noise outweighed the difference. While the improvement is small, I think the improvement to clarity and code generation is a win regardless. Thanks, Mark. Mark Rutland (8): arm64: stackleak: fix current_top_of_stack() stackleak: move skip_erasing() check earlier stackleak: rework stack low bound handling stackleak: clarify variable names stackleak: rework stack high bound handling stackleak: remove redundant check stackleak: add on/off stack variants arm64: entry: use stackleak_erase_on_task_stack() arch/arm64/include/asm/processor.h | 10 ++- arch/arm64/kernel/entry.S | 2 +- include/linux/stackleak.h | 29 ++++++++- kernel/stackleak.c | 99 ++++++++++++++++++++---------- 4 files changed, 98 insertions(+), 42 deletions(-)