Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1539752
| From | Baoquan He <bhe@redhat.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 0/2] Determine kernel text mapping size at runtime for x86_64 |
| Date | 2016-12-10 02:40 +0100 |
| Message-ID | <sMENP-2b6-1@gated-at.bofh.it> (permalink) |
| References | <sM1Mt-3ja-11@gated-at.bofh.it> <sMbLP-14G-29@gated-at.bofh.it> <sMceR-1um-15@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 12/08/16 at 02:00pm, Dave Anderson wrote: > > > ----- Original Message ----- > > On Wed, Dec 7, 2016 at 11:56 PM, Baoquan He <bhe@redhat.com> wrote: > > > Dave Anderson ever told in Crash utility he makes judgement whether it's > > > a kaslr kernel by size of KERNEL_IMAGE_SIZE. As long as it's 1G, it's > > > recognized as kaslr. Then the current upstream kernel has a wrong behaviour, > > > it sets KERNEL_IMAGE_SIZE as 1G as long as CONFIG_RANDOMIZE_BASE is enabled, > > > though people specify "nokaslr" into cmdline to disable kaslr explicitly. > > > > I'm not sure that's the correct solution to the Crash utility -- the > > kaslr-ness of a kernel should be already exposed in the dump with the > > kaslr_enabled variable yes? > > The crash utility doesn't use KERNEL_IMAGE_SIZE to determine whether > KASLR is in play, but rather to determine the base of the modules virtual > address space (i.e, the same way the kernel does). And then it uses that > value in a couple other places. Then I got it wrong. The current code makes it the same: #define MODULES_VADDR (__START_KERNEL_map + KERNEL_IMAGE_SIZE) With change, Crash doesn't need to change. Thanks Baoquan > > > > > > > So in this patchset, made changes to determine the size of kernel text > > > mapping > > > area at runtime. If "nokaslr" specified, kernel mapping size is 512M though > > > CONFIG_RANDOMIZE_BASE is enabled. > > > > This seems to make the non-KASLR case more consistent, so I'm fine > > with the idea. Once the build-bots are happy with everything, consider > > the series: > > > > Acked-by: Kees Cook <keescook@chromium.org> > > > > Thanks! > > > > -Kees > > > > > > > > Baoquan He (2): > > > x86/64: Make kernel text mapping always take one whole page table in > > > early boot code > > > x86/KASLR/64: Determine kernel text mapping size at runtime > > > > > > arch/x86/boot/compressed/kaslr.c | 15 ++++++++++----- > > > arch/x86/include/asm/kaslr.h | 1 + > > > arch/x86/include/asm/page_64_types.h | 20 ++++++++++++-------- > > > arch/x86/include/asm/pgtable_64_types.h | 2 +- > > > arch/x86/kernel/head64.c | 11 ++++++----- > > > arch/x86/kernel/head_64.S | 16 +++++++++------- > > > arch/x86/mm/dump_pagetables.c | 3 ++- > > > arch/x86/mm/init_64.c | 2 +- > > > arch/x86/mm/physaddr.c | 6 +++--- > > > 9 files changed, 45 insertions(+), 31 deletions(-) > > > > > > -- > > > 2.5.5 > > > > > > > > > > > -- > > Kees Cook > > Nexus Security > >
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[PATCH 0/2] Determine kernel text mapping size at runtime for x86_64 Baoquan He <bhe@redhat.com> - 2016-12-08 09:00 +0100
Re: [PATCH 0/2] Determine kernel text mapping size at runtime for x86_64 Kees Cook <keescook@chromium.org> - 2016-12-08 19:40 +0100
Re: [PATCH 0/2] Determine kernel text mapping size at runtime for x86_64 Dave Anderson <anderson@redhat.com> - 2016-12-08 20:10 +0100
Re: [PATCH 0/2] Determine kernel text mapping size at runtime for x86_64 Baoquan He <bhe@redhat.com> - 2016-12-10 02:40 +0100
csiph-web