Hi Martin, Thank you very much for your comments. On 04/03/2018 09:50 AM, Doerr, Martin wrote:
I think the Java and shared C++ code and should not use PPC64 specific names because it may get used for other platforms as well?
I fixed all the names and changed the provider's name to HWTRNG (previously it was P9TRNG). I changed the names for the helpers to something more "neutral" and removed the snake_case from their names. Yes, it may get used for other platforms and can get used readily by other platforms by providing an intrinsic for the randomLong() method. I provided an unique value for serialVersionUID in the new JCA provider by using an increment of a preexisting one. Do you know if there is any other (formal) way to determine that value?
Some people don't want to trust relying solely on the hardware number generator which cannot get reviewed publicly. So would it make sense to use the instruction mixed with something else?
Yes, I'm aware of the caveat... I the past Intel's 'rdrand' received a lot of criticism in that sense. I've talked to NX RNG designed and we've tried to find out a documentation about it on OpenPOWER foundation but it's not available yet. In any case, just like the use of 'rdrand' on OpenSSL that is disabled by default, wouldn't that be fine to use 'darn' on OpenJDK provided its use is optional and deliberated? Currently the user needs to (a) explicitly use the new provider by SecureRandom.getInstance("HWTRNG") and (b) unlock it using "-XX:+UnlockExperimentalVMOptions -XX:+UseRANDOMIntrinsics". In that sense, do you think it would be acceptable?
It would be good to have the complete change in one webrev for easier reviewing.
Sure. Thanks for letting me know. Here is the new webrev: http://cr.openjdk.java.net/~gromero/POWER9/darn/v3/webrev/ Thanks a lot. Best regards, Gustavo
Thanks and best regards, Martin
-----Original Message----- From: Gustavo Romero [mailto:gromero@linux.vnet.ibm.com] Sent: Montag, 2. April 2018 13:55 To: Volker Simonis <volker.simonis@gmail.com>; Doerr, Martin <martin.doerr@sap.com>; vladimir.kozlov@oracle.com Cc: ppc-aix-port-dev@openjdk.java.net Subject: [RFC] Re: POWER9: Is there a way to improve the random number generation on PPC64? Importance: High
Hi Martin, Volker, Vladimir
Sorry for the huge delay replaying on this...
I hope Martin (and Lutz) are feeling better and fully recovered.
On 11/24/2017 08:04 PM, Volker Simonis wrote:
Hi Gustavo,
in one of my talks [1,2] I have an example on how to intrinsify Random.nextInt() in C2 by using the Intel 'rdrandl' instruction. But please notice that this is just a "toy" example - it is not production ready. In fact I think the right way would be to create a new SecureRandom provider where you may implement "engineNextBytes" by using the new Power instruction (maybe by calling a native function). This special implementation of "engineNextBytes" could then be intrinsified as described in the talk.
Also, before you start this, please contact the security mailing list just to make sure you're not going into the wrong direction (I'm not a security expert :) I've created a new JCA provider called 'P9TRNG' and implemented a darn intrinsic for Interpreter, C1, and C2 compiler and did a couple of tests using micro benches [1, 2] to check the latency and throughput to get a random number using generateSeed() and nextBytes() with darn in place.
The 'P9TRNG' provider is basically a copy of 'NativePRNG' since it's necessary a software fallback in case darn instruction fails to return a valid random number after ten attempts (although it's very rare condition). On the other hand 'P9TRNG' uses the darn intrinsic when it's available.
The maximum theoretical throughput on the machine I'm testing it (a POWER9 witherspoon) is 128Mbps and there is one RNG per socket, so only one RNG per CPU. With a simple C code it's possible to get very close to that value (please see C code [3] for code details and log [4] for the expected outputs). Unrolling the tight loop does not help and causes a performance degradation.
On Hotspot, for Interpreter and C1 the throughput is ~3x higher than the version that does not use darn instruction (using micro benches [1, 2]):
gromero@gromero1:~/git/darn$ /tmp/jdk11/jvm/openjdk-11-internal/bin/java next_bytes SHA1PRNG 1024 10 3.8759432E7 ns 2.113550 Mbps gromero@gromero1:~/git/darn$ /tmp/jdk11/jvm/openjdk-11-internal/bin/java next_bytes SHA1PRNG 1024 100000 2.65902244E10 ns 30.808313 Mbps
gromero@gromero1:~/git/darn$ /tmp/jdk11/jvm/openjdk-11-internal/bin/java next_bytes NativePRNG 1024 100 7.1741008E7 ns 11.418853 Mbps gromero@gromero1:~/git/darn$ /tmp/jdk11/jvm/openjdk-11-internal/bin/java next_bytes NativePRNG 1024 100000 2.74547937E10 ns 29.838140 Mbps gromero@gromero1:~/git/darn$ /tmp/jdk11/jvm/openjdk-11-internal/bin/java -Xcomp -XX:TieredStopAtLevel=3 next_bytes NativePRNG 1024 100000 5.5632339E10 ns 14.725248 Mbps gromero@gromero1:~/git/darn$ /tmp/jdk11/jvm/openjdk-11-internal/bin/java -Xcomp -XX:-TieredCompilation next_bytes NativePRNG 1024 100000 2.78629519E10 ns 29.401051 Mbps
[With darn disabled: performance like NativePRNG] gromero@gromero1:~/git/darn$ /tmp/jdk11/jvm/openjdk-11-internal/bin/java next_bytes P9TRNG 1024 100 7.0272888E7 ns 11.657412 Mbps gromero@gromero1:~/git/darn$ /tmp/jdk11/jvm/openjdk-11-internal/bin/java next_bytes P9TRNG 1024 100000 2.75566244E10 ns 29.727880 Mbps ...
[With darn enabled] gromero@gromero1:~/git/darn$ /tmp/jdk11/jvm/openjdk-11-internal/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseDARN next_bytes P9TRNG 1024 100 8305029.0 ns 98.639030 Mbps gromero@gromero1:~/git/darn$ /tmp/jdk11/jvm/openjdk-11-internal/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseDARN next_bytes P9TRNG 1024 100000 6.442112E9 ns 127.163261 Mbps gromero@gromero1:~/git/darn$ /tmp/jdk11/jvm/openjdk-11-internal/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseDARN -Xcomp -XX:TieredStopAtLevel=3 next_bytes P9TRNG 1024 100000 1.57303337E10 ns 52.077728 Mbps gromero@gromero1:~/git/darn$ /tmp/jdk11/jvm/openjdk-11-internal/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseDARN -Xcomp -XX:-TieredCompilation next_bytes P9TRNG 1024 100000 6.46914E9 ns 126.631973 Mbps
For C2 compiler using darn is better until it reaches ~128Mbps (maximum theoretical throughput), but on the other hand it never blocks, so, for instance, generateSeed() which normally uses /dev/random (blocking) is not affected by a lack of entropy in Linux entropy pool.
@Vladimir, Volker mentioned that you already experimented with rand on Intel. Do you know if creating a new JCA provider as I did is a reasonable approach to exploit darn on POWER9? Also, in my implementation I had to create a VM intrinsic (_darn) in vmSymbols that is, let's say, arch dependent, and that seems to be the only case so far, but on the other hand a new JCA provider (with methods to be intrinsified) is necessary (I don't see another way to intrinsify the methods in NativePRNG/SHA1PRNG providers since I need a software fallback to darn). Do you have any recommendation about it?
The patchset rebased on top of jdk11 (http://hg.openjdk.java.net/jdk/hs) is:
http://cr.openjdk.java.net/~gromero/POWER9/darn/v1/0_PPC64_Add_JCA_provider_... http://cr.openjdk.java.net/~gromero/POWER9/darn/v1/1_PPC64_Assembler_add_sup... http://cr.openjdk.java.net/~gromero/POWER9/darn/v1/2_PPC64_Interpreter_add_t... http://cr.openjdk.java.net/~gromero/POWER9/darn/v1/3_PPC64_C2_Compiler_add_n... http://cr.openjdk.java.net/~gromero/POWER9/darn/v1/4_PPC64_C1_Compiler_add_i...
I intend to contribute that change as an experimental feature.
Thank you.
Best regards, Gustavo
[1] https://github.com/gromero/darn/blob/master/next_bytes.java [2] https://github.com/gromero/darn/blob/master/generate_seed.java [3] https://github.com/gromero/darn/blob/master/C/darn.c [4] https://github.com/gromero/darn/blob/master/C/darn.log