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: <1793684967.12087893.1478093388826.JavaMail.zimbra@redhat.com>
Date:   Wed, 2 Nov 2016 09:29:48 -0400 (EDT)
From:   Dave Anderson <anderson@...hat.com>
To:     Baoquan He <bhe@...hat.com>
Cc:     Dave Young <dyoung@...hat.com>, kexec@...ts.infradead.org,
        linux-kernel@...r.kernel.org, keescook@...omium.org,
        ats-kumagai@...jp.nec.com, thgarnie@...gle.com,
        takahiro akashi <takahiro.akashi@...aro.org>, mingo@...hat.com,
        ebiederm@...ssion.com, hpa@...or.com, tglx@...utronix.de,
        akpm@...ux-foundation.org, tonli@...hat.com, panand@...hat.com
Subject: Re: [PATCH] kexec: Export memory sections virtual addresses to
 vmcoreinfo



----- Original Message -----
> Hi Dave,
> 
> On 11/01/16 at 10:13am, Dave Anderson wrote:
> > 
> > 
> > > > But we have this in mainline which also introduced the VMCOREINFO
> > > > numbers, can you send a patch to revert them?
> > > 
> > > OK, will do.
> > > 
> > > However for find_vmemmap_x86_64() in makedumpfile, vmemmap_start is
> > > still needed. I checked code, seems no better way to avoid. I am not
> > > sure how many people are really using "-e" option to exclude unused
> > > vmemmap pages.
> > > 
> > > Maybe just leave it as is, and fix it when people complain?
> > 
> > Speaking of complaints, is there any chance you can make the
> > x86_64 "phys_base" value available?  The VMCOREINFO_SYMBOL(phys_base)
> > is useless since its contents are needed in order to access the
> > symbol address.
> 
> Yeah, the current exporting of virt addr of phys_base is really useless
> for x86_64. While I saw you have got phys_base from kdump-ed vmcore elf
> program header since kexec-tools has created that pt_load for kernel text
> region.
> 
> machdep->machspec->phys_base = phdr->p_paddr - (phdr->p_vaddr &
> ~(__START_KERNEL_map));
> 
> Do you still want the value of phys_base? If yes, I can change it to
> export the real value of phys_base, not &phys_base.
> 
> In fact, exporting &phys_base was done in 2008, makedumpfile has taken
> the similar way you use in crash to get value of phys_base. Means it has
> been ignored very earlier. You could be the first person to complain
> about it.

No, this is not the first time it's been brought up.  Anyway, yes,
it would be preferable if it were readily available in vmcoreinfo
rather than depending upon the PT_LOAD semantics. 

Thanks,
  Dave