POWER9: Is there a way to improve the random number generation on PPC64?

[Gustavo Romero]

Hi Volker,

On 29-11-2017 11:21, Volker Simonis wrote:
> On Wed, Nov 29, 2017 at 2:04 PM, Gustavo Romero
> <gromero at linux.vnet.ibm.com> wrote:
>> Hi Volker,
>>
>> On 24-11-2017 20:04, Volker Simonis wrote:
>>> 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.
>>
>> I've implemented a simple interpreter intrinsic for 'darn' for a given
>> class/method provided by the user, similarly to what you did for
>> Helloword.sayHello() in your example. Thanks! I'm now looking for the correct
>> way to call back from the intrinsic a Java method to act as a fallback method,
>> since ISA says [1]:
>>
>> When the error value is obtained [i.e. 'darn' did not return a random number],
>> software is expected to repeat the operation. If a non-error value has not been
>> obtained after several attempts, a software random number generation method
>> should be used. The recommended number of attempts may be implementation
>> specific. In the absence of other guidance, ten attempts should be adequate.
>>
>> and so I need to call back from the intrinsic, let's say, SecureRandom.netInt()
>> non-intrinsified method after about 10 failures to get the random number so it
>> can take over the task again. You did something like that here:
>>
>> https://github.com/simonis/JBreak2016/blob/master/examples/hs_patches/JBreak_HelloWorldIntrinsic.patch#L55
>>
>> but for fputs() from libc.
>>
>> Do you know if it's possible to call, for instance, a loaded method like
>> SecureRandom.nextInt() from the instrinsic?
>>
> 
> I don't think that would be easy to do (if possible at all).
> 
> The correct way to handle such situations would be to define a Java
> method with the exact semantics of your 'darn' instruction. All the
> other logic should be implemented in Java. So for example you would
> implement SecureRandom.darn() and call it from engineNextBytes(). At
> the call site of darn() you check the error value and dispatch to the
> corresponding Java implementation if necessary.

I've implemented a Java SecureRandom.darn() method [1]. I works as expected,
i.e. it returns 8 bytes of fake random number (using [3] example). However, when
I proceeded to intrinsify it [2, 0] as I did for the method provided by the user
(similarly to your HelloWorld example and for a user provided darn() method as I
mentioned previously) I hit the following check:

Compiler intrinsic is defined for method [_darn: static SecureRandom.darn()[B], but the method is not available in class [java/security/SecureRandom]. Exiting.

SecureRandom.darn() signature looks correct and I know that
java/security/SecureRandom::darn() is present in core libs because before trying
to intrinsify it worked ok (I've got the 8 bytes of fake random number - using
darning.java, below in references) and also 'javap' shows it's in .class:

gromero at gromero16:~/hg/jdk10/hs$ javap -c -s ./build/linux-ppc64le-normal-server-slowdebug/jdk/modules/java.base/java/security/SecureRandom.class | fgrep -i darn
  public byte[] darn();

I thought that no additional hack was necessary to get that intrinsic working as
it's in core libs, hence nothing like this is needed:

https://github.com/simonis/JBreak2016/blob/master/examples/hs_patches/JBreak2JavaZone.patch#L57-L59

On the other hand if I add @HotSpotIntrinsicCandidate to SecureRandom.darn() I
get:

Method [java.security.SecureRandom.darn()[B] is annotated with @HotSpotIntrinsicCandidate, but no compiler intrinsic is defined for the method. Exiting.

Any clue on what I'm missing? Is it correct to assume that since darn() now
is in core libs no check is necessary?

Thanks a lot!

Regards,
Gustavo

The hs patches:

[0] https://github.com/gromero/darn/blob/master/patches/0_darn_macroassembler.patch
[1] https://github.com/gromero/darn/blob/master/patches/1_SecureRandom_darn_Java.patch
[2] https://github.com/gromero/darn/blob/master/patches/2_SecureRandom_darn_intrinsic.patch

and the test-case:

[3] https://github.com/gromero/darn/blob/master/patches/darning.java

>> Thanks!
>>
>> Regards,
>> Gustavo
>>
>>> 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 :)
>>>
>>> Regards,
>>> Volker
>>>
>>> [1] https://vimeo.com/182074382
>>> [2] https://rawgit.com/simonis/JBreak2016/master/jbreak2016.xhtml#/
>>>
>>> On Fri, Nov 24, 2017 at 12:58 PM, Gustavo Romero
>>> <gromero at linux.vnet.ibm.com> wrote:
>>>> Hi,
>>>>
>>>> POWER9 processors introduced a new single instruction to generate a random
>>>> number called 'darn' (Deliver A Random Number) [1, 2]. The random number
>>>> generator behind this instruction is NIST SP800-90B and SP800-90C compliant and
>>>> provides a minimum of 0.5 bits of entropy per bit. That instruction is as simple
>>>> as "darn RT, L", where RT is general 64-bit purpose register and L is a 2-bit
>>>> operand to select the random number format. One can call 'darn' many times to
>>>> obtain a new random number each time.
>>>>
>>>> Initially I think it can help on the improving (throughput) of SecureRandom.generateSeed()
>>>> method & friends from JCE (NativePRNG provider). If that holds, so it has to
>>>> be done both for Interpreter and JIT.
>>>>
>>>> Currently generateSeed() from NativePRNG basically reads from /dev/random by
>>>> default (which blocks from time to time) or /dev/urandom if instructed to do so.
>>>> Could somebody please help me to figure out the appropriate place to exploit
>>>> such a P9 instruction for interpreted mode, given that code for generateSeed()
>>>> is pure Java and behind scenes just opens /dev/random file and reads from
>>>> it? For instance, is it correct to exploit it on a C/C++ code and attach that
>>>> by means of a JNI?
>>>>
>>>> Finally, for JITed mode, I think that a way to exploit such a feature would be
>>>> by matching an specific sub-tree in Ideal Graph and from that emit a `darn`
>>>> instruction, however I could not figure one sound sub-tree with known nodes
>>>> (AddI, LoadN, Parm, etc) that could be matched for that purpose. How do porters
>>>> usually proceed in this case?
>>>>
>>>> Any comments shedding some light on that is much appreciated.
>>>>
>>>> Thanks and best regards,
>>>> Gustavo
>>>>
>>>> [1] https://www.docdroid.net/tWT7hjD/powerisa-v30.pdf, p. 79
>>>> [2] https://openpowerfoundation.org/?resource_lib=power-isa-version-3-0
>>>>
>>>
>>
>