Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4808394yba; Tue, 30 Apr 2019 04:51:31 -0700 (PDT) X-Google-Smtp-Source: APXvYqz810YKqzqbrmiIyo+33Vs0zzx4UxAhy5gkuvR63ZpshUAKc5Ch2DUv+MGqQfh1dVRoJnN6 X-Received: by 2002:a63:a1a:: with SMTP id 26mr7328589pgk.11.1556625090879; Tue, 30 Apr 2019 04:51:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556625090; cv=none; d=google.com; s=arc-20160816; b=U1lYnBNY2pDrr1fpW6Ml+glHx39ix/RAFng43drI4pxp5KIR93YIOlu35s8IG0J32w abGNEYIurLeyvik30Iye7GdIHa7DUEIuyLNCGzAQBapjlCeRKOB+t2bS7UtRzVOiHchQ GjfX3W+9IsRp+dmq0PnXsJGtU2uD2bDJO436ECvv16OI+ZBll9zpr7In7aJxo6vyc2sV v9F20/NmxJaP2k91/lNL+U95SkB3g6TDrHoqPeUQtXUsimnrzvC3XQt5sYjpUZxZZ/2M 1FDQtVgR/ze4SVHEso+JMcq2dOJjW3rkIVie2KoOSCtAKfvfHnsP1p1RDZrFV6u3TQZC Ppnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=TryR9IbGKhlgHSPkJYNQszEpSR+qEZPA5o8+rm6JDWo=; b=iZ7ylRDtUkI0rSufkf9YDOBNvbOzCJZ1C6Xx+Z0RThQy8MpI6kzr04Dq5+syPqF4GE YrDJ3RIYCvT4lgYlpHMZJObsk3fi9IBIiXnizHDjZnJ4S6s5WHbFxM6jeSc9VUo2Flkr K6eE9K/QMVCPYJeb2sqVQqMNwldhF7IBurnm6xq79Qq7+lgL4KrBESrxT+lD2NXV+7Ef uZpXrwbG6PSbYCBvT9Kb24cTI7PTsN19icVdRoZWMBCDSb9UiQCwMoid+OpCjmKHyC5J IA463dS2rtvDyPO/EdFRq611KYZLMAzC6dLvpHEYxZco3rleFAhXTN+n9KauUGUdzIbk OxsQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=J6hgt1E7; 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 k4si16335231pgs.232.2019.04.30.04.51.14; Tue, 30 Apr 2019 04:51:30 -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; dkim=pass header.i=@kernel.org header.s=default header.b=J6hgt1E7; 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 S1731025AbfD3Lti (ORCPT + 99 others); Tue, 30 Apr 2019 07:49:38 -0400 Received: from mail.kernel.org ([198.145.29.99]:36142 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730671AbfD3Lte (ORCPT ); Tue, 30 Apr 2019 07:49:34 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E504D20449; Tue, 30 Apr 2019 11:49:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1556624973; bh=zNlQdbz+/oj7s2o7hZ2cj9AEuIuBVrfX/tbNdqzqbDs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=J6hgt1E77TRi5aayr13iqcb3T65XCP0+p2HYVeso1XW1mOW9Psvdw/+6ohsBvRWE1 0m/2CsaaeVTTAWjIDPjvUiw9XmtsPhbhsWEwZH+km2EYP7UTjVR8mUu8/jgtZfoY6f CRFPld13v2vf8H89KwID8pm8lpo9GwYMuTyprAD0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Joel Stanley , Michael Ellerman Subject: [PATCH 5.0 41/89] powerpc/mm/radix: Make Radix require HUGETLB_PAGE Date: Tue, 30 Apr 2019 13:38:32 +0200 Message-Id: <20190430113611.717806595@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190430113609.741196396@linuxfoundation.org> References: <20190430113609.741196396@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Michael Ellerman commit 8adddf349fda0d3de2f6bb41ddf838cbf36a8ad2 upstream. Joel reported weird crashes using skiroot_defconfig, in his case we jumped into an NX page: kernel tried to execute exec-protected page (c000000002bff4f0) - exploit attempt? (uid: 0) BUG: Unable to handle kernel instruction fetch Faulting instruction address: 0xc000000002bff4f0 Looking at the disassembly, we had simply branched to that address: c000000000c001bc 49fff335 bl c000000002bff4f0 But that didn't match the original kernel image: c000000000c001bc 4bfff335 bl c000000000bff4f0 When STRICT_KERNEL_RWX is enabled, and we're using the radix MMU, we call radix__change_memory_range() late in boot to change page protections. We do that both to mark rodata read only and also to mark init text no-execute. That involves walking the kernel page tables, and clearing _PAGE_WRITE or _PAGE_EXEC respectively. With radix we may use hugepages for the linear mapping, so the code in radix__change_memory_range() uses eg. pmd_huge() to test if it has found a huge mapping, and if so it stops the page table walk and changes the PMD permissions. However if the kernel is built without HUGETLBFS support, pmd_huge() is just a #define that always returns 0. That causes the code in radix__change_memory_range() to incorrectly interpret the PMD value as a pointer to a PTE page rather than as a PTE at the PMD level. We can see this using `dv` in xmon which also uses pmd_huge(): 0:mon> dv c000000000000000 pgd @ 0xc000000001740000 pgdp @ 0xc000000001740000 = 0x80000000ffffb009 pudp @ 0xc0000000ffffb000 = 0x80000000ffffa009 pmdp @ 0xc0000000ffffa000 = 0xc00000000000018f <- this is a PTE ptep @ 0xc000000000000100 = 0xa64bb17da64ab07d <- kernel text The end result is we treat the value at 0xc000000000000100 as a PTE and clear _PAGE_WRITE or _PAGE_EXEC, potentially corrupting the code at that address. In Joel's specific case we cleared the sign bit in the offset of the branch, causing a backward branch to turn into a forward branch which caused us to branch into a non-executable page. However the exact nature of the crash depends on kernel version, compiler version, and other factors. We need to fix radix__change_memory_range() to not use accessors that depend on HUGETLBFS, but we also have radix memory hotplug code that uses pmd_huge() etc that will also need fixing. So for now just disallow the broken combination of Radix with HUGETLBFS disabled. The only defconfig we have that is affected is skiroot_defconfig, so turn on HUGETLBFS there so that it still gets Radix. Fixes: 566ca99af026 ("powerpc/mm/radix: Add dummy radix_enabled()") Cc: stable@vger.kernel.org # v4.7+ Reported-by: Joel Stanley Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman --- arch/powerpc/configs/skiroot_defconfig | 1 + arch/powerpc/platforms/Kconfig.cputype | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) --- a/arch/powerpc/configs/skiroot_defconfig +++ b/arch/powerpc/configs/skiroot_defconfig @@ -260,6 +260,7 @@ CONFIG_UDF_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_PROC_KCORE=y +CONFIG_HUGETLBFS=y # CONFIG_MISC_FILESYSTEMS is not set # CONFIG_NETWORK_FILESYSTEMS is not set CONFIG_NLS=y --- a/arch/powerpc/platforms/Kconfig.cputype +++ b/arch/powerpc/platforms/Kconfig.cputype @@ -318,7 +318,7 @@ config ARCH_ENABLE_SPLIT_PMD_PTLOCK config PPC_RADIX_MMU bool "Radix MMU Support" - depends on PPC_BOOK3S_64 + depends on PPC_BOOK3S_64 && HUGETLB_PAGE select ARCH_HAS_GIGANTIC_PAGE if (MEMORY_ISOLATION && COMPACTION) || CMA default y help