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

Wang Weijun weijun.wang at oracle.com
Mon Nov 9 01:40:32 UTC 2015


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

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

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




More information about the security-dev mailing list