JDK-8270199 : Most SA tests are skipped on macosx-aarch64 because all executables are signed
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Affected Version: 17,18
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-07-09
  • Updated: 2024-03-25
  • Resolved: 2022-01-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 17 JDK 19
11.0.24Fixed 17.0.10-oracleFixed 19 b08Fixed
Related Reports
Relates :  
JDK-8271512 - ProblemList serviceability/sa/sadebugd/DebugdConnectTest.java due to 8270326
Relates :  
JDK-8254941 - Implement Serviceability Agent for macOS/AArch64
Relates :  
JDK-8270326 - [MacOSX-AARCH64] serviceability/sa/sadebugd/DebugdConnectTest.java fails with java.rmi.ConnectException
Description
For any SA test that attaches to an OSX process (this would be all SA tests except for 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 recently just 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 couple lines in the output that are 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
Signature=adhoc

Whereas the output for a truly signed binary contains the following:

bash-3.2$ codesign --display --verbose=4 /Applications/Safari.app/
CodeDirectory v=20100 size=513 flags=0x2000(library-validation) hashes=9+5 location=embedded
Signature size=4442
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
Signed Time=May 13, 2021 at 10:54:23 AM
Internal requirements count=1 size=64

I think looking for "Signature=adhoc" should be sufficient for detecting ad-hoc signed binaries. We should be able to do a debugger attach to these binaries since they can't be notarized.
Comments
Fix request [11u] I backport this for parity with 11.0.24-oracle. No risk, only a test change. test/hotspot/jtreg/testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java Backport to the origin file. Add backport to JDK-8241951, since it is modified after this backport. Tests pass. SAP nightly testing passed.
25-03-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u-dev/pull/2616 Date: 2024-03-21 05:30:52 +0000
21-03-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/1866 Date: 2023-10-10 10:33:59 +0000
10-10-2023
Fix request [17u] I backport this for parity with 17.0.10-oracle. No risk, only a test change. Clean backport. Tests pass. SAP nightly testing passed.
10-10-2023
Changeset: 16e0ad0a Author: Chris Plummer <cjplummer@openjdk.org> Date: 2022-01-26 18:06:05 +0000 URL: https://git.openjdk.java.net/jdk/commit/16e0ad0ad088af3ba1c9903ed8df60799a1ba651
26-01-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk/pull/6906 Date: 2021-12-21 06:17:25 +0000
18-01-2022
man codesign ... OPTION FLAGS .... runtime On macOS versions >= 10.14.0, opts signed processes into a hardened runtime environment which includes run- time code signing enforcement, library validation, hard, kill, and debugging restrictions. These restric- tions can be selectively relaxed via entitlements. Note: macOS versions older than 10.14.0 ignore the pres- ence of this flag in the code signature. then https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution?language=objc ... Prepare Your Software for Notarization ... Enable the Hardened Runtime capability for your app and command line targets, as described in Enable hardened runtime.
12-07-2021
I found the following, which describes the flags but does not give their values: https://developer.apple.com/documentation/security/seccodesignatureflags So "runtime" means that it is hardened.
12-07-2021
Regarding the flags, I'm looking at 4 different binaries and this is what I see: -For the jdk debug binary I see flags=0x20002(adhoc,linker-signed) -For the jdk notarized product binary I see flags=0x10000(runtime) -For Safari I see flags=0x2000(library-validation) -For Garage Band I see flags=0x10200(kill,runtime) So it looks like checking for flags=0x10000(runtime) makes sense since this is what our notarized binary has, but I wish understood the exact meaning of these flags a bit better. For example, why does "runtime" equate to having been notarized.
10-07-2021
What really matters I believe is that the binary has the com.apple.security.get-task-allow entitlement, and a notarized binary cannot have this entitlement. I think this entitlement is added automatically by xcode, but at some point gets stripped out either before or during notarization.
10-07-2021
In JDK-8269982 you said: > "notarization" has not much to do with the issue. notarization is some process on Apple server which doesn't change you binaries. > So you can have fully/properly signed JDK ( with hardened-runtime enabled) but not yet notarized, it will still fail to create core file. > IMHO using word "notarized" here only leads to more confusion. >The real "enemy" here is https://developer.apple.com/documentation/security/hardened_runtime which happen to be one of requirements for jdk to pass notrarization process
10-07-2021
I believe this is wrong: >I think looking for "Signature=adhoc" should be sufficient for detecting ad-hoc signed binaries. We should be able to do a debugger attach to these binaries since they can't be notarized. looking for flags=0x10000(runtime) is the right approach
09-07-2021