linux-kernel - Re: [PATCH] x86/boot/KASLR: skip the specified crashkernel reserved region

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] [day] [month] [year] [list]

Date:   Mon, 11 Mar 2019 10:49:08 +0800
From:   Baoquan He <bhe@...hat.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Kees Cook <keescook@...omium.org>,
        Pingfan Liu <kernelfans@...il.com>, x86@...nel.org,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Will Deacon <will.deacon@....com>,
        Nicolas Pitre <nico@...aro.org>,
        Chao Fan <fanc.fnst@...fujitsu.com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86/boot/KASLR: skip the specified crashkernel reserved
 region

On 02/27/19 at 08:39am, Borislav Petkov wrote:
> + Kees.
> 
> @Kees, you might want to go upthread a bit for context.
> 
> On Wed, Feb 27, 2019 at 09:30:34AM +0800, Baoquan He wrote:
> > Agree that 'crashkernel=x' should be encouraged to use as the first
> > choice when reserve crashkernel. If we decide to not obsolete
> > 'crashkernel=x@y', it will leave a unstable kernel parameter.
> 
> Is anyone even talking about obsoleting this?
> 
> And if anyone is, anyone can think a bit why we can't do this.

Oh, just a saying about that. If we can't prove this is a good fix,
we may need to persuit resolving it in other ways. Like obsoleting, or
adding a doc to notice user.

As for 'crashkernel=x@y', I rethink about it later, it's userful for user
in some cases. E.g those kinds of big server with hundreds of CPU and
tons of PCI-e devices (we did get report about kdump issue on this kind
of machine, and 'crashkernel=x@y' is needed), they can make use of
'crashkernel=x@y' to specify a memory region to make crash kernel be very
far away from 4G position, e.g 20G. Then if kernel crashed because of some
driver issues, etc, we can exclude the suspicion of crashkernel region.

> > Another worry is that KASLR won't always fail 'crashkernel=x@y',
> > customer may set and check in testing stage, then later in production
> > environment one time of neglect to not check may cause carashed kernel
> > uncaptured.
> >
> > IMHO, 'crashkernel=x@y' is similar to those specified memmap=ss[#$!]nn
> > which have been avoided in boot stage KASLR.
> 
> So my worry is that by specifying too many exclusion ranges, we might
> limit the kaslr space too much and make it too predictable. Especially
> since distros slap those things automatically and most users take them
> for granted.

Indeed. There have been so many avoided regions that the original KASLR
code has been covered with a bundle of atches. This add difficulity to
code maintaining of kernel text KASLR. However, most of time they won't
be specified at one time in one system. And on small systems, like virt
guest system, memmap=, mem= may not be added. As for crashkernel=x@y, it
may not expect too much memory, basically 256 MB can cover more than 90%
of systems. Have to admit that code complixity will be increased a
little because of 'crashkernel=x@y' handling, yet it won't weaken KASLR
much.

Personal opinion.

Thanks
Baoquan