Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2159961imm; Mon, 28 May 2018 02:54:53 -0700 (PDT) X-Google-Smtp-Source: AB8JxZozYC6dcxm3VAfWSnJe7N12bycg5LUubvCkzZEpBDENd4/EzkNCGtmVrZXSZK7dh28GSP7M X-Received: by 2002:a63:7209:: with SMTP id n9-v6mr10138799pgc.146.1527501293767; Mon, 28 May 2018 02:54:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527501293; cv=none; d=google.com; s=arc-20160816; b=LjMhQw1r30m1MxGBWE+qeuDIa2M7Pb9JM4a1p1rmp9RLkejoYuNjHt1rs9FO7PlXhz oiGMksb37M+MT2w0fFxQuXX6ibQ0yeHtyLAHSzahhm/gIIq6xkB2glvux52ncqtovdhR a4OoL5lQoTpBYvVlJiWTfqti1ZM0z6RaXJgTW9eVtE42ClB2yS6LzdgT6fGVho1ECZly 3DN9rKxpfAV1VYSXrvdZHXXq1oBuhMEDq9z/tku7fFKLRcrmXm313rw1E9M+4rrjGFB2 SgWJ1YIm82qmrEk1xguDmTO/Ksl1YB/ufL9O7eZ5zhakTi5NKEe0YFCZPSxKWf9LUewQ ETkA== 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=/8Gyw337qbJvsuAAPfaeQ4OIRvinBKpj5z3JLEsVpvc=; b=ON/0jd0tPPc/GIAjWUdM3Os0geM4nXtQgUD5NyzS8yZ75zIctQd7LRTXPs1KhN0Ms9 lOFBcIG9deRQLRvh5MfNm3WybrDxteG2AbIzhz7H/yDqnfHEdqNwTwxdt1rihUjWgTDn C394YrH4Zg4Xl30vwsaJ4YSN/LFi7LU4NPTKPZBL5howNL1sk+YEsFVLW8708nKS3caH xiQ/LzK7Y8W+WXafPWf2s/BsItwS+wbw3b68+3LJ5Vh/fhLDmX1t4dTH8VJCwSQuU33Z EOc38hYa7THC9CDLK0lV4xW5SVB8WQhTsS5xsz9HynjMQw3urLgpED44EntEodniWeR6 yQfA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s184-v6si5329185pgb.172.2018.05.28.02.54.38; Mon, 28 May 2018 02:54:53 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754334AbeE1JyY (ORCPT + 99 others); Mon, 28 May 2018 05:54:24 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:60658 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754173AbeE1JyX (ORCPT ); Mon, 28 May 2018 05:54:23 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DF2187D668; Mon, 28 May 2018 09:54:22 +0000 (UTC) Received: from localhost (ovpn-8-24.pek2.redhat.com [10.72.8.24]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 81A79202698A; Mon, 28 May 2018 09:54:21 +0000 (UTC) Date: Mon, 28 May 2018 17:54:18 +0800 From: Baoquan He To: Ingo Molnar , Luiz Capitulino Cc: linux-kernel@vger.kernel.org, keescook@chromium.org, tglx@linutronix.de, x86@kernel.org, hpa@zytor.com, fanc.fnst@cn.fujitsu.com, yasu.isimatu@gmail.com, indou.takao@jp.fujitsu.com, douly.fnst@cn.fujitsu.com Subject: Re: [PATCH 0/2] x86/boot/KASLR: Skip specified number of 1GB huge pages when do physical randomization Message-ID: <20180528095418.GD31261@MiWiFi-R3L-srv> References: <20180516100532.14083-1-bhe@redhat.com> <20180518070046.GA18660@gmail.com> <20180518074359.GR24627@MiWiFi-R3L-srv> <20180518081919.GB11379@gmail.com> <20180518112836.GS24627@MiWiFi-R3L-srv> <20180523151022.102e3565@doriath> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180523151022.102e3565@doriath> User-Agent: Mutt/1.9.1 (2017-09-22) X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Mon, 28 May 2018 09:54:22 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Mon, 28 May 2018 09:54:22 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.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 05/23/18 at 03:10pm, Luiz Capitulino wrote: > On Fri, 18 May 2018 19:28:36 +0800 > Baoquan He wrote: > > > > Note that it's not KASLR specific: if we had some other kernel feature that tried > > > to allocate a piece of memory from what appears to be perfectly usable generic RAM > > > we'd have the same problems! > > > > Hmm, this may not be the situation for 1GB huge pages. For 1GB huge > > pages, the bug is that on KVM guest with 4GB ram, when user adds > > 'default_hugepagesz=1G hugepagesz=1G hugepages=1' to kernel > > command-line, if 'nokaslr' is specified, they can get 1GB huge page > > allocated successfully. If remove 'nokaslr', namely KASLR is enabled, > > the 1GB huge page allocation failed. > > Let me clarify that this issue is not specific to KVM in any way. The same > issue happens on bare-metal, but if you have lots of memory you'll hardly > notice it. On the other hand, it's common to create KVM guests with a few > GBs of memory. In those guests, you may not be able to get a 1GB hugepage > at all if kaslr is enabled. > > This series is a simple fix for this bug. It hooks up into already existing > KASLR code that scans memory regions to be avoided. The memory hotplug > issue is left for another day. Exactly. This issue is about kernel being randomized into good 1GB huge pages to break later huge page allocation, and we can only scan memory to know where 1GB huge page is located and avoid them. The memory hotplug issue is about kernel being randomized into movable memory regions, and we need read ACPI SRAT table to retrieve the attribute of memory regions to know if it's movable, then avoid it if yes. > > Now, if I understand what Ingo is saying is that he wants to see all problems > solved with a generic solution vs. a specific solution for each problem. Hmm, if we understand Ingo's words correctly, for these two issues, seems there isn't a generic solution to solve both of them. We can only fix them separately. Hi Ingo, Ping! Not sure if my above understanding is correct. Could you confirm if I have understood your comments and if the solution of this patchset is right? Thanks Baoquan