Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754194AbcKRRNI (ORCPT ); Fri, 18 Nov 2016 12:13:08 -0500 Received: from mga03.intel.com ([134.134.136.65]:13937 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753963AbcKRRNH (ORCPT ); Fri, 18 Nov 2016 12:13:07 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,510,1473145200"; d="scan'208";a="1087188724" Subject: Re: [PATCH] x86: Add warning when memmap=nn!ss and CONFIG_RANDOMIZE_BASE enabled To: Dan Williams References: <147941499514.131046.6450643991764692220.stgit@djiang5-desk3.ch.intel.com> Cc: Thomas Gleixner , "linux-nvdimm@lists.01.org" , the arch/x86 maintainers , Dave Chinner , LKML , "H. Peter Anvin" , Ingo Molnar From: Dave Jiang Message-ID: Date: Fri, 18 Nov 2016 10:13:05 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2001 Lines: 59 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/18/2016 10:07 AM, Dan Williams wrote: > 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(). > Actually it was my fault. I was digging around that and somehow totally missed the early command line parsing bits. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlgvNqEACgkQZBXE8WajuT71LAD9GGV5sL9bAkunWlZZylNGZ+Ug XRfcnKB1g1+SJ4JFDuYA/RxrHAyBBhteIfSuORl5T+1ACYqwTA0MuHFwiASHXbuQ =+j9S -----END PGP SIGNATURE-----