linux-kernel - Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.

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]

Date:	Mon, 30 Apr 2007 23:54:22 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Andi Kleen <ak@...e.de>
Cc:	vgoyal@...ibm.com, Kexec Mailing List <kexec@...ts.infradead.org>,
	linux-kernel@...r.kernel.org, Jurriaan <thunder7@...all.nl>,
	Helge Hafting <helgehaf@...el.hist.no>,
	Horms <horms@...ge.net.au>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.

Andi Kleen <ak@...e.de> writes:

> On Mon, Apr 30, 2007 at 11:26:50PM -0600, Eric W. Biederman wrote:
>> Vivek Goyal <vgoyal@...ibm.com> writes:
>> 
>> 
>> >> At least without a core file it is working on with gdb 6.4.
>> >>
>> >
>> > This seems to be a problem with gdb 6.5. I transferred the dump to a
>> > different machine having GNU gdb 6.4, and it works fine there.
>> 
>> Ok.  The difference between those two symbols didn't seem to make
>> any sense, so a gdb bug makes sense.
>> 
>> Cool.  Then the patch is good. :)
>
> It would still make any gdb 6.5 users unhappy. If no workaround can be found
> I guess we'll need a CONFIG of some sort?

It is probably worth reproducing this bug with a PIE executable.
But it looks very much like gdb got it wrong, or else there is some
slight mismatch between our core dump and gdb.

Given that gdb 6.5 handles the vmlinux fine when it isn't in conjunction
with a core dump I would not say the problem is in vmlinux.

Rather there seems to be something messed up when gdb 6.5 tries to match
up the kernel core dump with the kernel.  The offset for the symbol
Vivek gave was 0x7fff70e9. ???  Although that is almost 2M...

Vivek could we see the program headers of your core file?

>From what I can tell what is left to figure out is do we have
a bug in gdb 6.5 or do we have a bug in our core file generation.

Right now I'm inclined to believe that the fedora core 6? gdb 6.5 got it
wrong.  I'm probably just burnt out with binutils problems whenever
I try and do something interesting.  But I'm just not inclined that
the bleeding edge tools are working properly while there kernel
core dump mechanism would mess up with a two byte field change.

It does make sense to root cause this if we can.  If it's a gdb
problem it should also apply to PIE executables, and should irritate
a few users.

Regardless last I heard it was crash that was the primary analysis
tool and not gdb anyway.  With gdb serving as the double check to make
certain that the kernel core dump was in a reasonably standard format.

Eric
-
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/