<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<p>Thanks for the update, there are still some build problems due to
compiler warnings/errors.</p>
<p>Perhaps <a class="moz-txt-link-freetext" href="https://wiki.openjdk.java.net/display/Build/Submit+Repo">https://wiki.openjdk.java.net/display/Build/Submit+Repo</a>
and
<a class="moz-txt-link-freetext" href="https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms">https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms</a>
would help?</p>
Regards,<br>
Valerie<br>
<br>
<div class="moz-cite-prefix">On 5/2/2018 4:50 PM, Martin Balao
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAKZz+gdo-ysMJzK6nd64rPKbVxXgR+L7sEdzupiArhWfQy8GrA@mail.gmail.com">
<div dir="ltr">Minor update (webrev 06):
<div><br>
</div>
<div> * Rebased to <span style="font-size:12.8px">cece972575ac
[1] (latest JDK revision today)</span></div>
<div> * Compiler warnings fixed</div>
<div><br>
</div>
<div> * <a
href="http://cr.openjdk.java.net/%7Embalao/webrevs/6913047/6913047.webrev.06/"
target="_blank" moz-do-not-send="true">http://cr.openjdk.java.net/<wbr>~mbalao/webrevs/6913047/<wbr>6913047.webrev.06/</a></div>
<div> * <a
href="http://cr.openjdk.java.net/%7Embalao/webrevs/6913047/6913047.webrev.06.zip"
target="_blank" moz-do-not-send="true">http://cr.openjdk.java.net/<wbr>~mbalao/webrevs/6913047/<wbr>6913047.webrev.06.zip</a></div>
<div>
<div><br>
</div>
</div>
<div>Kind regards,</div>
<div>Martin.-</div>
<div><br>
</div>
<div>--</div>
<div>[1] - <a
href="http://hg.openjdk.java.net/jdk/jdk/rev/cece972575ac"
target="_blank" style="font-size:12.8px"
moz-do-not-send="true">http://hg.openjdk.java.net/<wbr>jdk/jdk/rev/cece972575ac</a></div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Oct 12, 2017 at 10:00 AM,
Martin Balao <span dir="ltr"><<a
href="mailto:mbalao@redhat.com" target="_blank"
moz-do-not-send="true">mbalao@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>Webrev 04 uploaded to <a
href="http://cr.openjdk.java.net" target="_blank"
moz-do-not-send="true">cr.openjdk.java.net</a>:</div>
<div><br>
</div>
* <a
href="http://cr.openjdk.java.net/%7Esgehwolf/webrevs/mbalaoal/JDK-6913047/webrev.04/"
rel="noreferrer" style="font-size:12.8px"
target="_blank" moz-do-not-send="true">http://cr.openjdk.java.net/<wbr>~sgehwolf/webrevs/mbalaoal/<wbr>JDK-6913047/webrev.04/</a> (<span
style="font-size:12.8px">browse online</span>)<br
style="font-size:12.8px">
* <a
href="http://cr.openjdk.java.net/%7Esgehwolf/webrevs/mbalaoal/JDK-6913047/webrev.04/6913047.webrev.04.zip"
rel="noreferrer" style="font-size:12.8px"
target="_blank" moz-do-not-send="true">http://cr.openjdk.java.net/<wbr>~sgehwolf/webrevs/mbalaoal/<wbr>JDK-6913047/webrev.04/6913047.<wbr>webrev.04.zip</a> (download)<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote"><span class="">On Wed, Oct 11,
2017 at 10:31 AM, Martin Balao <span dir="ltr"><<a
href="mailto:mbalao@redhat.com" target="_blank"
moz-do-not-send="true">mbalao@redhat.com</a>></span>
wrote:<br>
</span>
<div>
<div class="h5">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>Hi,</div>
<div><br>
</div>
<div>I'd like to propose a fix for bug
JDK-6913047: "Long term memory leak when using
PKCS11 and JCE exceeds 32 bit process address
space" [1]. This fix does not contain changes
in the GC and is SunPKCS11 internal only.</div>
<div><br>
</div>
<div>PROBLEM</div>
<div>..............................<wbr>..........................</div>
<div><br>
</div>
<div>When using the SunPKCS11 crypto provider
(for cipher, signature, mac, key generation or
any other operation), multiple key objects may
be created. I.e.: every time a TLS session is
established, a unique master key (derived from
the pre-master-key) has to be created and then
used for encryption and decryption operations.
This is a legitimate use case in which key
caching does not make sense as each key is
unique per session. These keys are of P11Key
type and have a corresponding native key
object created. In the case of NSS SunPKCS11
backend (PKCS11 software token), this native
key object is temporarily stored in the
process native heap. The interface is simple:
a JNI call is done to create a native key
object (C_CreateObject, C_CopyObject,
C_DeriveKey, C_GenerateKeys, etc., according
to the PKCS11 interface) and an integer
handler is kept in the Java side (P11Key).
When the P11Key object is destroyed, a
finalizer code is executed to free the native
key object (through C_DestroyObject JNI call).
The problem is that finalizer code execution
happens only if the JVM garbage-collector
cleans up the P11Key object. That may be
delayed or not done at all, depending on
different GC algorithms, parameters and
environment conditions. As a result, the
native heap may be exhausted with not freed
native key objects, and the JVM will then
crash -this is particularly true for 32 bits
VMs where the virtual address space can be
exhausted-.</div>
<div><br>
</div>
<div><br>
</div>
<div>SCOPE</div>
<div>..............................<wbr>..........................</div>
<div><br>
</div>
<div>The fix is proposed for SunPKCS11 with NSS
backend only. Other PKCS11 backends are not
currently under scope. It's likely that
hardware PKCS11 backends store native key
objects in their own memory, preventing a
native heap exhaustion and a JVM crash.
However, it might be possible to cause an
exhaustion on their own memory blocking key
objects creation at some point. In any case,
this is speculative as no tests were done on
our side with real hardware.</div>
<div><br>
</div>
<div><br>
</div>
<div>SOLUTION</div>
<div>..............................<wbr>..........................</div>
<div><br>
</div>
<div>Assuming that native keys are extractable,
the idea is to hold native key data in the
Java heap while keys are not in use. When a
P11Key is created, every CK_ATTRIBUTE (PKCS11)
value for the native key is queried, data
stored in an opaque Java byte[] (inside the
P11Key object) and native key destroyed. Every
time the P11Key is about to be used, the
native key is created with the stored data.
After usage, the native key is again
destroyed. Thus, it's not necessary to wait
for a finalizer execution to cleanup native
resources: cleanup is done at deterministic
and previously-known points. This comes with a
resposibility for key users -which are all
SunPKCS11 internal services like P11Signature,
P11Cipher, P11KeyGenerator, etc.-: create and
destroy native keys through a reference
counting scheme exposed by P11Key class. There
are two kind of usages:</div>
<div><br>
</div>
<div> 1) stateless: the native key is
"atomically" created, used and destroyed.
I.e.: MAC calculation, getEncodedInternal
operation (on P11Key objects), signature
operations, TLS key derivation, etc.</div>
<div><br>
</div>
<div> 2) statefull: the native key is created,
one or multiple intermediate actions are
performed by the key user, a final action is
performed and finally the native key is
destroyed. I.e.: cipher operations.</div>
<div><br>
</div>
<div>For keys that are extractable but sensitive
(CKA_SENSITIVE attribute is true), as the case
when operating in FIPS mode,
wrapping/unwrapping is used as a workaround to
extract session keys. Wrapper key is global
and lives forever.</div>
<div><br>
</div>
<div>There are no interface changes for
SunPKCS11 external users.</div>
<div><br>
</div>
<div>If keys are not extractable or the feature
cannot be enabled for any other reason, the
previous finalizer scheme is used as a
fallback.</div>
<div><br>
</div>
<div><br>
</div>
<div>ADDITIONAL IMPLEMENTATION NOTES</div>
<div>..............................<wbr>..........................</div>
<div><br>
</div>
<div>When a P11Key is created, a constructor
parameter exists to indicate if the feature is
enabled for that specific key. For this
feature to be enabled, 2 additional conditions
apply: 1) SunPKCS11 backend has to be NSS, and
2) key has to be extractable. If the feature
is not enabled for a key, behavior is as
previous to this patch (native key destruction
relies on finalizer execution).</div>
<div><br>
</div>
<div>The only P11Key user that explicitly does
not use this feature is P11KeyStore. This is
because these keys (token keys) are managed by
alias names and makes no sense to remove them
from the key store (they need to be accessible
by an alias at any time).</div>
<div><br>
</div>
<div>Because P11Key objects can be used by
multiple threads at a time, there is a
thread-safe reference counting scheme in order
to decide when a native key object has to be
created or destroyed. The SunPKCS11 internal
API to use a P11Key is as follows: 1)
increment the reference counter (which will
eventually create the native key object if it
doesn't exist), 2) use the key and 3)
decrement the reference counter (which will
eventually destroy the native key if there
it's not being used by anyone else).</div>
<div><br>
</div>
<div>The reason why an opaque byte[] is used in
P11Key objects to store native keys data
(instead of a CK_ATTRIBUTE[] Java objects,
queried by Java's C_GetAttributeValue
function) is performance. My prototypes show a
difference of 4x in speed. 2 functions were
added to libj2pkcs11 library: getNativeKeyInfo
(to extract the opaque byte[] from a native
key object) and createNativeKey (to create a
native key object from an opaque byte[]).</div>
<div><br>
</div>
<div><br>
</div>
<div>CHANGESET</div>
<div>..............................<wbr>..........................</div>
<div><br>
</div>
<div>This changeset is JDK-10 (at jdk
c8796a577885 rev) based:</div>
<div><br>
</div>
<div> * <a
href="http://people.redhat.com/mbalaoal/webrevs/jdk_6913047_sunpkcs11_nss_memory_leak/2017_10_06/6913047.webrev.04/"
target="_blank" moz-do-not-send="true">http://people.redhat.com/mbala<wbr>oal/webrevs/jdk_6913047_sunpkc<wbr>s11_nss_memory_leak/2017_10_<wbr>06/6913047.webrev.04/</a>
(browse online)</div>
<div> * <a
href="http://people.redhat.com/mbalaoal/webrevs/jdk_6913047_sunpkcs11_nss_memory_leak/2017_10_06/6913047.webrev.04.zip"
target="_blank" moz-do-not-send="true">http://people.redhat.com/mbala<wbr>oal/webrevs/jdk_6913047_sunpkc<wbr>s11_nss_memory_leak/2017_10_<wbr>06/6913047.webrev.04.zip</a>
(download)</div>
<div><br>
</div>
<div><br>
</div>
<div>TESTING</div>
<div>..............................<wbr>..........................</div>
<div><br>
</div>
<div>Test suite for 32 bits JVMs only: <a
href="http://people.redhat.com/mbalaoal/webrevs/jdk_6913047_sunpkcs11_nss_memory_leak/2017_10_06/Bug6913047.java"
target="_blank" moz-do-not-send="true">http://people.redhat.com/mbala<wbr>oal/webrevs/jdk_6913047_sunpkc<wbr>s11_nss_memory_leak/2017_10_<wbr>06/Bug6913047.java</a></div>
<div><br>
</div>
<div> * Suite (Bug6913047.java)</div>
<div> * Tests JVM memory exhaustion while using
keys for different services: P11Cipher,
P11Signature, P11KeyAgreement, P11Mac,
P11Digest, P11KeyGenerator, P11KeyFactory,
etc.</div>
<div> * Tests functional regression.</div>
<div> * Including Key Stores (P11KeyStore)</div>
<div><br>
</div>
<div>Parameters to run the reproducer (on
JDK-10): </div>
<div> * javac: --add-modules jdk.crypto.cryptoki
--add-exports java.base/sun.security.interna<wbr>l.spec=ALL-UNNAMED </div>
<div> * java: -XX:+UseParallelGC -Xmx3500m
--add-modules jdk.crypto.cryptoki --add-opens
java.base/javax.crypto=ALL-UNN<wbr>AMED
--add-opens jdk.crypto.cryptoki/sun.securi<wbr>ty.pkcs11=ALL-UNNAMED</div>
<div><br>
</div>
<div>You can also use jtreg.</div>
<div><br>
</div>
<div><br>
</div>
<div>PERFORMANCE</div>
<div>..............................<wbr>..........................</div>
<div><br>
</div>
<div>For a quick reproducer previously developed
(which looped 100000 times creating P11Cipher
and P11Key objects to encrypt a plaintext),
these are the figures I got:</div>
<div><br>
</div>
<div> * real 1m11.328s (without fix)</div>
<div> * real 1m12.795s (with fix)</div>
<div><br>
</div>
<div>Performance penalty seems to be low in
current state.</div>
<div><br>
</div>
<div>OTHER</div>
<div>..............................<wbr>.........................</div>
<div><br>
</div>
<div>My employer has an OCA agreement with
Oracle and this work has been done in that
context.</div>
<div><br>
</div>
<div>Look forward to your comments.</div>
<div><br>
</div>
<div>Kind regards,</div>
<div>Martin.-</div>
<div><br>
</div>
<div>--</div>
<div>[1] - <a
href="https://bugs.openjdk.java.net/browse/JDK-6913047"
target="_blank" moz-do-not-send="true">https://bugs.openjdk.java.net/<wbr>browse/JDK-6913047</a></div>
</div>
</blockquote>
</div>
</div>
</div>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>