Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754491AbcKRRHp (ORCPT ); Fri, 18 Nov 2016 12:07:45 -0500 Received: from mail-qk0-f193.google.com ([209.85.220.193]:35840 "EHLO mail-qk0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754388AbcKRRHn (ORCPT ); Fri, 18 Nov 2016 12:07:43 -0500 MIME-Version: 1.0 In-Reply-To: References: <147941499514.131046.6450643991764692220.stgit@djiang5-desk3.ch.intel.com> From: Dan Williams Date: Fri, 18 Nov 2016 09:07:41 -0800 Message-ID: Subject: Re: [PATCH] x86: Add warning when memmap=nn!ss and CONFIG_RANDOMIZE_BASE enabled To: Dave Jiang Cc: Thomas Gleixner , "linux-nvdimm@lists.01.org" , "the arch/x86 maintainers" , Dave Chinner , LKML , "H. Peter Anvin" , Ingo Molnar Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1511 Lines: 42 On Fri, Nov 18, 2016 at 8:47 AM, Dave Jiang wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > > On 11/18/2016 04:33 AM, Thomas Gleixner wrote: >> On Thu, 17 Nov 2016, Dave Jiang wrote: >>> CONFIG_RANDOMIZE_BASE can place the kernel anywhere. This causes >>> a problem for when memmap=nn!ss is used. This information is not >>> known until after the kernel starts executing and the decision >>> for where the randomized base goes happens before the kernel is >>> uncompressed. memmap=nn!ss is not reliable in the presence of >>> CONFIG_RANDOMIZE_BASE. >> >> So this is a description of a problem. Now what's missing is a >> useful explanation why you think that adding a warning will make >> things better. >> >> IMNSHO adding that warning is just a pointless exercise. >> >> Why aren't you addressing the real issue and make the boot code >> parse that option and prevent that region from being used for >> kernel placement? >> >> The same issue exists for other memmap options as well, not just >> for that PMEM thingy. >> >> Thanks, >> >> tglx >> > > I wasn't planning to fix it because the pmem memmap option is really > only used for testing. Is it possible to parse the kernel commandline > parameters before the kernel is uncompressed? Apologies, this was my mistake. I missed that we have early boot command line parsing in addition to the in-kernel cmdline parsing. Dave, I think we could fix this in: arch/x86/boot/compressed/kaslr.c::choose_random_location().