Unexpected Padding Between Note Sections in ELF File

[ismailhkose]

I am working on a crate to embed metadata into binaries and shared libraries using custom note sections. However, I encountered an issue where the Rust compiler adds unexpected padding between .note.gnu.build-id and .note.hello sections in the generated ELF file. This padding causes problems with the section headers and results in warnings when using tools like readelf.

Steps to Reproduce:

1. Create a new Rust project.
2. Add the following code to lib.rs:

#[link_section = ".note.hello"]
#[used]
pub static HELLO_NOTE_SECTION: &[u8] = &[];

fn main() {
    println!("Hello, world!");
}

3. Create a custom linker script linker.ld with the following content:

SECTIONS {
  .note.hello : ALIGN(4) SUBALIGN(4) {
    KEEP(*(.note.hello))
    BYTE(0x04);
    BYTE(0x00);
    BYTE(0x00);
    BYTE(0x00);
    BYTE(0x04);
    BYTE(0x00);
    BYTE(0x00);
    BYTE(0x00);
    BYTE(0x7E);
    BYTE(0x1A);
    BYTE(0xFE);
    BYTE(0xCA);
    BYTE(0x46);
    BYTE(0x44);
    BYTE(0x4F);
    BYTE(0x0A);
    BYTE(0x0B);
    BYTE(0x0E);
    BYTE(0x0E);
    BYTE(0x00);
  }
}
INSERT AFTER .note.gnu.build-id;

4. Build the project with the custom linker script:
   cargo rustc -- -C link-arg=-Tlinker.ld

5. Inspect the generated ELF file using readelf:
   readelf --note target/debug/hello
   or
   readelf --section-headers --note target/debug/hello

.note.hello section

Note section is parsing result from readelf

Unexpected padding that starts at address 0x3c8
The actual note section starts at 0x3d8, after 16 bytes later as opposed to what section header points.

Expected Behavior:

The .note.hello section should be placed immediately after the .note.gnu.build-id section without any unexpected padding.
The actual note section should have started at 0x3d8.

Actual Behavior:

There is a 16-byte padding between the .note.gnu.build-id and .note.hello sections, which results in the following warnings:

Displaying notes found in: .note.hello
  Owner                Data size        Description
                       0x00000000       Unknown note type: (0x00000000)
readelf: Warning: note with invalid namesz and/or descsz found at offset 0x10
readelf: Warning:  type: 0xcafe1a7e, namesize: 0x00000004, descsize: 0x00000188, alignment: 8

The actual note section starts at 0x3d8, after 16 bytes later as opposed to what section header points.

Meta

rustc --version --verbose:

rustc 1.85.0 (4d91de4e4 2025-02-17)
binary: rustc
commit-hash: 4d91de4e48198da2e33413efdcd9cd2cc0c46688
commit-date: 2025-02-17
host: x86_64-unknown-linux-gnu
release: 1.85.0
LLVM version: 19.1.7

I saw this issue in older versions of rust compilers too.
uname -a

Linux 7c26d603c4a9 5.15.0-1079-azure #88~20.04.1-Ubuntu SMP Fri Jan 17 18:28:29 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/os-release

PRETTY_NAME="Ubuntu 22.04.5 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.5 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

[ismailhkose]

I think I found the reason for the issue, but I don't understand why.

It's related to the way the pointing array to the note section is defined.

#[link_section = ".note.hello"]
#[no_mangle]
#[used]
pub static HELLO_NOTE_SECTION: &[u8] = &[];

When it's defined as follows, it does not add the extra 16 bytes of padding.

#[link_section = ".note.hello"]
#[no_mangle]
#[used]
pub static HELLO_NOTE_SECTION: [u8; 0] = [];

Can someone enlighten me about the reason of adding the extra 16 bytes with the previous definition?
Is this a bug or a feature?

[bjorn3]

What happens in the first case is that you don't put the content of the &[] in the .note.hello section. Rather you are putting the pointer to this content (16 bytes as it is a wide pointer with 8 bytes address and 8 bytes length on 64bit systems) in the .note.hello section and rustc decided to put the actual content after the pointer in the same section by chance. In the second case you are directly putting the content of the [] in the .note.hello section.

[ismailhkose]

I'm closing this issue as it's not a bug but expected behavior based on Rust's memory model and how the #[link_section] attribute works.

Root Cause
The 16-byte padding observed between .note.gnu.build-id and where your note data actually begins is due to how Rust represents references (&[u8]):

[link_section = ".note.hello"]
#[used]
pub static HELLO_NOTE_SECTION: &[u8] = &[];  // Creates a 16-byte fat pointer

When you use #[link_section], Rust places the variable itself in that section, not just the data it references. Since &[u8] is a fat pointer (containing an 8-byte address and 8-byte length on 64-bit platforms), these 16 bytes appear at the start of your section, followed by the actual data.

Solution
The alternative approach correctly solves the issue:

#[link_section = ".note.hello"]
#[no_mangle]
#[used]
pub static HELLO_NOTE_SECTION: [u8; 0] = [];  // Directly embeds the array

This places the array directly in the section without any pointer metadata, aligning with what ELF tools expect when parsing note sections.

When embedding data in custom ELF sections, especially note sections with specific format requirements, prefer using direct arrays ([u8; N]) over references (&[u8]) to avoid unexpected metadata affecting the section layout.