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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190205081552.GG21801@zn.tnic>
Date:   Tue, 5 Feb 2019 09:15:52 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Jerry Hoemann <jerry.hoemann@....com>
Cc:     Dave Young <dyoung@...hat.com>, x86@...nel.org,
        Baoquan He <bhe@...hat.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Pingfan Liu <kernelfans@...il.com>,
        Mike Rapoport <rppt@...ux.vnet.ibm.com>,
        Andrew Morton <akpm@...ux-foundation.org>, yinghai@...nel.org,
        vgoyal@...hat.com
Subject: Re: [PATCHv7] x86/kdump: bugfix, make the behavior of crashkernel=X
 consistent with kaslr

On Mon, Feb 04, 2019 at 03:30:16PM -0700, Jerry Hoemann wrote:
> Is your objection only to the second fallback of allocating
> memory above >= 4GB?   Or are you objecting to allocating from
> (896 .. 4GB) as well?

My problem is why should the user need to specify high or low allocation
explicitly when we can handle all that in the kernel automatically.

The presence of crashkernel= on the cmdline sure means that the user
wants to allocate memory for a second kernel.

Now, if the requested allocation fails, we say:

  Error reserving crashkernel

So, instead of saying that, we can *try* *again* and say

  Error reserving requested crashkernel at @..., attempting a high range.

and run memblock_find_in_range() on the other regions which we deemed
are ok to allocate from.

Why aren't we doing that by default instead of placing all those
different options in front of the user and expecting her/him to know
something about all those magic ranges?

I don't think most of the users care about where the kernel gets
allocated - all they want is a working kdump setup.

> Falling back to allocating < 4GB probably satisfes most of the cases
> where the original allocation fails.

Yes. Now make that automatic.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ