> 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…