forking new process when calling gnutls_global_init() function

[Simon Josefsson]

"Haidar Habib" <h.habib at gmail.com> writes:

> Hi Werner,
>
> I have done some debugging on the child process. Following is the
> output of bactrace(bt) of functions call by it.
> Pls look into this if this helps.
>
>
> #0  0xc0201020 in _write_sys+0x10 () from /usr/lib/libc.2
> #1  0xc020d13c in write+0xc4 () from /usr/lib/libc.2
> #2  0xc6478130 in start_gatherer+0x320 () from /usr/local/lib/libgcrypt.sl.13
> #3  0xc64784f4 in _gcry_rndunix_gather_random+0x148 ()
>    from /usr/local/lib/libgcrypt.sl.13
> #4  0xc642e128 in read_random_source+0xe0 ()
>    from /usr/local/lib/libgcrypt.sl.13
> #5  0xc642dc04 in random_poll+0x58 () from /usr/local/lib/libgcrypt.sl.13
> #6  0xc642d6bc in read_pool+0x308 () from /usr/local/lib/libgcrypt.sl.13
> #7  0xc642c6cc in gcry_randomize+0x1b0 () from /usr/local/lib/libgcrypt.sl.13
> #8  0xc5b46fa0 in gc_pseudo_random+0x38 ()
>    from /usr/local/lib/libgnutls-extra.sl.13
> #9  0xc6357c84 in gnutls_global_init+0x42c ()
>    from /usr/local/lib/libgnutls.sl.13

This looks consistent with what Werner described how it is intended to
work.

> Actually my concern is why the child process is visible in HPUX os and
> not in LINUX. Is this because in HPUX there is no /dev/random device
> defined or due to any other reason.

Yes, that's the reason.  On linux, cipher/rndlinux.c is used, which is
very different from cipher/rndunix.c which is used under HPUX.

> For us it is not a good option to have a child process wtih our actual process.
> So can you pls provide some fix so that no child process is present there .

EGD was suggested, and if it didn't work, the only other option is to
modify libgcrypt to do something else -- you could check with the HPUX
documentation if there isn't a entropy API somewhere.

I wouldn't consider forking a child process to be a problem though.  It
is how libgcrypt was intended to work on generic unix systems.  If you
could describe in more detail why you think that is a problem (memory
usage?), maybe that problem could be fixed.

/Simon


>
> Regards,
> Haidar
>
> On Wed, Feb 20, 2008 at 11:27 PM, Werner Koch <wk at gnupg.org> wrote:
>> On Wed, 20 Feb 2008 14:38, h.habib at gmail.com said:
>>
>> > lets say our process name is dfn_tls. When we run this process and then
>> >  do ps -aef we get the following output.
>> >
>> >   haidar 24069 24068  0 17:53:54 ttyp1     0:00 ./dfn_tls clientDfn.cfg
>> >   haidar 24068 23117  0 17:53:51 ttyp1     0:04 ./dfn_tls clientDfn.cfg
>>
>> Okay that is useful.  I have not looked at the code for a long time, so
>> please excuse that I didn't mentioned it right away.  What libgcrypt
>> with rndunix does is to chreate a child process which runs an the actual
>> entropy gathering (spawing system utilities).  The child communicates
>> via a pipe with the parent and is controlled by the parent reading from
>> the child.  Thus after the parent read enough (i.e. got enough entropy),
>> the child (the entropy gatherer loop) will eventually wait in a write
>> call until the parent reads again from it.
>>
>> So now if you kill that child and libgcrypt (the parent) needs to get
>> more entropy it sits in a read without the other other end connected and
>> thus gets an EPIPE.  You should see a
>>
>>  "reading from gatherer pipe failed: %s"
>>
>> error message.  Of course we could restart the gatherer process but as
>> it should never terminate in the first place there is no point in
>> starting it again.  libgcrypt will instead hang in its random generator
>> because it is not able to load new entropy into its pool.
>>
>> If there is a real problem, you should either fire up a debugger or
>> sprinkle more debug printfs into it.
>>
>>
>>
>>
>> Shalom-Salam,
>>
>>   Werner
>>
>>
>>
>> --
>> Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.
>>
>>