ELF Notes should use 4-byte alignment about goblin HOT 11 CLOSED

I wouldn't rely solely on that man page. As noted in #90, other programs such as readelf sometimes use an alignment of 8, so I don't think changing to always use 4 is a correct solution.

Can you provide a file to test with, or steps to create such a file?

from goblin.

Maybe I was a bit overeager and creates a PR with a test right away: #365

Unfortunately, I can’t share the file I am looking at as it contains sensitive customer data.

from goblin.

Can you determine which compiler was used to create the file?

from goblin.

The file is not an executable, but a core file from a certain proprietary ELF-based platform that puts a bunch of custom info into various NOTEs. I’m trying to intentionally keep this as vague as possible :-D

from goblin.

A possibility is that the proprietary ELF-based platform is incompatible with other platforms.

I'll see if I can find a file that does require 8 byte alignment for notes.

from goblin.

In case this is indeed incompatible with other ELF platforms, I can also parse the NOTEs manually instead of going through iter_note_headers, that is perfectly fine for my use cases :-)

from goblin.

Ah okay, I found out the confusion here.

Both LLVM and binutils align only namesz, and not the whole pointer offset:

https://github.com/llvm/llvm-project/blob/2f2c76ddb73e6176bed558c7d61faa50aabb9e9e/llvm/include/llvm/Object/ELFTypes.h#L643

https://github.com/bminor/binutils-gdb/blob/1ed7ccc6cf46f1ec60538875cf0f68890f5ae6ec/binutils/readelf.c#L16177

Whereas goblin aligns the whole pointer.

in my case namesz == 16, so it is already 8-byte aligned, and no change is being made in readelf. But goblin sees the 12-byte NOTE header + 16 byte namesz and aligns that. (Or rather, the file-based offset of that.) That is where my 4-byte offset is coming from presumably.

from goblin.

I’m still so confused how this whole thing could potentially have ever worked reading theNT_GNU_BUILD_ID, which has a 4-byte namesz.

from goblin.

Okay no, wait a second, that alignment is taking into account the offsetof:

https://github.com/bminor/binutils-gdb/blob/1ed7ccc6cf46f1ec60538875cf0f68890f5ae6ec/include/elf/external.h#L193-L194

So it does align taking into account the whole struct, which is why GNU\0 aligns correctly.

For my use-case, readelf seems to align and read things correctly, but goblin does not. Maybe it is simply using a different alignment value for some reason, even though the program headers state that the NOTEs are supposed to be 8-byte aligned.

from goblin.

The only files I've found on my system that have alignment 8 are the ".note.gnu.property" sections, which happen to be readable using an alignment of both 4 and 8.

For the test you added in #365, have you kept the same length for the name and descriptor?

If I write the data from that test to a file with section alignment 8, then readelf fails to read it:

$ readelf -n note8.o

Displaying notes found in: .note
  Owner                Data size 	Description
readelf: Warning: note with invalid namesz and/or descsz found at offset 0x0
readelf: Warning:  type: 0x1, namesize: 0x00000008, descsize: 0x00000014, alignment: 8

llvm-readobj does succeed because it always uses alignment 4. In my opinion this is an LLVM bug, and it has had similar bugs before (https://reviews.llvm.org/D70962).

The ELF generic ABI states that padding is 4 or 8 depending on ELF class: https://www.sco.com/developers/gabi/latest/ch5.pheader.html#note_section. OS and CPU ABIs can override that, but in any case I would expect the section alignment to match the alignment that is used.

from goblin.

Thanks for helping me deep dive into all this. I was indeed using llvm-readobj / llvm-readelf as a reference, which was working just fine. It looks like the core dump that I am dealing with might just advertise a wrong alignment. But I should be able to work around that on my end. Thanks for all the help!

from goblin.