Bug 23072 - abi-note.S breaks gABI on 64-bit systems
Summary: abi-note.S breaks gABI on 64-bit systems
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.27
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2018-04-17 07:35 UTC by Kean Johnston
Modified: 2018-08-07 11:40 UTC (History)
3 users (show)

See Also:
Last reconfirmed:
fweimer: security-


Note You need to log in before you can comment on or make changes to this bug.
Description Kean Johnston 2018-04-17 07:35:56 UTC

The gABI clearly states "In 64-bit objects (files with e_ident[EI_CLASS] equal to ELFCLASS64), each entry is an array of 8-byte words in the format of the target processor. In 32-bit objects (files with e_ident[EI_CLASS] equal to ELFCLASS32), each entry is an array of 4-byte words in the format of the target processor."

However, csu/abi-note.S incorrectly documents and implements the note fields as 4-byte integers. Any ABI-compliant ELF processor will therefore get invalid values when processing such note sections.

There are a number of ways this can be fixed, some of which will take co-operation from the link editor (I will file a bug about this in binutils) and some of which is in glibc. First, on 64-bit systems the .note section should *ALWAYS* be aligned on an 8-byte boundary because it is supposed to contain 8-byte values. So if the link editor correctly sets this alignment it will be a clue that the .note section is possibly correct. Secondly, the code in elf/dl-load.c should be trained to correctly detect whether such an existing .note section used 4-byte words or 8-byte words, again using the segment alignment as a clue (but not relying on it).
Comment 2 Florian Weimer 2018-05-22 12:42:29 UTC
Note that the linked WSL issue is likely not caused by ABI alignment, but by the contents of the ELF note (which we do not know) in relation to data provided by the WSL environment.