linux-kernel - Re: [PATCH] x86: Add warning when memmap=nn!ss and CONFIG_RANDOMIZE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAA9_cmf9bPnPLZN0m1_OtLxZBJZhE6X16fRzkC7WOQQBZnu4QA@mail.gmail.com>
Date:   Fri, 18 Nov 2016 09:07:41 -0800
From:   Dan Williams <dan.j.williams@...il.com>
To:     Dave Jiang <dave.jiang@...el.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        "linux-nvdimm@...ts.01.org" <linux-nvdimm@...1.01.org>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        Dave Chinner <david@...morbit.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH] x86: Add warning when memmap=nn!ss and
 CONFIG_RANDOMIZE_BASE enabled

On Fri, Nov 18, 2016 at 8:47 AM, Dave Jiang <dave.jiang@...el.com> 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().