Re: [PATCH v2 2/2] x86/KASLR/64: Determine kernel text mapping size at runtime

[Baoquan He]

On 12/10/16 at 05:28pm, Borislav Petkov wrote:
> 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.

Surely they can grep their config and then check whether "nokaslr" has
been added to kernel cmdline. But could you tell where I can find
document or descriptions defining if I want to know a feature is
enabled or not, I have to grep their config and then check kernel
cmdline? Linux kernel is a open source and free software, as long as
people get and use it, they can do whatever they want to do. If they
want to know somethings, they can look anywhere. They can look at config
or not, they can look at this or that, they can look alone or together
with people, habited or naked. In my humble opinion, people can check
whatever they like, while kernel developers need to make sure wherever
and whenever they check, things should be correct, stable, reasonable,
consistent. If there's corner case or exceptions hard to cover, at least
leave a note to explain it.

So now, what you are telling is if someone saw something not reasonable,
blame on him, because he is looking at something that supposed not to be
seen. I am not persuaded.

> 
> > 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.

Well, assume a kernel driver developer wants to check if his code still
works well under Fedora 25 which defaults to enable
CONFIG_RANDOMIZE_BASE, for example. Firstly he surely want to know if
his code still works with kaslr feature disabled which is the same as in
the old version of distro kaslr feature is not compiled in or not
supported. Now two choices are put in front of him:
1) Set CONFIG_RANDOMIZE_BASE to 'n' and rebuild kernel code, it will
take him 30 minutes or about 1 hour.
2) Add "nokaslr" to kernel cmdline and rebot, it will take him 30
seconds or about 1 minute.

If were you, which one do you choose?

Then he added his testing code to print the virtual address his modules are
loaded at. Now he saw his driver modules were not loaded at the range he
always saw in the previous kernel, but in a position with 512M added. In
this case, what do you suggest him to do? Still stuff should just work, leave
it alone? If he really does as you suggested, do you think if he is a
responsible worker? If you are his boss, are you happy to see what he is
doing? 

So it's so obvious that "nokaslr" should disable kaslr feature completely,
should be consistent with the old kernel which doesn't support kaslr at
all. However now it has inconsistent behaviour, though no kernel crash is
reported or userspace utility collapse collected, if saw a plate filled
with food sliding to the edge of table, half hovering, we have to wait
until it fall to the floor, then busy on fixing plate, scrubbing off
the dirty, finding people to blame?

For arguing and defending myself, I couldn't be very objective. So if
you really think remaining 1G is OK though nokaslr is specified, I am
fine with it. We can wait until a report is coming.
> 
> And even then, looking at KERNEL_IMAGE_SIZE is still the wrong way to do
> it.

Again, any information, as long as it's exposed out of kernel, can be
checked. KERNEL_IMAGE_SIZE should be used to limit the run space of
kernel, if someone is doubted using it in wrong way, can we check
ourselves if we define and expose it right.

Thanks
Baoquan