executable is killed after codesign

That's part of the purpose of the hardened runtime. By default, it won't allow an app to load an unsigned library or a library whose code signature has been invalidated because it's been modified since it's been signed.

You will have to sign the modified library B. Or, you could debug with a build of A that does not have the hardened runtime enabled. Alternatively, you could debug with SIP disabled.

You could add the Disable Library Validation Entitlement to A to relax the hardened runtime's restriction, but be sure you remove that for the build you ship unless you're sure you want to allow that.

I have tried these

1) codesign modified B => doesn't work

2) codesign both A and B => doesn't work

3) codesign both A and B by removing "-o runtime" - disabling hardend runtime => doesn't work

with 2 and 3 now, binary wont even start. lldb says "bad executable (or shared library), dtruss says (no such file or directory)

if I remove codesign from both A and B, then it works.

How are you “replacing” this binary? macOS has a long-standing wrinkle that causes problems if you overwrite a Mach-O file on disk (the kernel caches code signing info from the original file and doesn’t flush that cache when you rewrite it). If you want to replace a Mach-O file on disk, you should always replace the file with a new one. Thus, using

mv

cp

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

that perhaps is, because what I went on trying is, disabled SIP => things worked, enabled SIP => things continued working. now, I have issues with some binary not all, and a simple reboot fixed it.

in log stream all I was getting is

020-03-18 15:57:49.958688-0500 0xc530 Default 0x0 8777 0 taskgated: (Security) [com.apple.securityd:security_exception] UNIX error exception: 3

2020-03-18 15:57:49.960037-0500 0xc530 Default 0x0 8777 0 taskgated: no signature for pid=5799 (cannot make code: UNIX[No such process])

which perhaps indicates what your are suggesting about kernel caching code sign info.

I would try mv when I try next and update here.

I too seeing the same issue.

When I overwrite the old binaries with the newer one (with additional entitlements), I get "Killed: 9" error: Bad executable (or shared library)" when I execute any binary that has a dependecy on .dylib. The binaries that just depends on "/usr/lib/libSystem.B.dylib" works fine. When I reboot the machine, then all the binaries work fine and no error is seen.

Do I need to flush dylib cache or any other cache to avoid the reboot? Or How can I fix it please?

See my response on the other thread you posted to.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

It is new in [Apple silicon]?

No, but you’re more likely to encounter it on Apple silicon because code signing is absolutely required on that architecture. Previous architectures would let you build and run (at least locally) unsigned code.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Use mv not cp is the key.

Cool.

I finally got around to documenting this gotcha officially: Updating Mac Software.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"