Optional "sunec" native library of SunEC provider becomes mandatory when using SVM

[fcurts]

The SunEC provider has an optional sunec native library that provides additional algorithms.

We do not want to ship the sunec native library with our native executable due to licensing and packaging concerns. However, not providing this library gives the following runtime error when opening an HTTPS connection:

Exception in thread "main" java.lang.UnsatisfiedLinkError: sun.security.ec.ECKeyPairGenerator.generateECKeyPair(I[B[B)[Ljava/lang/Object; [symbol: Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair or Java_sun_security_ec_ECKeyPairGenerator_generateECKeyPair__I_3B_3B]
	at com.oracle.svm.jni.access.JNINativeLinkage.getOrFindEntryPoint(JNINativeLinkage.java:145)
	at com.oracle.svm.jni.JNIGeneratedMethodSupport.nativeCallAddress(JNIGeneratedMethodSupport.java:54)
	at sun.security.ec.ECKeyPairGenerator.generateECKeyPair(ECKeyPairGenerator.java)
	at sun.security.ec.ECKeyPairGenerator.generateKeyPair(ECKeyPairGenerator.java:128)
	at java.security.KeyPairGenerator$Delegate.generateKeyPair(KeyPairGenerator.java:703)
	at sun.security.ssl.ECDHCrypt.<init>(ECDHCrypt.java:78)
	at sun.security.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:783)
	at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:302)
	at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
	at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
	at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
	at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
	at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263)
	at java.net.URL.openStream(URL.java:1045)

The error is preceded by the following warning:

WARNING: The sunec native library, required by the SunEC provider, could not be loaded. This library is usually shipped as part of the JDK and can be found under <JAVA_HOME>/jre/lib/<platform>/libsunec.so. It is loaded at run time via System.loadLibrary("sunec"), the first time services from SunEC are accessed. To use this provider's services the java.library.path system property needs to be set accordingly to point to a location that contains libsunec.so. Note that if java.library.path is not set it defaults to the current working directory.

We've tried several workarounds. The only one that worked is (code is in Kotlin):

class MyFeature: Feature {
  override fun duringSetup(access: DuringSetupAccess) {
    System.loadLibrary("sunec")

    Log.setLog(object : RealLog() {
      override fun string(value: String?): Log = this
      override fun newline(): Log = this
    })
  }
}

Here, System.loadLibrary("sunec") prevents the UnsatisfiedLinkError (although we don't know why), and disabling logging prevents the warning.

The only usage of method generateECKeyPair in our project is in com.oracle.svm.hosted.SecurityServicesFeature, line 133:

JNIRuntimeAccess.register(sun.security.ec.ECKeyPairGenerator.class.getDeclaredMethod("generateECKeyPair", int.class, byte[].class, byte[].class));

We think this might be related to the issue we are seeing.

GraalVM CE 1.0.0-rc11, macOS 10.14.2

[fcurts]

Update:

After removing the SunEC provider from the java.security file, the following code reports the same ciphers as before. Hence I'm not sure how useful "SunEC without native library" is.

println(java.util.Arrays.toString(
      (javax.net.ssl.SSLSocketFactory.getDefault() as javax.net.ssl.SSLSocketFactory).supportedCipherSuites))

We've also managed to get Bouncy Castle to work by removing the SunEC provider from the java.security file, adding Security.addProvider(BouncyCastleProvider()) to our SVM feature (registering it in the java.security file had no effect), and setting the following native-image options:

--rerun-class-initialization-at-runtime=org.bouncycastle.crypto.prng.SP800SecureRandom
--rerun-class-initialization-at-runtime=org.bouncycastle.jcajce.provider.drbg.DRBG$Default
--rerun-class-initialization-at-runtime=org.bouncycastle.jcajce.provider.drbg.DRBG$NonceAndIV

With this in place, significantly more ciphers are reported at runtime, including the ECC ones. However, it adds 15 MB to the size of our executable, which is too much.

[fcurts]

Update 2:

I was able to get the provider list down to the following, but unfortunately it doesn't reduce binary size compared to the baseline without Bouncy Castle:

security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
security.provider.3=com.sun.net.ssl.internal.ssl.Provider
security.provider.4=com.sun.crypto.provider.SunJCE

[fcurts]

Update 3:

The solution we've settled on for now is to remove the SunEC provider from the java.security file. In this case, none of the mentioned workarounds is necessary, and HTTPS still works for us.

If there was a way to get ECC ciphers back without shipping a separate library or significantly increasing binary size, we'd love to hear about it.

[nhoughto]

Great info in your 3 updates thanks for the learnings, i've settled on adding BouncyCastle as a provider, and removing SunEC both via java.security, doing it via Security.addProvider/removeProvider doesn't appear to work in SVM.

This results in a binary that doesn't require a native library and can't still do HTTPS.

I did still need to set JVM args to the path of cacerts as per #768 which feels really weird as at the point of having a native image, you don't really think about needing a JRE anymore, and cacerts is something that ships with the JRE, ideally it would just use /etc/ssl/certs/ directly, like everything else..

[nhoughto]

My own update since rediscovering this, SunEC can be replaced with BC fairly easily like this:

https://github.com/bsycorp/make-jks/blob/master/java.security.overrides

Its a bit fragile but works.

[lvh]

Is there a way to disable SunEC without editing the java.security file?

[nhoughto]

My approach above doesn’t edit the file, overrides by environment variable? Other than that I don’t think so

[lvh]

@nhoughto That repository appears to have disappeared :) I'm passing -Dsecurity.provider.3=org.bouncycastle.jce.provider.BouncyCastleProvider to native-image directly, which feels like it should be equivalent to what you're doing, but doesn't work: I get the same SunEC error when I run the resulting application.

[lvh]

Starting from an app that works (if it has libsunec.so, at least), with [org.bouncycastle/bcprov-jdk15on "1.61"] on the classpath, All tests are with graalvm-19.0.0 with the following options:

["--verbose" "--no-fallback" "-Dclojure.compiler.direct-linking=true" "-H:+ReportExceptionStackTraces"  "--report-unsupported-elements-at-runtime" "--initialize-at-build-time"  "--enable-https"]

I tried both security.provider.3=sun.security.ec.SunEC and security.provider.3=org.bouncycastle.jce.provider.BouncyCastleProvider and both commented (so there's no provider 3) and they all have exactly the same behavior: at runtime, the app tries to load SunEC and fails. I have also tried adding -Dsecurity.provider.3=org.bouncycastle.jce.provider.BouncyCastleProvider and leaving java.security unchanged, which feels like it should be identical to what @nhoughto is doing, but that similarly appears to have no effect.

My best bet is that between -rc11 and 19.0.0, something changed in GraalVM in the handling of the provider, requiring it even if it's unset in jre/lib/security/java.security.

@nhoughto Which version of GraalVM are you trying this with?