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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham 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 67BF2C6778D for ; Tue, 11 Sep 2018 07:22:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 20BE420854 for ; Tue, 11 Sep 2018 07:22:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 20BE420854 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727734AbeIKMUL (ORCPT ); Tue, 11 Sep 2018 08:20:11 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:47626 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726840AbeIKMUK (ORCPT ); Tue, 11 Sep 2018 08:20:10 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3CC4980825A9; Tue, 11 Sep 2018 07:22:14 +0000 (UTC) Received: from localhost (ovpn-8-16.pek2.redhat.com [10.72.8.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 09D14101041E; Tue, 11 Sep 2018 07:22:12 +0000 (UTC) Date: Tue, 11 Sep 2018 15:22:09 +0800 From: Baoquan He To: Ingo Molnar Cc: tglx@linutronix.de, hpa@zytor.com, thgarnie@google.com, kirill.shutemov@linux.intel.com, x86@kernel.org, linux-kernel@vger.kernel.org, Peter Zijlstra Subject: Re: [PATCH v2 1/3] x86/mm/KASLR: Fix the wrong calculation of kalsr region initial size Message-ID: <20180911072209.GV1740@192.168.1.3> References: <20180909124946.17988-1-bhe@redhat.com> <20180910061839.GA90334@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180910061839.GA90334@gmail.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Tue, 11 Sep 2018 07:22:14 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Tue, 11 Sep 2018 07:22:14 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'bhe@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/10/18 at 08:18am, Ingo Molnar wrote: > > * Baoquan He wrote: > > > In memory KASLR, __PHYSICAL_MASK_SHIFT is taken to calculate the > > initial size of the direct mapping region. This is right in the > > old code where __PHYSICAL_MASK_SHIFT was equal to MAX_PHYSMEM_BITS, > > 46bit, and only 4-level mode was supported. >...... > - what does 'memory KASLR' mean? All KASLR deals with memory. Thanks for your reviewing. I have updated patch log according to your comments. For this one, Thomas Garnier calls it memory section KASLR, to differentiate with kernel text KASLR. I would like to call it memory region KASLR, is it OK? Paste the updated patch here. >From df0df638a24aafeee6862f184769c4fb96f29afb Mon Sep 17 00:00:00 2001 From: Baoquan He Date: Fri, 29 Jun 2018 09:43:28 +0800 Subject: [PATCH] x86/mm/KASLR: Fix the wrong calculation of memory region initial size In memory region KASLR, __PHYSICAL_MASK_SHIFT is taken to calculate the initial size of the direct mapping region. This is correct in the old code where __PHYSICAL_MASK_SHIFT was equal to MAX_PHYSMEM_BITS, 46 bits, and only 4-level mode was supported. Later, in commit: b83ce5ee91471d ("x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52"), __PHYSICAL_MASK_SHIFT was changed to be always 52 bits, no matter it's 5-level or 4-level. This is wrong for 4-level paging. Then when we adapt physical memory region size based on available memory, it will overflow if the amount of system RAM and the padding is bigger than 64 TB. In fact, here MAX_PHYSMEM_BITS should be used instead. Fix it by replacing __PHYSICAL_MASK_SHIFT with MAX_PHYSMEM_BITS. Acked-by: Kirill A. Shutemov Reviewed-by: Thomas Garnier Signed-off-by: Baoquan He --- 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 61db77b0eda9..0988971069c9 100644 --- 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; /* -- 2.13.6