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=-5.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,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 2C5F4C04A6B for ; Mon, 6 May 2019 14:59:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F2C422053B for ; Mon, 6 May 2019 14:59:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1557154741; bh=01XHoYpFEAwL43J9OmQuL6FADk+rtJXZIizhcQvoyu4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=qtwHGYqhFL8UZrIWijla+B46yIN0hjPKVsOyu5O0pqa36Uni3wfZtyN4nvSUF3KUr 4cKGxS71txQbjgrU65md8pTsOSSMx7SfTKahIrsveU3s+BZ3T/zBEO9H0E/YjMjAdw W+6ZCg2ru3qMp21zYBF0PjuQP81kMvQ3GciC/ua4= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728657AbfEFOn0 (ORCPT ); Mon, 6 May 2019 10:43:26 -0400 Received: from mail.kernel.org ([198.145.29.99]:38950 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728652AbfEFOnZ (ORCPT ); Mon, 6 May 2019 10:43:25 -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 21AFD20449; Mon, 6 May 2019 14:43:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1557153804; bh=01XHoYpFEAwL43J9OmQuL6FADk+rtJXZIizhcQvoyu4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kdxwWAX8vp/Ld8t6pHunrQ+UYlhnvov6864/7xi3ETYbN+31fBmKQZVB7aLVw3M+I qe9esChRQ5V05mPR/R1G7XYLRfXmOloAcs4MjMi6T9NNZzbmfe5/lvqeJBiIFwbZhb 7tvldViDIiCZWSkmCPP2fENMoDM1ICofxWzHj9FA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, 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 Subject: [PATCH 4.19 95/99] x86/mm/KASLR: Fix the size of the direct mapping section Date: Mon, 6 May 2019 16:33:08 +0200 Message-Id: <20190506143102.453965144@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190506143053.899356316@linuxfoundation.org> References: <20190506143053.899356316@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Baoquan He commit ec3937107ab43f3e8b2bc9dad95710043c462ff7 upstream. 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: Greg Kroah-Hartman --- arch/x86/mm/kaslr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/x86/mm/kaslr.c +++ b/arch/x86/mm/kaslr.c @@ -93,7 +93,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; /*