[lkml]   [2016]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v2 2/2] x86/KASLR/64: Determine kernel text mapping size at runtime
On Sat, Dec 10, 2016 at 09:41:56PM +0800, Baoquan He wrote:
> 1) Fedora 25 defaults to enable CONFIG_RANDOMIZE_BASE. And this worries
> maintainers of several Fedora component. People ever asked me how to
> judge whether it's a kaslr kernel. I told them I usually read elf header
> of kcore - "readelf -l /proc/kcore" to check it. If the 'VirtAddr' of
> segments like kernel text, modules, direct mapping is changed, it should
> be kaslr kernel. Then they said why I have specified 'nokaslr', the
> virtual address of modules is not '0xffffffffa0000000', but
> '0xffffffffc0000000'. OK, I realized this is not right, it need be
> fixed.

So people want to know whether the kernel they're running has KASLR
enabled or not.

Clearly they can grep their config. And then check whether "nokaslr" has
been added to the kernel command line or not. Done.

> So in v2 I didn't mention problem about Crash. But case 1) need be
> cared, whether kaslr code is compiled or not, it should not confuse
> people, should not make difference between kaslr code not compiled in
> and kaslr code compiled in with 'nokaslr' specified.

That's exactly the point - people should *not* care whether it is a
kernel with KASLR enabled or not - stuff should just work. So what
you're trying to "fix" here is an exercise of pointlessness, IMO. Unless
you give me a real, valid reason why people need a *defined* interface
to ask whether the kernel has KASLR enabled or not.

And even then, looking at KERNEL_IMAGE_SIZE is still the wrong way to do


SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

 \ /
  Last update: 2016-12-10 17:28    [W:0.045 / U:1.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site