linux-kernel - Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo

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: <20161011074111.GD11185@x1>
Date:   Tue, 11 Oct 2016 15:41:11 +0800
From:   Baoquan He <bhe@...hat.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
        tglx@...utronix.de, akpm@...ux-foundation.org, mingo@...hat.com,
        hpa@...or.com, dyoung@...hat.com, tonli@...hat.com,
        keescook@...omium.org, takahiro.akashi@...aro.org,
        thgarnie@...gle.com, ats-kumagai@...jp.nec.com
Subject: Re: [PATCH] kexec: Export memory sections virtual addresses to
 vmcoreinfo

Hi Eric,

Thanks a lot for your reviewing! Sorry for late reply.

On 10/06/16 at 03:07pm, Eric W. Biederman wrote:
> Baoquan He <bhe@...hat.com> writes:
> 
> > KASLR memory randomization can randomize the base of the physical memory
> > mapping (PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap
> > (VMEMMAP_START). These need be exported to VMCOREINFO so that user space
> > utility, mainly makedumpfile can use them to identify the base of each
> > memory section. Here using VMCOREINFO_NUMBER we can reuse the existing
> > struct number_table in makedumpfile to import data easily.
> >
> > Since they are related to x86_64 only, put them into
> > arch_crash_save_vmcoreinfo. And move the exportion of KERNEL_IMAGE_SIZE
> > together since it's also for x86_64 only.
> 
> *Scratches my head*  I would have thought this information would have
> better fit in the ELF header.  Where it actually has a field for virtual
> address.  It also has a field for physical address, and a third field
> for offset in the file (which is where the kdump finds these things in
> memory aftewards).
> 
> Why do we need need more magic vmcoreinfo to handle this?

Previously in x86_64, values of PAGE_OFFSET, VMALLOC and VMEMMAP are
fixed, makedumpfile also hard codes them.

In kexec-tools, we try to get page_offset_base from /proc/kallsyms or
search it from /proc/kcore elf header with the help of virtual address
of symbol _stext. Then we save it into p_vaddr of kernel text program
segment. In kdump kernel, we may assume kernel text has the biggest
starting virtual address and search it from vmcore elf header. But I
can't think of a way to get the starting virtual address of vmalloc and
vmemmap which are necessary for makedumpfile analysis.

So it's necessary to add them into VMCOREINFO to let makedumpfile know.

Thanks
Baoquan