Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp304841imm; Wed, 11 Jul 2018 02:47:28 -0700 (PDT) X-Google-Smtp-Source: AAOMgpespm0xMJi/tfhizEYt1/OGnubhRWsRsQfrfdPo0JcP8BDnrerxKXiP54+IVjOro0JVXtZx X-Received: by 2002:a17:902:f83:: with SMTP id 3-v6mr923222plz.282.1531302448283; Wed, 11 Jul 2018 02:47:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531302448; cv=none; d=google.com; s=arc-20160816; b=zkGWD2DaKUoTcueFqV4bw59EA9+TyURjV/flhy0eNapE6XS5R90ND06ne00h8a035C 1TVBFND1o3Ffq71jjLvP5Eoj3Ye6ByPaFDMdOiwVqUOOHpIxFdZRJ5JdZGeVqogzQxG6 ZrduzJwYHJ+VVuLIotR5lBUcA8p9V20eCVantr49jasXa5DZzkn/MQgHwAr6cuPZdMLp p5Y0xZnZven085BmmjFSAeNVoVTlakBT8pOH4XzWuz6YxncP+Rsg0cKt4SpYfOBq0u8o ESXRe6WaF9PbjdMyAyCKXl5bFOuomunENMMupRUUy4KrY+0ILtyQSa/A181onzDxFrT/ d5uA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:content-disposition :mime-version:message-id:subject:cc:to:from:date :arc-authentication-results; bh=fzNaEl92Kq32dztZ3RzYWlKFrZAjTiYdqF9ha6BQC4g=; b=eae86hRMe6crDGOf3E9ah43BajIPvUHDiV2r9F1oP7B7Xa9FzHcuT7BdLCTz9PuaY7 ROW6i20WL74nD8YcsYZ8v2HYHrs78tJkATq+lZB2/mDt3BoduJjD5VZzQBSSovL0IpYS ZspuGc0R2cCxWAGzBkzwlm6lmMdif/ah4mQhVCW2XKtpDjigoHDf7wvQikCMkCfdR9vG 7WnSPGOvSdczvOuWxQ9taX0apNRyjr6azl47+/lHrtODEzEjZyFsw/hvH6XCs5XC+6+e S2BZHAX8KoeZceVwI+Jl87iEMH/phXukJfpYlM6SAd6AZ7aEvGOt03+HcFZ3h6pBQckp nZVQ== 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 a194-v6si2344861pfa.18.2018.07.11.02.47.12; Wed, 11 Jul 2018 02:47:28 -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 S1726780AbeGKJtq (ORCPT + 99 others); Wed, 11 Jul 2018 05:49:46 -0400 Received: from mail.cn.fujitsu.com ([183.91.158.132]:50304 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726500AbeGKJtq (ORCPT ); Wed, 11 Jul 2018 05:49:46 -0400 X-IronPort-AV: E=Sophos;i="5.43,368,1503331200"; d="scan'208";a="42114445" Received: from unknown (HELO cn.fujitsu.com) ([10.167.33.5]) by heian.cn.fujitsu.com with ESMTP; 11 Jul 2018 17:44:20 +0800 Received: from G08CNEXCHPEKD02.g08.fujitsu.local (unknown [10.167.33.83]) by cn.fujitsu.com (Postfix) with ESMTP id B4D774B473EC; Wed, 11 Jul 2018 17:44:17 +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 17:44:15 +0800 Date: Wed, 11 Jul 2018 17:42:44 +0800 From: Chao Fan To: , , , CC: , , , , Subject: Bug report about KASLR and ZONE_MOVABLE Message-ID: <20180711094244.GA2019@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline User-Agent: Mutt/1.10.0 (2018-05-17) X-Originating-IP: [10.167.225.56] X-yoursite-MailScanner-ID: B4D774B473EC.AB32E 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 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. If there is something wrong, pleas let me know. And any comments will be welcome. Thanks, Chao Fan