From patchwork Mon Aug 7 18:35:52 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Rutland X-Patchwork-Id: 109582 Delivered-To: patch@linaro.org Received: by 10.140.95.78 with SMTP id h72csp1951882qge; Mon, 7 Aug 2017 11:37:40 -0700 (PDT) X-Received: by 10.98.131.141 with SMTP id h135mr1504015pfe.271.1502131060659; Mon, 07 Aug 2017 11:37:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1502131060; cv=none; d=google.com; s=arc-20160816; b=RU/jzulDfL8qRxchz56F4vmMUsIrj16GNktx9bmWv1KN1bVwutqWAtza24zgN5Ks42 zvQQg2dNPRGUTSde0FQTAuhBVHiTi0bxe9lM2QLQs8/pMGMbwHvB3yjqgiLcZqb8/m6V fn+8/ijpSYIqLriqUN7NMRCXasO4vQtXaIv3y02Qhv5Lw2tQdohOGlab8bSZx8ThFUCX 4UhHJT1Qb53CfJElv9ZjAHooB9LIq2ddhDkJum4g+ZGp+R37Qq6IlB36w/2Sa6F+KEE7 wkHgluFFhvoaCeejhyAHLf39hylp4Uq2Xjio9KukWArcd53c4pAizbYm4peYW7xv/exZ Umcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=J1QoV70zeK2xWn4Y/Ff1f+Pq9wWI5i3bZr/DV9XUGys=; b=N60snvfkWs7RB0JTmMsEl9gFVHdPFu9wSQJwMDEQI4vVJ838ChiuvTeVNrpPBnlKN+ 30d7qqCkpEg1S6bQyZyzdiHlJ130Cbh+R+SHmkiL3oI0hIhsWaONiP5vU4N1KLlCnRJ/ 5b+pzCVUUXfEuqjnKvbyCnYNEwJX5U6C2pXEKDE+LThEfT52XpgYeDGqW91RdFhHOE1t f4p1Sq1PvBq7w4gtuwO6n+TOqZNUxLxvOyUciwMCal8n1f7IFuzE8kvgxaG0+qA3STpw csnihtlJdMPV++/P4rLR0LNcACsy8Aj30U3adKg5Dg9gTqyd1qywrKlZrdLJ9KhHZtvc +MvA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 186si5049288pfu.378.2017.08.07.11.37.40; Mon, 07 Aug 2017 11:37:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751974AbdHGShi (ORCPT + 25 others); Mon, 7 Aug 2017 14:37:38 -0400 Received: from foss.arm.com ([217.140.101.70]:52482 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751426AbdHGShh (ORCPT ); Mon, 7 Aug 2017 14:37:37 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0317715B2; Mon, 7 Aug 2017 11:37:37 -0700 (PDT) Received: from leverpostej.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id E4E493F577; Mon, 7 Aug 2017 11:37:34 -0700 (PDT) From: Mark Rutland To: linux-arm-kernel@lists.infradead.org Cc: ard.biesheuvel@linaro.org, catalin.marinas@arm.com, james.morse@arm.com, labbott@redhat.com, linux-kernel@vger.kernel.org, luto@amacapital.net, mark.rutland@arm.com, matt@codeblueprint.co.uk, will.deacon@arm.com, kernel-hardening@lists.openwall.com, keescook@chromium.org Subject: [PATCH 01/14] arm64: remove __die()'s stack dump Date: Mon, 7 Aug 2017 19:35:52 +0100 Message-Id: <1502130965-18710-2-git-send-email-mark.rutland@arm.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1502130965-18710-1-git-send-email-mark.rutland@arm.com> References: <1502130965-18710-1-git-send-email-mark.rutland@arm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Our __die() implementation tries to dump the stack memory, in addition to a backtrace, which is problematic. For contemporary 16K stacks, this can be a lot of data, which can take a long time to dump, and can push other useful context out of the kernel's printk ringbuffer (and/or a user's scrollback buffer on an attached console). Additionally, the code implicitly assumes that the SP is on the task's stack, and tries to dump everything between the SP and the highest task stack address. When the SP points at an IRQ stack (or is corrupted), this makes the kernel attempt to dump vast amounts of VA space. With vmap'd stacks, this may result in erroneous accesses to peripherals. This patch removes the memory dump, leaving us to rely on the backtrace, and other means of dumping stack memory such as kdump. Signed-off-by: Mark Rutland Cc: Ard Biesheuvel Cc: Catalin Marinas Cc: Laura Abbott Cc: James Morse Cc: Will Deacon --- arch/arm64/kernel/traps.c | 2 -- 1 file changed, 2 deletions(-) -- 1.9.1 diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c index c2a81bf..9633773 100644 --- a/arch/arm64/kernel/traps.c +++ b/arch/arm64/kernel/traps.c @@ -237,8 +237,6 @@ static int __die(const char *str, int err, struct pt_regs *regs) end_of_stack(tsk)); if (!user_mode(regs)) { - dump_mem(KERN_EMERG, "Stack: ", regs->sp, - THREAD_SIZE + (unsigned long)task_stack_page(tsk)); dump_backtrace(regs, tsk); dump_instr(KERN_EMERG, regs); }