alt Hacker NewsWell, you'll have a SHT_NOTE section and then PT_NOTE pointing to its contents, right? So that way the notes are accessible both via section headers and program headers.
Mach-O does similarly have a distinction between sections as a link-time view, and segments as an execution-time view – a Mach-O contains one or more segments (LC_SEGMENT for 32-bit, LC_SEGMENT_64 for 64-bit), each of which contains a segment header followed by zero or more section headers, so the sections are subdivisions of the segment. Mach-O has names for both segments and sections; ELF only has names for sections.
Let me put it this way – if you wanted to add embedded digital signatures to ELF, so the kernel could verify them at runtime, similar to Mach-O LC_CODE_SIGNATURE – what is the extension point you'd use? The Linux kernel supports digital signatures for ELF executables in conjunction with IMA, but instead of storing the signature in the executable like Mach-O does, it stores it in a filesystem xattr.
> Well, you'll have a SHT_NOTE section and then PT_NOTE pointing to its contents, right?
No, the PT_NOTE points directly at parts of the file. The SHT_NOTE is still there because tools don't bother removing it, but it's essentially wrong to use any section information on a finished binary. The loader and dynamic linker don't.
> […] so the sections are subdivisions of the segment. […]
Ok, I'll say this is probably cleaner than the ELF n:m relationship between PT_LOAD blocks and sections. I guess the ELF way is a tiny bit more efficient (since there's fewer instructions for the loader to follow) but that really doesn't matter in face of the cost of doing relocations.
> Let me put it this way – if you wanted to add embedded digital signatures to ELF, […]
Hm. I'm not a libc/kernel developer, so take this with multiple grains of salt, but my train of thought would be this:
There's already GNU_RELRO which makes a statement about "spans" in the file. I'm not sure if it even makes sense to sign a binary partially, but let's say it does. In that case, I'd start with a new PT_SIGNED, of which there could be multiple, defining chunks of the file to be signed. Unfortunately, the signature itself can't be put into that same header, since it has no payload. (Actually... I guess e_phentsize could be bumped up. Hmm. Not sure how much breakage that would cause. But also, then you'd need to skip the signatures in the middle of program headers…) Left with having to put the signature(s) somewhere (one? multiple, if multiple chunks are getting signed? not sure.) - hmm, I'm torn between notes and a second new program header. I'm slightly leaning towards notes, but don't really know.
[Ed.:] oh, wait. The hypothetical PT_SIGNED program header would probably only use the PhysAddr / FileSize fields. The VirtAddr could point at the actual signature. (Or other way around?) A little hacky, but could maybe be executed well enough to not turn extremely ugly…