forking new process when calling gnutls_global_init() function

Haidar Habib h.habib at gmail.com
Mon Feb 25 13:56:53 CET 2008


Thanks for all your suggestions. Finally I am able to do away with
this problem by installing random generator software KRNG11i in my
HPUX machine. This software created /dev/random and now no child
process is created.
Thanks

Regards,
Haidar Habib

On Thu, Feb 21, 2008 at 6:55 PM, Simon Josefsson <simon at josefsson.org> wrote:
> "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.
> >>
> >>
>



More information about the Gcrypt-devel mailing list