RFR: 8270199: Most SA tests are skipped on macosx-aarch64 because all executables are signed [v2]

David Holmes dholmes at openjdk.java.net
Wed Jan 19 22:36:50 UTC 2022


On Wed, 19 Jan 2022 18:22:13 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> For any SA test that attaches to an OSX process (this would be all SA tests except for those that test core file support), there is a check to make sure that the target jvm process is not a signed binary. If it is, SkippedException is thrown, and the test passes without doing anything. This is all we can do since being signed implied being notarized, and debuggers cannot attach to a notarized binary.
>> 
>> I noticed that on macosx-aarch64, all our SA tests that attach to a process were being skipped because the binary was signed, even for debug builds. It turns out that for macosx-aarch64, the linker always ads what is known as ad-hoc signing. You can find some info on ad-hoc signing here:
>> 
>> https://eclecticlight.co/2020/08/22/apple-silicon-macs-will-require-signed-code/
>> 
>> The tests use the codesign tool to determine if the binary is signed. Normally the check just relies on getting an error code of 1 when not signed, but since all binaries are now signed on macosx-aarch64, we need to modify the check to ignore ad-hoc signing.
>> 
>> Using "codesign --display" on an an ad-hoc signed binary shows some output that is of interest:
>> 
>> bash-3.2$ codesign --display --verbose=4 a.out
>> CodeDirectory v=20400 size=254 flags=0x20002(adhoc,linker-signed) hashes=5+0 location=embedded 
>> 
>> Looking for flags=0x20002(adhoc,linker-signed) will tell us if the binary is adhoc signed, which means we can assume that the SA tests can still be run against it. 
>> 
>> Looking for flags=0x10000(runtime) will tell us that the binary is hardened. These are binaries that we cannot use with SA.
>> 
>> If the binary is not signed at all, which should only happen on macosx-x64, codesign will print the message "code object is not signed at all". We can also run SA against these binaries.
>> 
>> Due to fixing the issue, we now have to problem list a few more core file tests on macosx-aarch64 due to 8269982. This issue was not noticed in the past because the tests were not being run. This was due to most of our macosx-aarch64 machines not being capable of producing a core file. Without this fix the test assumes it couldn't produce the core file because the binary was signed. With this fix it, for binaries that are not hardened the test will fail if it does not produce a core file.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyrights

Okay. If the verbose output changes then we won't match and so will assume not-hardened and so proceed with the test. If then test then fails because the runtime actually was hardened then we will see in the log (hopefully) that the output was not as expected.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6906


More information about the serviceability-dev mailing list