kernel-hardening - Re: [PATCH v1] kdump, vmcoreinfo: report memory sections virtual addresses

server OS

Message-ID: <CAGXu5j+2o5iPbesqJA5t2QDM2hK=g7mZAAdoS4EqHzVE76DzcA@mail.gmail.com>
Date: Fri, 19 Aug 2016 11:01:36 -0700
From: Kees Cook <keescook@...omium.org>
To: Baoquan He <bhe@...hat.com>
Cc: Thomas Garnier <thgarnie@...gle.com>, Thomas Gleixner <tglx@...utronix.de>, 
	Ingo Molnar <mingo@...hat.com>, "H . Peter Anvin" <hpa@...or.com>, Eric Biederman <ebiederm@...ssion.com>, 
	Andrew Morton <akpm@...ux-foundation.org>, Xunlei Pang <xlpang@...hat.com>, 
	HATAYAMA Daisuke <d.hatayama@...fujitsu.com>, 
	"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, 
	Eugene Surovegin <surovegin@...gle.com>, "x86@...nel.org" <x86@...nel.org>, 
	Kexec Mailing List <kexec@...ts.infradead.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1] kdump, vmcoreinfo: report memory sections virtual addresses

On Thu, Aug 18, 2016 at 7:41 PM, Baoquan He <bhe@...hat.com> wrote:
>
> This makes sense. Makedumpfile need this to parse memory sections.

Yup, good addition.

Acked-by: Kees Cook <keescook@...omium.org>

-Kees

>
> Ack.
>
> Acked-by: Baoquan He <bhe@...hat.com>
>
> On 08/18/16 at 07:47am, Thomas Garnier wrote:
>> KASLR memory randomization can randomize the base of the physical memory
>> mapping (PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap
>> (VMEMMAP_START). Adding these variables on VMCOREINFO so tools can
>> easily identify the base of each memory section.
>>
>> Signed-off-by: Thomas Garnier <thgarnie@...gle.com>
>> ---
>> Based on next-20160817
>> ---
>>  arch/x86/kernel/machine_kexec_64.c | 3 +++
>>  include/linux/kexec.h              | 6 ++++++
>>  2 files changed, 9 insertions(+)
>>
>> diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
>> index fc3389f..b1f15a2 100644
>> --- a/arch/x86/kernel/machine_kexec_64.c
>> +++ b/arch/x86/kernel/machine_kexec_64.c
>> @@ -338,6 +338,9 @@ void arch_crash_save_vmcoreinfo(void)
>>       vmcoreinfo_append_str("KERNELOFFSET=%lx\n",
>>                             kaslr_offset());
>>       VMCOREINFO_PHYS_BASE(phys_base);
>> +     VMCOREINFO_PAGE_OFFSET(PAGE_OFFSET);
>> +     VMCOREINFO_VMALLOC_START(VMALLOC_START);
>> +     VMCOREINFO_VMEMMAP_START(VMEMMAP_START);
>>  }
>>
>>  /* arch-dependent functionality related to kexec file-based syscall */
>> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
>> index d3ae429..cd3874c 100644
>> --- a/include/linux/kexec.h
>> +++ b/include/linux/kexec.h
>> @@ -261,6 +261,12 @@ phys_addr_t paddr_vmcoreinfo_note(void);
>>       vmcoreinfo_append_str("CONFIG_%s=y\n", #name)
>>  #define VMCOREINFO_PHYS_BASE(value) \
>>       vmcoreinfo_append_str("PHYS_BASE=%lx\n", (unsigned long)value)
>
> Could it be better to define only one MACRO like VMCOREINFO_
>> +#define VMCOREINFO_PAGE_OFFSET(value) \
>> +     vmcoreinfo_append_str("PAGE_OFFSET=%lx\n", (unsigned long)value)
>> +#define VMCOREINFO_VMALLOC_START(value) \
>> +     vmcoreinfo_append_str("VMALLOC_START=%lx\n", (unsigned long)value)
>> +#define VMCOREINFO_VMEMMAP_START(value) \
>> +     vmcoreinfo_append_str("VMEMMAP_START=%lx\n", (unsigned long)value)
>>
>>  extern struct kimage *kexec_image;
>>  extern struct kimage *kexec_crash_image;
>> --
>> 2.8.0.rc3.226.g39d4020
>>
>>
>> _______________________________________________
>> kexec mailing list
>> kexec@...ts.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec

-- 
Kees Cook
Nexus Security