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_PASS, T_DKIMWL_WL_HIGH,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 C4ABCC004C9 for ; Tue, 7 May 2019 06:05:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8E8EC205C9 for ; Tue, 7 May 2019 06:05:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1557209107; bh=b5n7aL0jy61kZcvf177QrIp1CQWhvFLaSUq005Z4tgk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=LOepy/9IMnGV4YW+yoOC1Qgp5TERRfx3mhRC58GJZpzNpSVze1kLRmzTfLg9+agVN V5mMEaLAbKKMU6n70JpAWAzAPZMvD40Mann7AkRjFYbidup/oiKdQPxlZOu6suhsnI l5+LfFFZe9clnipiiESf5+RwB6B+nzWu3o3qFfsw= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727501AbfEGFeV (ORCPT ); Tue, 7 May 2019 01:34:21 -0400 Received: from mail.kernel.org ([198.145.29.99]:54196 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727478AbfEGFeS (ORCPT ); Tue, 7 May 2019 01:34:18 -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 6A44420989; Tue, 7 May 2019 05:34:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1557207257; bh=b5n7aL0jy61kZcvf177QrIp1CQWhvFLaSUq005Z4tgk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oZAYMyC6xI9WaR18EHD2hOW7nsOYMiBhbqALkyYbT/L5mg2OjdYlpX3ZUgwPSDCmd XTezQtRJUcjMOVGDHHVSUTI8vpjskPOohz4cwSLwh1IimTEqTYCA3AJzm7EUNxmRGB RWB9GJG6e8yEFZQUUqLTqKfOV5RKQfuaiYQb7BCc= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Baoquan He , Borislav Petkov , Thomas Garnier , "Kirill A . Shutemov" , "H. Peter Anvin" , Andy Lutomirski , Dave Hansen , Ingo Molnar , Kees Cook , Peter Zijlstra , Thomas Gleixner , frank.ramsay@hpe.com, herbert@gondor.apana.org.au, kirill@shutemov.name, mike.travis@hpe.com, x86-ml , yamada.masahiro@socionext.com, Sasha Levin Subject: [PATCH AUTOSEL 5.0 54/99] x86/mm/KASLR: Fix the size of the direct mapping section Date: Tue, 7 May 2019 01:31:48 -0400 Message-Id: <20190507053235.29900-54-sashal@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190507053235.29900-1-sashal@kernel.org> References: <20190507053235.29900-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: Baoquan He [ Upstream commit ec3937107ab43f3e8b2bc9dad95710043c462ff7 ] kernel_randomize_memory() uses __PHYSICAL_MASK_SHIFT to calculate the maximum amount of system RAM supported. The size of the direct mapping section is obtained from the smaller one of the below two values: (actual system RAM size + padding size) vs (max system RAM size supported) This calculation is wrong since commit b83ce5ee9147 ("x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52"). In it, __PHYSICAL_MASK_SHIFT was changed to be 52, regardless of whether the kernel is using 4-level or 5-level page tables. Thus, it will always use 4 PB as the maximum amount of system RAM, even in 4-level paging mode where it should actually be 64 TB. Thus, the size of the direct mapping section will always be the sum of the actual system RAM size plus the padding size. Even when the amount of system RAM is 64 TB, the following layout will still be used. Obviously KALSR will be weakened significantly. |____|_______actual RAM_______|_padding_|______the rest_______| 0 64TB ~120TB Instead, it should be like this: |____|_______actual RAM_______|_________the rest______________| 0 64TB ~120TB The size of padding region is controlled by CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING, which is 10 TB by default. The above issue only exists when CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING is set to a non-zero value, which is the case when CONFIG_MEMORY_HOTPLUG is enabled. Otherwise, using __PHYSICAL_MASK_SHIFT doesn't affect KASLR. Fix it by replacing __PHYSICAL_MASK_SHIFT with MAX_PHYSMEM_BITS. [ bp: Massage commit message. ] Fixes: b83ce5ee9147 ("x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52") Signed-off-by: Baoquan He Signed-off-by: Borislav Petkov Reviewed-by: Thomas Garnier Acked-by: Kirill A. Shutemov Cc: "H. Peter Anvin" Cc: Andy Lutomirski Cc: Dave Hansen Cc: Ingo Molnar Cc: Kees Cook Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: frank.ramsay@hpe.com Cc: herbert@gondor.apana.org.au Cc: kirill@shutemov.name Cc: mike.travis@hpe.com Cc: thgarnie@google.com Cc: x86-ml Cc: yamada.masahiro@socionext.com Link: https://lkml.kernel.org/r/20190417083536.GE7065@MiWiFi-R3L-srv Signed-off-by: Sasha Levin --- arch/x86/mm/kaslr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c index 3f452ffed7e9..d669c5e797e0 100644 --- a/arch/x86/mm/kaslr.c +++ b/arch/x86/mm/kaslr.c @@ -94,7 +94,7 @@ void __init kernel_randomize_memory(void) if (!kaslr_memory_enabled()) return; - kaslr_regions[0].size_tb = 1 << (__PHYSICAL_MASK_SHIFT - TB_SHIFT); + kaslr_regions[0].size_tb = 1 << (MAX_PHYSMEM_BITS - TB_SHIFT); kaslr_regions[1].size_tb = VMALLOC_SIZE_TB; /* -- 2.20.1