Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1214728imm; Wed, 23 May 2018 12:10:52 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrYO6PiMFMOUNfIL5zSm4dqwhC0i2PyGPfrRDM/8kgfH2ur+arotgOSVG4+5hmTjamATVIm X-Received: by 2002:a17:902:3001:: with SMTP id u1-v6mr4137182plb.376.1527102652458; Wed, 23 May 2018 12:10:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527102652; cv=none; d=google.com; s=arc-20160816; b=mcxUoiGDdPgMmvwuErmueiVSOspuACp7BLBA/bYOKtVsJ9GJQFi6sikmInw5J7ZFUr Ynz7y0yBMaKozbwZkXThs4cXDWXE2rEY2b2Q9r78asy1htY0O2534kswFR49RU+/0ff7 Y82CU8KVf77Nd301BSqVx462IEuoso3FQVVSJTY5dTsSm/XtYGhvlbzICerVKV1U/JPg hW2G8eGPTN9/FjPM/vJEGbyj74axeZMypi1gr+n71u6yzkWcUIGAlTLwGyfIhHOLYBKf LbxySS7dKlD8UN53bho51Zksi4KUBZ/XF2KTN6Po+O4trDQdnLOA5Foxi97WGZXzk/v/ ppnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:arc-authentication-results; bh=PcXtHjFy+2YTpbszLabdMGxoYmUlTPmsXu0h2QqlKh4=; b=Vqk3tRAg/RM+xI7uV6W4PtoPsVyGWHoIEVOJvNQZjbgDT1E6Nj18qozadmiE4jxI3c vmINyqIOJEpZOmxlJWFQJkm43RhBXTeoW6AvBK8w1mX0Y8Q4Vbk6JtwxC+P8ToAGdUzH 0dWcm+2cIelpmVPzWIr6dcABwf5q8+ecLA4xNI/Zkx+LSLn3HdcZK1G37vtes5l8Fjr3 lFFjLZw492zEM/U7t1SHEthEb2BQUG+fgfn9Z808r5ELthDNVi6juY2kxbH6nyLskglE vtPW2vScnTJLzRvMAeEKeoOF78twjPe+brYfwyapPf01iCju63n/yEJB3tyD+2nNRN2E uXWw== 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 j2-v6si3571010pgn.120.2018.05.23.12.10.37; Wed, 23 May 2018 12:10:52 -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 S934155AbeEWTK2 (ORCPT + 99 others); Wed, 23 May 2018 15:10:28 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:44876 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933928AbeEWTK1 (ORCPT ); Wed, 23 May 2018 15:10:27 -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 BE03240122A7; Wed, 23 May 2018 19:10:26 +0000 (UTC) Received: from doriath (ovpn-116-74.phx2.redhat.com [10.3.116.74]) by smtp.corp.redhat.com (Postfix) with ESMTP id 14AAC210C6C6; Wed, 23 May 2018 19:10:23 +0000 (UTC) Date: Wed, 23 May 2018 15:10:22 -0400 From: Luiz Capitulino To: Baoquan He Cc: Ingo Molnar , 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: <20180523151022.102e3565@doriath> In-Reply-To: <20180518112836.GS24627@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> Organization: Red Hat MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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.5]); Wed, 23 May 2018 19:10:26 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Wed, 23 May 2018 19:10:26 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lcapitulino@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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.