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

[Volker Simonis]

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.

> 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
>>>
>>
>