Messages in this thread | | | From | Pingfan Liu <> | Date | Wed, 6 Mar 2019 15:58:33 +0800 | Subject | Re: [PATCH] x86/boot/KASLR: skip the specified crashkernel reserved region |
| |
On Wed, Feb 27, 2019 at 3:40 PM Borislav Petkov <bp@alien8.de> wrote: > > + Kees. > > @Kees, you might want to go upthread a bit for context. > Seems not reply from Kees. > 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. > As Dave said, some un-relocatable code should be loaded to a specified space. Also the param is used by archs beside x86 > > 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. > Kernel has already done this excluding 1gb pages. Do we need to worry about 200-400 MB for crashkernel? And I think if a user specify the region, then he/she should be aware of the limit of KASLR (can printk to warn him/her).
> But I might be way off here because of something else I'm missing ... > So how do you think about this now? Just leaving a unstable kernel parameter, or printk some info when crashkernel=x@y fails.
Thanks, Pingfan > -- > Regards/Gruss, > Boris. > > Good mailing practices for 400: avoid top-posting and trim the reply.
| |