[PATCH] D96164: [lld-macho] add code signature for native arm64 macOS

Jez Ng via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Feb 21 13:49:46 PST 2021


int3 added inline comments.


================
Comment at: lld/MachO/Writer.cpp:790-792
+  uint8_t *codeEnd =
+      buffer->getBufferEnd() -
+      (codeSignatureSection ? codeSignatureSection->getSize() : 0);
----------------
gkm wrote:
> cynecx wrote:
> > gkm wrote:
> > > int3 wrote:
> > > > gkm wrote:
> > > > > int3 wrote:
> > > > > > is this necessary? I don't think hashing a few extra zero bytes makes a difference
> > > > > Yes. `codeEnd` abuts the code-signature header, which is not hashed. "A few extra bytes" are significant, whether zero or not, and influence the hash. We stop hashing at `codeEnd` in order to honor the contract between signer and runtime.
> > > > this doesn't seem done
> > > Oh, sorry. I was confused. This is for UUID, not code-signature. I am playing it safe here: only compute UUID for the image as it is before code signature is added.
> > > 
> > > How do you prefer I handle this?
> > Isn't codesign doing the exact same thing? So, I guess the current approach is alright.
> The mechanisms are similar:
> * `LC_UUID` has a minimal header and signs with md5
> * `LC_CODE_SIGNATURE` has a more elaborate header and signs with sha256
> The precise use(s) of the UUID is unclear to me, due to lack of documentation. As best I can tell, it is used as a unique identifier for program & library content, i.e., it morphs with every code change. I do not see it used to verify content.
@gkm you forgot to hit submit the first time you replied ;)

yeah the UUID is just used to match .dSYM files with their corresponding executables. It doesn't matter what the value is, or how it's computed, as long as it's deterministic. So I think it's fine to just hash the whole buffer, including the unwritten codesign bits.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D96164/new/

https://reviews.llvm.org/D96164



More information about the llvm-commits mailing list