From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752411AbcLKK6g (ORCPT ); Sun, 11 Dec 2016 05:58:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60724 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751983AbcLKK6e (ORCPT ); Sun, 11 Dec 2016 05:58:34 -0500 Date: Sun, 11 Dec 2016 18:58:29 +0800 From: Baoquan He To: Borislav Petkov Cc: linux-kernel@vger.kernel.org, tglx@linutronix.de, hpa@zytor.com, mingo@redhat.com, x86@kernel.org, keescook@chromium.org, yinghai@kernel.org, thgarnie@google.com, kuleshovmail@gmail.com, luto@kernel.org, mcgrof@kernel.org, anderson@redhat.com, dyoung@redhat.com, xlpang@redhat.com Subject: Re: [PATCH v2 2/2] x86/KASLR/64: Determine kernel text mapping size at runtime Message-ID: <20161211105829.GG1034@x1> References: <1481294518-29595-1-git-send-email-bhe@redhat.com> <1481294518-29595-3-git-send-email-bhe@redhat.com> <20161210103151.56d7k2iwwwu5acmw@pd.tnic> <20161210122757.GE1034@x1> <20161210123340.begeyyiegktangh2@pd.tnic> <20161210134156.GF1034@x1> <20161210162805.sdpidajk47mgquds@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161210162805.sdpidajk47mgquds@pd.tnic> User-Agent: Mutt/1.7.0 (2016-08-17) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Sun, 11 Dec 2016 10:58:33 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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