Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1539857

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

From Borislav Petkov <bp@suse.de>
Newsgroups linux.kernel
Subject Re: [PATCH v2 2/2] x86/KASLR/64: Determine kernel text mapping size at runtime
Date 2016-12-10 17:30 +0100
Message-ID <sMSH7-4wf-1@gated-at.bofh.it> (permalink)
References (1 earlier) <sMuEN-4tz-9@gated-at.bofh.it> <sMNeq-pA-39@gated-at.bofh.it> <sMOWS-2d6-33@gated-at.bofh.it> <sMP6y-2g7-27@gated-at.bofh.it> <sMQci-2V7-21@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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

-- 
Regards/Gruss,
    Boris.

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

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH v2 0/2] Determine kernel text mapping size at runtime for x86_64 Baoquan He <bhe@redhat.com> - 2016-12-09 15:50 +0100
  [PATCH v2 2/2] x86/KASLR/64: Determine kernel text mapping size at runtime Baoquan He <bhe@redhat.com> - 2016-12-09 15:50 +0100
    Re: [PATCH v2 2/2] x86/KASLR/64: Determine kernel text mapping size  at runtime Borislav Petkov <bp@suse.de> - 2016-12-10 11:40 +0100
      Re: [PATCH v2 2/2] x86/KASLR/64: Determine kernel text mapping size  at runtime Baoquan He <bhe@redhat.com> - 2016-12-10 13:30 +0100
        Re: [PATCH v2 2/2] x86/KASLR/64: Determine kernel text mapping size  at runtime Borislav Petkov <bp@suse.de> - 2016-12-10 13:40 +0100
          Re: [PATCH v2 2/2] x86/KASLR/64: Determine kernel text mapping size  at runtime Baoquan He <bhe@redhat.com> - 2016-12-10 14:50 +0100
            Re: [PATCH v2 2/2] x86/KASLR/64: Determine kernel text mapping size  at runtime Borislav Petkov <bp@suse.de> - 2016-12-10 17:30 +0100
              Re: [PATCH v2 2/2] x86/KASLR/64: Determine kernel text mapping size  at runtime Baoquan He <bhe@redhat.com> - 2016-12-11 12:00 +0100
                Re: [PATCH v2 2/2] x86/KASLR/64: Determine kernel text mapping size  at runtime Borislav Petkov <bp@suse.de> - 2016-12-11 13:10 +0100
                Re: [PATCH v2 2/2] x86/KASLR/64: Determine kernel text mapping size  at runtime Baoquan He <bhe@redhat.com> - 2016-12-12 03:40 +0100
  [PATCH v2 1/2] x86/64: Make kernel text mapping always take one whole page table in early boot code Baoquan He <bhe@redhat.com> - 2016-12-09 15:50 +0100

csiph-web