|

Conflicting SIGCHLD handling

View: New views

7 Messages — Rating Filter: Alert me

	Conflicting SIGCHLD handling by Scott Neugroschl-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Some parts of this message have been removed. Learn more about Nabble's security policy. I’m getting the “Conflicting SIGCHLD handling detected” error. Having read the comment in the code, I understand the reasons for defaulting SIGCHLD in slowPoll. In trying to trace the calls to slowPoll, I’m trying to figure out if its only called at initialization, or if it can be called (during normal usage) later on in the session…. I’ve got an app that needs to handle SIGCHLD, and am worried about the (very short) race condition caused by setting the handler to SIG_DFL in that routine. So… Is this an initialization only issue, that can be handled by moving my application signal handling initialization past cryptlib initialization, or is it possible for this condition to occur later on during normal use? ---- Scott Neugroschl XYPRO Technologies scott_n@... 805-583-2874 x121 _______________________________________________ Cryptlib mailing list Cryptlib@... via Mail: cryptlib-request@... Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/ http://news.gmane.org/gmane.comp.encryption.cryptlib Posts from non-subscribed addresses are blocked to prevent spam, please subscribe in order to post messages.
	Re: Conflicting SIGCHLD handling by Peter Gutmann :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message "Scott Neugroschl" <scott_n@...> writes: >I'm getting the "Conflicting SIGCHLD handling detected" error. Having >read the comment in the code, I understand the reasons for defaulting >SIGCHLD in slowPoll. > >In trying to trace the calls to slowPoll, I'm trying to figure out if >its only called at initialization, or if it can be called (during normal >usage) later on in the session.... I've got an app that needs to handle >SIGCHLD, and am worried about the (very short) race condition caused by >setting the handler to SIG_DFL in that routine. > >Is this an initialization only issue, that can be handled by moving my >application signal handling initialization past cryptlib initialization, >or is it possible for this condition to occur later on during normal >use? It's only called when entropy is needed, if you call it at initialisation and it gathers enough entropy then it won't be called again unless you explicitly call it. Note that it's up to you to call it (i.e. you control when the gathering is done), the built-in call is only performed if you don't call it yourself and it's not possible to continue without gathering entropy. (I'm assuming this isn't on any recent system with /dev/random, procfs, kstats, EGD, or something similar, since the entropy poll generally doesn't get called on those systems). Peter. _______________________________________________ Cryptlib mailing list Cryptlib@... via Mail: cryptlib-request@... Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/ http://news.gmane.org/gmane.comp.encryption.cryptlib Posts from non-subscribed addresses are blocked to prevent spam, please subscribe in order to post messages.
	Re: Conflicting SIGCHLD handling by Scott Neugroschl-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Quoth Peter: > > "Scott Neugroschl" <scott_n@...> writes: > > >I'm getting the "Conflicting SIGCHLD handling detected" error. Having > >read the comment in the code, I understand the reasons for defaulting > >SIGCHLD in slowPoll. > > > >In trying to trace the calls to slowPoll, I'm trying to figure out if > >its only called at initialization, or if it can be called (during > normal > >usage) later on in the session.... I've got an app that needs to > handle > >SIGCHLD, and am worried about the (very short) race condition caused > by > >setting the handler to SIG_DFL in that routine. > > > >Is this an initialization only issue, that can be handled by moving my > >application signal handling initialization past cryptlib > initialization, > >or is it possible for this condition to occur later on during normal > >use? > > It's only called when entropy is needed, if you call it at > initialisation and > it gathers enough entropy then it won't be called again unless you > explicitly > call it. Note that it's up to you to call it (i.e. you control when > the > gathering is done), the built-in call is only performed if you don't > call it > yourself and it's not possible to continue without gathering entropy. > > (I'm assuming this isn't on any recent system with /dev/random, procfs, > kstats, EGD, or something similar, since the entropy poll generally > doesn't > get called on those systems). Ran it through the debugger. Apparently /dev/urandom and EGD aren't giving enough entropy quality (only 75), so that it's falling into the slowPoll code. System is AIX 5.2 Scott _______________________________________________ Cryptlib mailing list Cryptlib@... via Mail: cryptlib-request@... Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/ http://news.gmane.org/gmane.comp.encryption.cryptlib Posts from non-subscribed addresses are blocked to prevent spam, please subscribe in order to post messages.
	Re: Conflicting SIGCHLD handling by Peter Gutmann :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message "Scott Neugroschl" <scott_n@...> writes: >Quoth Peter: >> "Scott Neugroschl" <scott_n@...> writes: >> >> >I'm getting the "Conflicting SIGCHLD handling detected" error. Having >> >read the comment in the code, I understand the reasons for defaulting >> >SIGCHLD in slowPoll. >> > >> >In trying to trace the calls to slowPoll, I'm trying to figure out if >> >its only called at initialization, or if it can be called (during normal >> >usage) later on in the session.... I've got an app that needs to handle >> >SIGCHLD, and am worried about the (very short) race condition caused by >> >setting the handler to SIG_DFL in that routine. >> > >> >Is this an initialization only issue, that can be handled by moving my >> >application signal handling initialization past cryptlib initialization, >> >or is it possible for this condition to occur later on during normal >> >use? >> >> It's only called when entropy is needed, if you call it at initialisation and >> it gathers enough entropy then it won't be called again unless you explicitly >> call it. Note that it's up to you to call it (i.e. you control when the >> gathering is done), the built-in call is only performed if you don't call it >> yourself and it's not possible to continue without gathering entropy. >> >> (I'm assuming this isn't on any recent system with /dev/random, procfs, >> kstats, EGD, or something similar, since the entropy poll generally doesn't >> get called on those systems). > >Ran it through the debugger. Apparently /dev/urandom and EGD aren't >giving enough entropy quality (only 75), so that it's falling into the >slowPoll code. > >System is AIX 5.2 I assume only one of /dev/urandom and EGD are present, since they both contribute a quality factor of 75 which is over the 100 needed. cryptlib won't rely on a single entropy source so it won't use just /dev/urandom or EGD alone. Is it possible to get access to the AIX box? Another solution would be to find alternative entropy sources (things like procfs or Sun's kstats) so the full entropy poll is never done, but I'd need access to the machine to do that. Peter. _______________________________________________ Cryptlib mailing list Cryptlib@... via Mail: cryptlib-request@... Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/ http://news.gmane.org/gmane.comp.encryption.cryptlib Posts from non-subscribed addresses are blocked to prevent spam, please subscribe in order to post messages.
	Re: Conflicting SIGCHLD handling by Scott Neugroschl-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Peter <pgut001@...> wrote > Sent: Tuesday, July 22, 2008 9:37 AM > To: cryptlib@...; Scott Neugroschl > Subject: Re: [Cryptlib] Conflicting SIGCHLD handling > > "Scott Neugroschl" <scott_n@...> writes: > > >I'm getting the "Conflicting SIGCHLD handling detected" error. Having > >read the comment in the code, I understand the reasons for defaulting > >SIGCHLD in slowPoll. > > > >In trying to trace the calls to slowPoll, I'm trying to figure out if > >its only called at initialization, or if it can be called (during > normal > >usage) later on in the session.... I've got an app that needs to > handle > >SIGCHLD, and am worried about the (very short) race condition caused > by > >setting the handler to SIG_DFL in that routine. > > > >Is this an initialization only issue, that can be handled by moving my > >application signal handling initialization past cryptlib > initialization, > >or is it possible for this condition to occur later on during normal > >use? > > It's only called when entropy is needed, if you call it at > initialisation and > it gathers enough entropy then it won't be called again unless you > explicitly > call it. Note that it's up to you to call it (i.e. you control when > the > gathering is done), the built-in call is only performed if you don't > call it > yourself and it's not possible to continue without gathering entropy. > > (I'm assuming this isn't on any recent system with /dev/random, procfs, > kstats, EGD, or something similar, since the entropy poll generally > doesn't > get called on those systems). This is a client's system. We had them set their signal handlers post-initialization, but it still seems to be occurring. I did some checks. This is an AIX 5 system. It has /dev/random. It has a procfs, but no /proc/interrupts. It has no kstat, and EGD/PRNGD is not running. Any suggestions? _______________________________________________ Cryptlib mailing list Cryptlib@... via Mail: cryptlib-request@... Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/ http://news.gmane.org/gmane.comp.encryption.cryptlib Posts from non-subscribed addresses are blocked to prevent spam, please subscribe in order to post messages.
	Re: Conflicting SIGCHLD handling by Peter Gutmann :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message "Scott Neugroschl" <scott_n@...> writes: >This is an AIX 5 system. It has /dev/random. It has a procfs, but no >/proc/interrupts. It has no kstat, and EGD/PRNGD is not running. Any >suggestions? In random/unix.c, line 865, can you add: ( defined( _AIX ) && ( OSVERSION >= 5 ) ) to the #ifdef and see if that helps? Also, uncomment the '#define DEBUG_RANDOM' at the start of the file to see where entropy is coming from, you should get messages like "PIOXYZ contributed x bytes". (We should probably also do this in private mail since I'm not sure that everyone on the list wants to see the debugging info :-). Peter. _______________________________________________ Cryptlib mailing list Cryptlib@... via Mail: cryptlib-request@... Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/ http://news.gmane.org/gmane.comp.encryption.cryptlib Posts from non-subscribed addresses are blocked to prevent spam, please subscribe in order to post messages.
	Re: Conflicting SIGCHLD handling by Scott Neugroschl-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Peter wrote: > "Scott Neugroschl" <scott_n@...> writes: > > >This is an AIX 5 system. It has /dev/random. It has a procfs, but no > >/proc/interrupts. It has no kstat, and EGD/PRNGD is not running. Any > >suggestions? > > In random/unix.c, line 865, can you add: > > ( defined( _AIX ) && ( OSVERSION >= 5 ) ) > > to the #ifdef and see if that helps? Also, uncomment the '#define > DEBUG_RANDOM' at the start of the file to see where entropy is coming > from, > you should get messages like "PIOXYZ contributed x bytes". > > (We should probably also do this in private mail since I'm not sure > that > everyone on the list wants to see the debugging info :-). Here's another dumb question related to this. It looks like the gathererOldHandler is only restored if it's NOT SIG_DFL. See random/unix.c lines 1784-1812 in 3.3.2. There may be an issue here. If the calling code uses SIG_DFL, but with a different sa_mask or sa_flags, those flags and mask will not be restored. Is there a reason that the old handler (flags, mask, and all) is not restored unconditionally? _______________________________________________ Cryptlib mailing list Cryptlib@... via Mail: cryptlib-request@... Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/ http://news.gmane.org/gmane.comp.encryption.cryptlib Posts from non-subscribed addresses are blocked to prevent spam, please subscribe in order to post messages.