On Tue, 21 Dec 2021 06:17:25 GMT, Chris Plummer <cjplum...@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
