linux-kernel - Re: [PATCH] Revert "Revert "kdump, vmcoreinfo: report memory sections virtual addresses""

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87bmwdytco.fsf@xmission.com>
Date:   Fri, 16 Dec 2016 06:50:31 +1300
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Thomas Garnier <thgarnie@...gle.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H . Peter Anvin" <hpa@...or.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Baoquan He <bhe@...hat.com>, Xunlei Pang <xlpang@...hat.com>,
        HATAYAMA Daisuke <d.hatayama@...fujitsu.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org, kexec@...ts.infradead.org,
        kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH] Revert "Revert "kdump, vmcoreinfo: report memory sections virtual addresses""

Thomas Garnier <thgarnie@...gle.com> writes:

> This reverts commit 49fd897573c97b0eaf10f47d850027d78c456cd7.
>
> Reverting back to commit 0549a3c because the values are used by crash
> and other tools already. I expected this commit would not go through given
> the unresolved comments. I want it to be easy to resolve major memory
> section positions when KASLR memory randomization is enabled.

This patch is broken.  The commit referenced is wrong,
as is the justification.

These values are not in fact widely used by userspace (they are brand new).

This is a very fragile approach relying on kernel implementation
details, so if we can do anything else that is more robust it
is much more likely to pass the test of time.

And yes a more robust implementation has been already discussed.

Nacked-by: "Eric W. Biederman" <ebiederm@...ssion.com>

>
> Signed-off-by: Thomas Garnier <thgarnie@...gle.com>
> ---
>  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 2e3c34b..05f3367 100644
> --- a/arch/x86/kernel/machine_kexec_64.c
> +++ b/arch/x86/kernel/machine_kexec_64.c
> @@ -339,6 +339,9 @@ void arch_crash_save_vmcoreinfo(void)
>  			      kaslr_offset());
>  	VMCOREINFO_NUMBER(KERNEL_IMAGE_SIZE);
>  	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 e98e546..ff9c876 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -285,6 +285,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)
> +#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;