> 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…
> hmm, I'm torn between notes and a second new program header. I'm slightly leaning towards notes, but don't really know.
This is my point-Mach-O is more elegant because it applies the “there should be one way to do it” dictum made famous by Python-the answer is load commands. ELF gives you multiple ways to do the same thing and it isn’t always clear which one people should use.
> Left with having to put the signature(s) somewhere (one? multiple, if multiple chunks are getting signed? not sure.)
The way macOS handles it-the binary contains a table of hashes, with one hash per a page. The table of hashes is itself hashed, and then that hash of hashes is signed. When loading the executable, the kernel saves the table of hashes in kernel memory, checking the hash on the table of hashes and its signature as it does so. Then, all the kernel has to do, is whenever it reads into memory a page from disk, it looks up the expected hash of the page in the hash table, and compares it it to the hash of the page data being read in. (This is a somewhat simplified explanation, not 100% accurate, but conveys the gist of how it works.)
Oh I didn't even consider that you'd want to hash individual pages.
…that does make the answer for ELF a program header & then you basically do the same thing. Notes are (as I understand it) for small pieces of information (e.g. a single hash, not a whole bunch of them.)
I see where you're coming from though. Thanks for the very informative discussion!
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…