Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp334766imm; Wed, 11 Jul 2018 03:22:40 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfgXDE1F2auxjbLF2B88ZntCpaYbMuiLBSVuJBh6WdPTH4t3aM8AIkxcnz6OpVBm6ZxqWaO X-Received: by 2002:a17:902:4101:: with SMTP id e1-v6mr28298127pld.205.1531304560596; Wed, 11 Jul 2018 03:22:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531304560; cv=none; d=google.com; s=arc-20160816; b=cQ1sdPcwCCFTDwh4cgPRKYZplSf5Ejc8W9NJ+pbbBSZKFlY1k1JOp+u1FKtaST+vcU qDzNKaIxT2XR+r1ZLPfekRQ0i10qIozuHtI4PvhsSCr2zZMzBvNPz2lGtNUdXLyQWghf 9Auqc/m8BIbEfhM2P7lrljjsRSoDY9gG1+okkTtVSNVAKksQBb5d7quqCmcdS2CrV5Q5 qaQ8zzw+pDTsNbp733cZdm7d3sJPYvyhhquUzuAQGL70Qe8TWsXrckK9B46lxdoqZNiG 14nSdWEesvv2rChN84FdNDQzAx360eIFFOT0Sy4H5irBN0OVqn+iGrOZGp4hCvolQqBS hGkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=1sXLHMyNTsZREzLAosRgONvTnQO+bFkawW3C1UILwVg=; b=ETiR31rU4WwXPPoieTwqBDtDhHeXimSYetvebtn14JSl7aSEOsuEq8yVKFWke6GkmR Ex4UvkL3Ex/5hkxROT2j4ruPgsAPaPQSpvUBlt/9kuZvQuzSaJ6QOH4OEvwFJ4WFNwO/ SaCN5dEY4rpB2cjVJXtn4EeB1jxdsjg9SYc2OP9d8O7e9F+enaLAQi3xffA+ee3tpXU3 QQhb9f6DZGhaFjRyLhdUpbSgtWjzqgQrfKTOzY515fDv9F/rmDQ8vAQY9ViQyPTJMl3z MpSNJ04k6kEE5p/zTNX7GwiahDoTHbg66Rt3PW1QxYUkbZreiuwbbtkFVacgtqppxANr OPrg== ARC-Authentication-Results: i=1; mx.google.com; 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 207-v6si18225912pga.113.2018.07.11.03.22.25; Wed, 11 Jul 2018 03:22:40 -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; 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 S1732358AbeGKKJz (ORCPT + 99 others); Wed, 11 Jul 2018 06:09:55 -0400 Received: from mail.cn.fujitsu.com ([183.91.158.132]:10319 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726460AbeGKKJy (ORCPT ); Wed, 11 Jul 2018 06:09:54 -0400 X-IronPort-AV: E=Sophos;i="5.43,368,1503331200"; d="scan'208";a="42115580" Received: from unknown (HELO cn.fujitsu.com) ([10.167.33.5]) by heian.cn.fujitsu.com with ESMTP; 11 Jul 2018 18:06:19 +0800 Received: from G08CNEXCHPEKD02.g08.fujitsu.local (unknown [10.167.33.83]) by cn.fujitsu.com (Postfix) with ESMTP id 2FA3E4B473E7; Wed, 11 Jul 2018 18:06:20 +0800 (CST) Received: from localhost.localdomain (10.167.225.56) by G08CNEXCHPEKD02.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 11 Jul 2018 18:06:16 +0800 Date: Wed, 11 Jul 2018 18:04:45 +0800 From: Chao Fan To: , , , CC: , , , Subject: Re: Bug report about KASLR and ZONE_MOVABLE Message-ID: <20180711100445.GA6742@localhost.localdomain> References: <20180711094244.GA2019@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20180711094244.GA2019@localhost.localdomain> User-Agent: Mutt/1.10.0 (2018-05-17) X-Originating-IP: [10.167.225.56] X-yoursite-MailScanner-ID: 2FA3E4B473E7.A9C0B X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-From: fanc.fnst@cn.fujitsu.com X-Spam-Status: No Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 11, 2018 at 05:42:44PM +0800, Chao Fan wrote: >Hi all, > >I found there is a BUG about KASLR and ZONE_MOVABLE. > >When users use 'kernelcore=' parameter without 'movable_node', >movable memory is evenly distributed to all nodes. The size of >ZONE_MOVABLE depends on the kernel parameter 'kernelcore=' and >'movablecore='. >But sometiomes, KASLR may put the uncompressed kernel to the >tail position of a node, which will cause the kernel memory >set as ZONE_MOVABLE. This region can not be offlined. > >Here is a very simple test in my qemu-kvm machine, there is >only one node: > >The command line: >[root@localhost ~]# cat /proc/cmdline >BOOT_IMAGE=/vmlinuz-4.18.0-rc3+ root=/dev/mapper/fedora_localhost--live-root >ro resume=/dev/mapper/fedora_localhost--live-swap >rd.lvm.lv=fedora_localhost-live/root rd.lvm.lv=fedora_localhost-live/swap >console=ttyS0 earlyprintk=ttyS0,115200n8 memblock=debug kernelcore=50% > >I use 'kernelcore=50%' here. > >Here is my early print result, I print the random_addr after KASLR chooses >physical memory: >early console in extract_kernel >input_data: 0x000000000266b3b1 >input_len: 0x00000000007d8802 >output: 0x0000000001000000 >output_len: 0x0000000001e15698 >kernel_total_size: 0x0000000001a8b000 >trampoline_32bit: 0x000000000009d000 >booted via startup_32() >Physical KASLR using RDRAND RDTSC... >random_addr: 0x000000012f000000 >Virtual KASLR using RDRAND RDTSC... > >The address for kernel is 0x000000012f000000 > >Here is the log of ZONE: >[ 0.000000] Zone ranges: >[ 0.000000] DMA [mem 0x0000000000001000-0x0000000000ffffff] >[ 0.000000] DMA32 [mem 0x0000000001000000-0x00000000ffffffff] >[ 0.000000] Normal [mem 0x0000000100000000-0x00000001f57fffff] >[ 0.000000] Device empty >[ 0.000000] Movable zone start for each node >[ 0.000000] Node 0: 0x000000011b000000 >[ 0.000000] Early memory node ranges >[ 0.000000] node 0: [mem 0x0000000000001000-0x000000000009efff] >[ 0.000000] node 0: [mem 0x0000000000100000-0x00000000bffd6fff] >[ 0.000000] node 0: [mem 0x0000000100000000-0x00000001f57fffff] >[ 0.000000] Initmem setup node 0 [mem >0x0000000000001000-0x00000001f57fffff] > >Only one node in my machine, ZONE_MOVABLE begins from 0x000000011b000000, >which is lower than 0x000000012f000000. >So KASLR put the kernel to the ZONE_MOVABLE. >Try to solve this problem, I think there should be a new tactic in function >find_zone_movable_pfns_for_nodes() of mm/page_alloc.c. If kernel is uncompressed >in a tail position, then just set the memory after the kernel as ZONE_MOVABLE, >at the same time, memory in other nodes will be set as ZONE_MOVABLE. Sorry, mistake here. It should be: "more memory in other nodes will be set as ZONE_MOVABLE". Thanks, Chao Fan > >If there is something wrong, pleas let me know. And any comments will be welcome. > >Thanks, >Chao Fan