From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,T_DKIMWL_WL_HIGH,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 62A90C282CE for ; Tue, 4 Jun 2019 23:25:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 395D92085A for ; Tue, 4 Jun 2019 23:25:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559690727; bh=bS1WUeWETqkknD0xFwDKGa0SWyHszAHTUtGTiwD4rIs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=TxKhWpMl6b8KMnvOj4SXkMk2W0o2S7Au96/mdqwbQhkeTrqfxXBudn9Y+MFsuykaI hC49djJDGek6CwcuJRkv9ELSYmGBxTx3Y+AAPrlNYvHMU5hpc7/ApFJYJFYrKnlRo5 lS5pQmSxE2TcFU+yqS5urvVDzqv7cV4eRJngw9pk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727995AbfFDXZ0 (ORCPT ); Tue, 4 Jun 2019 19:25:26 -0400 Received: from mail.kernel.org ([198.145.29.99]:37044 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727960AbfFDXZY (ORCPT ); Tue, 4 Jun 2019 19:25:24 -0400 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7CBBD2085A; Tue, 4 Jun 2019 23:25:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559690722; bh=bS1WUeWETqkknD0xFwDKGa0SWyHszAHTUtGTiwD4rIs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AzikZmCSmW+ZwrWyRVaxnSdXdS/A1Tj3ZGQb0Iqjoe0RK/B94fc9DxsULLFvpWKA0 O2oM3DmkT8smfTiCMIGn6e2uapR/paDef3819nr7BvpwxTVHLtxx0U5cdA8f17i2Uz o12HCi2xJvk4msYod/Adl88WPtMgLYWNmZ7PmpGo= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Mark Rutland , Catalin Marinas , Ard Biesheuvel , Anshuman Khandual , Will Deacon , Sasha Levin Subject: [PATCH AUTOSEL 4.9 11/17] arm64/mm: Inhibit huge-vmap with ptdump Date: Tue, 4 Jun 2019 19:24:52 -0400 Message-Id: <20190604232459.7745-11-sashal@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190604232459.7745-1-sashal@kernel.org> References: <20190604232459.7745-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Mark Rutland [ Upstream commit 7ba36eccb3f83983a651efd570b4f933ecad1b5c ] The arm64 ptdump code can race with concurrent modification of the kernel page tables. At the time this was added, this was sound as: * Modifications to leaf entries could result in stale information being logged, but would not result in a functional problem. * Boot time modifications to non-leaf entries (e.g. freeing of initmem) were performed when the ptdump code cannot be invoked. * At runtime, modifications to non-leaf entries only occurred in the vmalloc region, and these were strictly additive, as intermediate entries were never freed. However, since commit: commit 324420bf91f6 ("arm64: add support for ioremap() block mappings") ... it has been possible to create huge mappings in the vmalloc area at runtime, and as part of this existing intermediate levels of table my be removed and freed. It's possible for the ptdump code to race with this, and continue to walk tables which have been freed (and potentially poisoned or reallocated). As a result of this, the ptdump code may dereference bogus addresses, which could be fatal. Since huge-vmap is a TLB and memory optimization, we can disable it when the runtime ptdump code is in use to avoid this problem. Cc: Catalin Marinas Fixes: 324420bf91f60582 ("arm64: add support for ioremap() block mappings") Acked-by: Ard Biesheuvel Signed-off-by: Mark Rutland Signed-off-by: Anshuman Khandual Signed-off-by: Will Deacon Signed-off-by: Sasha Levin --- arch/arm64/mm/mmu.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c index 0a56898f8410..efd65fc85238 100644 --- a/arch/arm64/mm/mmu.c +++ b/arch/arm64/mm/mmu.c @@ -765,13 +765,18 @@ void *__init fixmap_remap_fdt(phys_addr_t dt_phys) int __init arch_ioremap_pud_supported(void) { - /* only 4k granule supports level 1 block mappings */ - return IS_ENABLED(CONFIG_ARM64_4K_PAGES); + /* + * Only 4k granule supports level 1 block mappings. + * SW table walks can't handle removal of intermediate entries. + */ + return IS_ENABLED(CONFIG_ARM64_4K_PAGES) && + !IS_ENABLED(CONFIG_ARM64_PTDUMP_DEBUGFS); } int __init arch_ioremap_pmd_supported(void) { - return 1; + /* See arch_ioremap_pud_supported() */ + return !IS_ENABLED(CONFIG_ARM64_PTDUMP_DEBUGFS); } int pud_set_huge(pud_t *pud, phys_addr_t phys, pgprot_t prot) -- 2.20.1