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:	Fri, 10 Nov 2006 09:49:22 -0500
From:	Vivek Goyal <vgoyal@...ibm.com>
To:	Magnus Damm <magnus.damm@...il.com>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Magnus Damm <magnus@...inux.co.jp>,
	linux-kernel@...r.kernel.org, Vivek Goyal <vgoyal@...ibm.com>,
	Andi Kleen <ak@....de>, fastboot@...ts.osdl.org,
	Horms <horms@...ge.net.au>, Dave Anderson <anderson@...hat.com>
Subject: Re: [PATCH 02/02] Elf: Align elf notes properly

On Fri, Nov 10, 2006 at 03:53:57PM +0900, Magnus Damm wrote:
[..]
> >Sure.
> >
> >To verify your claim that 8 byte alignment is correct I checked the
> >core dump code in fs/binfmt_elf.c in the linux kernel.  That always
> >uses 4 byte alignment.  Therefore it appears clear that only doing
> >4 byte alignment is not a local misreading of the spec, and is used in
> >other implementations.  If you can find an implementation that uses
> >8 byte alignment I am willing to consider it.
> 
> Yes, fs/binfmt_elf.c is one of the files that my patch modifies. There
> are several elf note implementations in the kernel, all seem to use
> 4-byte aligment.
> 
> Implementations that use 8-byte alignment:
> 
> binutils-2.16.1/bfd/elf.c: elf_core_write_note() is using
> log_file_align which is set to 3 on some 64-bit platforms.  8-byte
> alignment in some cases.
> 
> binutils-2.16.1/binutils/readelf.c: process_corefile_note_segment() is
> always using 4-byte alignment though.
> 
> >The current situation is that the linux kernel generated application
> >core dumps use 4 byte alignment so I expect that is what existing
> >applications such as gdb expect.
> 
> Most applications probably expect 4-byte aligned data. OTOH, I just
> came across HP's ELF-64 Object File Format document. It says that
> 8-byte alignment should be used:
> 
> http://devresource.hp.com/drc/STK/docs/refs/elf-64-hp.pdf
> 
> So now we have two documents that say 8-byte alignment should be used.
> 
> >Therefore we use 4 byte alignment unless it can be shown that the
> >linux core dumps are a fluke and should be fixed.
> 
> Ok. Vivek, Dave, anyone? Comments?
> 

IMHO, I think we should go by the specs (8byte boundary alignment on 64bit
platforms) until and unless it can be proven that specs are wrong. This
probably will mean that we will break things for sometime (until and unless
it is fixed in tool chain and probably will also break the capability to use
an older kernel for capturing dump). But that's unavoidable if we want to be
compliant to specs.

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