dlsym(RTLD_DEFAULT, "getentropy") return non-NULL on Mac

[Mike StJohns]

On 11/8/2015 8:40 PM, Wang Weijun wrote:
>> On Nov 9, 2015, at 5:45 AM, Mike StJohns <mstjohns at comcast.net> wrote:
>>
>> Hi Max et al -
>>
>> In general, I'm not a big fan of silent failover in security stuff.  There ought to be a way - perhaps a system property - to signal that if you don't get the originally desired entropy source, you'll throw an error.
> Agreed. I can use securerandom.source inside java.security.

securerandom.entropy.source?

>
>> Also, have you considered:
>>
>> https://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide?language=fr
>>
>> If you're going into the raw libraries, it might actually be a better idea to go straight to the chipset if RDSEED is available.
>>
>> (Hmm... also http://stackoverflow.com/questions/29372893/rdrand-and-rdseed-intrinsics-gcc-and-intel-c)
> Thanks for the links. That will be a nice enhancement.
>
> BTW, I'll file separate bugs for EntropyInput implementations. These are non-goals for the DRBG feature itself.

Yup - Mike

>
> Thanks
> Max
>
>> Mike
>>
>>
>> On 11/8/2015 6:18 AM, Dmitry Samersoff wrote:
>>> Wang Weijun,
>>>
>>>
>>>> The function is rather new in the latest Solaris beta [1] and it's
>>>> preferred to reading from /dev/random. There are already people
>>>> suggest adding it to Linux. If I use simply using dlsym then it will
>>>> automatically work on all current and future platforms. In fact, I
>>>> was planning to write
>>>>
>>> 1. Please, check libc only not entire process image.
>>>
>>> 2. OS X random system is a different story: /dev/random never blocks and
>>> returns the output of Yarrow PRNG.  Also OS X uses SecurityServer
>>> process to feed entropy pool.
>>>
>>> So IMHO, it's better to don't attempt to use other functions on OS X
>>> until it appears officially.
>>>
>>> 3. Please notice that:
>>>
>>>     /dev/random will block if you request more bits than entropy pool can
>>> provide.
>>>
>>>     but (according to manual page) getentropy will return immediately
>>> with error if less that requested bytes of entropy is available and you
>>> can't request more than 256 bytes of entropy at once.
>>>
>>>      it might require changes in uplevel logic.
>>>
>>> -Dmitry
>>>
>>>
>>> On 2015-11-08 03:37, Wang Weijun wrote:
>>>
>>>>> On Nov 8, 2015, at 4:29 AM, Dmitry Samersoff
>>>>>
>>>>> <dmitry.samersoff at oracle.com>
>>>>>   wrote:
>>>>>
>>>>> Wang Weijun,
>>>>>
>>>>> 1. RTLD_DEFAUL call is expensive and dangerous because it cause
>>>>> symbol search across all loaded images. So it can pick up something
>>>>> absolutely irrelevant to your expectations at any time.
>>>>>
>>>>> If you decide to play to this game, you have to use dladdr to check
>>>>> the origin of a symbol and try to guess whether it is what you are
>>>>> looking for or not.
>>>>>
>>>>> Please dlopen(libSystem.dylib, RTLD_NOW) and search through it
>>>>> only.
>>>>>
>>>>> 2. You shouldn't rely on return value of dlopen() or dlsym(). Call
>>>>> dlerror() and check whether it returns error or NULL.
>>>>>
>>>> I'll try.
>>>>
>>>>
>>>>> PS: What is the goal of using a get entropy ?
>>>>>
>>>> The function is rather new in the latest Solaris beta [1] and it's
>>>> preferred to reading from /dev/random. There are already people
>>>> suggest adding it to Linux. If I use simply using dlsym then it will
>>>> automatically work on all current and future platforms. In fact, I
>>>> was planning to write
>>>>
>>>> getentropy = (GETENTROPY_FN)dlsym(RTLD_DEFAULT, "getentropy"); if
>>>> (getentropy) { return 1; } else { getrandom =
>>>> (GETRANDOM_FN)dlsym(RTLD_DEFAULT, "getrandom"); if (getrandom) {
>>>> return 2; } else { return -1;  // will read /dev/random } }
>>>>
>>>> Thanks Max
>>>>
>>>> [1]
>>>>
>>>> https://blogs.oracle.com/darren/entry/solaris_new_system_calls_getentropy
>>>>
>>>>
>>>>
>>>>
>>>>> -Dmitry
>>>>>
>>>>> On 2015-11-07 05:51, Wang Weijun wrote:
>>>>>
>>>>>> I find something strange.
>>>>>>
>>>>>> Background: a new method getentropy() is available on OpenBSD [1]
>>>>>> and Solaris and people are also proposing it on other OSes.
>>>>>>
>>>>>> Therefore inside JDK I write a piece of native code to detect it,
>>>>>> something like
>>>>>>
>>>>>> typedef int (*GETENTROPY_FN)(char* buffer, int len);
>>>>>>
>>>>>> getentropy = (GETENTROPY_FN)dlsym(RTLD_DEFAULT, "getentropy"); if
>>>>>> (getentropy) { return 1; }
>>>>>>
>>>>>> On Mac, it returns non-NULL, but a later call to
>>>>>> (*getentropy)(cbuffer, length) shows
>>>>>>
>>>>>> #  SIGBUS (0xa) at pc=0x0000000103bfa030, pid=22434, tid=5891
>>>>>> ... # Problematic frame: # C  [libj2rand.dylib+0x1030]
>>>>>> getentropy+0x0
>>>>>>
>>>>>> However, "man getentropy" does not show anything, and the
>>>>>> following simple program also prints out 0x0
>>>>>>
>>>>>> #include <dlfcn.h> #include <stdlib.h>
>>>>>>
>>>>>> main() { void* g = dlsym(RTLD_DEFAULT, "getentropy");
>>>>>> printf("%p\n", g); }
>>>>>>
>>>>>> What does this mean? Is the JDK code loading another getentropy()
>>>>>> somewhere else? How do I detect it and what shall I do to avoid
>>>>>> it?
>>>>>>
>>>>>> Thanks Max
>>>>>>
>>>>>> [1]
>>>>>>
>>>>>> http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/getentropy.2
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>