RFR: 8270199: Most SA tests are skipped on macosx-aarch64 because all executables are signed
David Holmes
dholmes at openjdk.java.net
Wed Jan 19 06:53:27 UTC 2022
On Tue, 21 Dec 2021 06:17:25 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.
Hi Chris,
Seems fine. My only query/concern here is how reliable/stable this codesign verbose output is?
Thanks,
David
test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java line 2:
> 1: /*
> 2: * Copyright (c) 2014, 2021, Oracle and/or its affiliates. All rights reserved.
2022 :)
-------------
Marked as reviewed by dholmes (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/6906
More information about the serviceability-dev
mailing list