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>] [day] [month] [year] [list]
Message-ID: <20130530144937.GE2864@redhat.com>
Date:	Thu, 30 May 2013 10:49:37 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Michael Holzheu <holzheu@...ux.vnet.ibm.com>
Cc:	Jan Willeke <willeke@...ibm.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	linux-kernel@...r.kernel.org, kexec@...ts.infradead.org
Subject: Re: [PATCH v4 1/3] kdump: Introduce ELF header in new memory feature

On Fri, May 24, 2013 at 11:18:56AM -0400, Vivek Goyal wrote:
> On Fri, May 24, 2013 at 01:29:41PM +0200, Michael Holzheu wrote:
> > Currently for s390 we create the ELF core header in the 2nd kernel
> > with a small trick. We relocate the addresses in the ELF header in
> > a way that for the /proc/vmcore code it seems to be in the 1st kernel
> > (old) memory and the read_from_oldmem() returns the correct data.
> > This allows the /proc/vmcore code to use the ELF header in the
> > 2nd kernel.
> > 
> > This patch now exchanges the old mechanism with the new and much
> > cleaner function call override feature that now offcially allows to
> > create the ELF core header in the 2nd kernel.
> > 
> > To use the new feature the following has to be done by the architecture
> > backend code:
> > 
> >  * Override arch_get_crash_header() to return the address of the ELF
> >    header in new memory.
> >  * Override arch_free_crash_header() to free the memory of the ELF
> >    header in new memory.
> >  * Override arch_read_from_crash_header() to read from the ELF header
> >    in new memory
> 
> I think above function is not clear in definition. What happens to reading
> of data pointed by ELF headers. For sections of data pointed by PT_NOTE
> we are calling arch_read_from_crash_header() but for accessing data
> pointed by PT_LOAD, we must be calling regular functions.
> 
> Not very sure what to do about this. Just that it looks little ugly
> right now.

Hi Michael,

How about if we introduce another function to read notes, say
arch_read_crash_notes(). So arch_read_from_crash_header() is meant
to get just ELF headers (ELF header and PT_LOAD, PT_NOTE type elf headers)
and arch_read_crash_notes() gets the data as pointed by PT_NOTE elf
header.

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ