Date: Thu, 21 Aug 2014 15:32:46 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Roger Pau Monn? <royger@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Bryan Drewery <bdrewery@FreeBSD.org> Subject: Re: svn commit: r265003 - head/secure/usr.sbin/sshd Message-ID: <20140821123246.GH2737@kib.kiev.ua> In-Reply-To: <53F5D42E.9080908@FreeBSD.org> References: <201404270528.s3R5SEIm054377@svn.freebsd.org> <53F4B381.5010205@FreeBSD.org> <20140820151310.GB2737@kib.kiev.ua> <53F4BC9B.3090405@FreeBSD.org> <53F4BEB1.6070000@FreeBSD.org> <53F4C022.5050804@FreeBSD.org> <20140821080541.GE2737@kib.kiev.ua> <53F5D42E.9080908@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--o8DTQsiwS+K7TY1f Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 21, 2014 at 01:12:46PM +0200, Roger Pau Monn? wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 21/08/14 10:05, Konstantin Belousov wrote: > > On Wed, Aug 20, 2014 at 05:34:58PM +0200, Roger Pau Monn? wrote: > >> On 20/08/14 17:28, Bryan Drewery wrote: > >>> On 8/20/2014 10:19 AM, Roger Pau Monn? wrote: > >>>> On 20/08/14 17:13, Konstantin Belousov wrote: > >>>>> On Wed, Aug 20, 2014 at 04:41:05PM +0200, Roger Pau Monn??=20 > >>>>> wrote: > >>>>>> On 27/04/14 07:28, Konstantin Belousov wrote: > >>>>>>> Author: kib Date: Sun Apr 27 05:28:14 2014 New=20 > >>>>>>> Revision: 265003 URL:=20 > >>>>>>> http://svnweb.freebsd.org/changeset/base/265003 > >>>>>>>=20 > >>>>>>> Log: Fix order of libthr and libc in the global dso=20 > >>>>>>> list for sshd, by explicitely linking main binary with=20 > >>>>>>> -lpthread. Before, libthr appeared in the list due to=20 > >>>>>>> dependency of one of the kerberos libs. Due to the=20 > >>>>>>> change in ld(1) behaviour of not copying NEEDED entries > >>>>>>> from direct dependencies into the link results, the > >>>>>>> order becomes reversed. > >>>>>>>=20 > >>>>>>> The libthr must appear before libc to properly=20 > >>>>>>> interpose libc symbols and provide working rtld locks=20 > >>>>>>> implementation. The symptom was sshd hanging on rtld=20 > >>>>>>> bind lock during nested symbol binding from a signal=20 > >>>>>>> handler. > >>>>>>>=20 > >>>>>>> Approved by: des (openssh maintainer) Sponsored by: > >>>>>>> The FreeBSD Foundation MFC after: 1 week > >>>>>>>=20 > >>>>>>> Modified: head/secure/usr.sbin/sshd/Makefile > >>>>>>>=20 > >>>>>>> Modified: head/secure/usr.sbin/sshd/Makefile=20 > >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>=20 > - --- head/secure/usr.sbin/sshd/Makefile Sun Apr 27 05:19:01 2014 (r26500= 2) > >>>>>>> +++ head/secure/usr.sbin/sshd/Makefile Sun Apr 27=20 > >>>>>>> 05:28:14 2014 (r265003) @@ -57,6 +57,16 @@ CFLAGS+=3D=20 > >>>>>>> -DNONE_CIPHER_ENABLED DPADD+=3D ${LIBCRYPT} ${LIBCRYPTO}=20 > >>>>>>> ${LIBZ} LDADD+=3D -lcrypt -lcrypto -lz > >>>>>>>=20 > >>>>>>> +# Fix the order of NEEDED entries for libthr and > >>>>>>> libc. The libthr +# needs to interpose libc symbols, > >>>>>>> leaving the libthr loading as +# dependency of krb > >>>>>>> causes reversed order and broken interposing. Put +# > >>>>>>> the threading library last on the linker command line, > >>>>>>> just before +# the -lc added by a compiler driver. > >>>>>>> +.if ${MK_KERBEROS_SUPPORT} !=3D "no" +DPADD+=3D > >>>>>>> ${LIBPTHREAD} +LDADD+=3D -lpthread +.endif + .if > >>>>>>> defined(LOCALBASE) CFLAGS+=3D > >>>>>>> -DXAUTH_PATH=3D\"${LOCALBASE}/bin/xauth\" .endif > >>>>>>=20 > >>>>>> Hello, > >>>>>>=20 > >>>>>> This change makes the following simple test program fail=20 > >>>>>> on the second assert. The problem is that sa_handler =3D=3D=20 > >>>>>> SIG_DFL, and sa_flags =3D=3D SA_SIGINFO, which according to=20 > >>>>>> the sigaction(9) man page is not possible. With this=20 > >>>>>> change reverted the test is successful. > >>>>> I do not quite follow. > >>>>>=20 > >>>>> What are the relations between sshd and your test program ? > >>>>> Should the test be run somehow specially ? > >>>>=20 > >>>> No, and frankly that's what I don't understand. I compile=20 > >>>> this simple test with `cc -o test test.c`. It fails with > >>>> this commit applied, and succeeds without it. > >>>>=20 > >>>> Roger. > >>>>=20 > >>>=20 > >>> Does it fail if you do not connect with ssh? > >>=20 > >> Right, it works fine from the serial console, fails when > >> executed from ssh. > >=20 > > I cannot reproduce it locally with your scenario, but the attached=20 > > program demonstrates the issue without relying on inheritance and=20 > > libthr. > >=20 > > I think you mis-interpret the man page statement, it only says that > > SA_SIGINFO should not be set in new->sa_flags IMO. But I do not see > > much sense in the requirement. Note that we do not test flags for > > correctness at all. SUSv4 is also silent on the issue. > >=20 > > If this is important for your case, the following patch prevents=20 > > leaking of the flags for ignored of default/action signals. Could=20 > > you, please, describe why do you consider this a bug ? >=20 > IMO, it is an inconsistency to return an invalid old sigaction, I > assume that what is returned as the old sigaction should also be valid > according to the man page. >=20 > I realize SUSv4 don't specify such requirement, but it would still be > wrong to use SIG_DFL with SA_SIGINFO, since SA_SIGINFO expect the > handler to be of the type: >=20 > void func(int signo, siginfo_t *info, void *context); >=20 > While SIG_DLF is of type: >=20 > void func(int signo); >=20 > There's software out there that (wrongly?) relies on sa_action =3D=3D > SIG_DFL and (sa_flags & SA_SIGINFO) =3D=3D 0: >=20 > http://xenbits.xen.org/gitweb/?p=3Dxen.git;a=3Dblob;f=3Dtools/libxl/libxl= _fork.c;h=3Dfa150959adcfa6618342ba1eb0085cbba5f75d0a;hb=3DHEAD#l338 >=20 > The sa_flags check done here seems too strong in my opinion, but I > still think it's right according to the man page. Apparently, the original problem requires /bin/sh as the login shell to reproduce, while I used zsh on the test box. Below is the patch which fixes reset of flags both for sigaction(2) and execve(2). diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c index 561ea0a..4077ec9 100644 --- a/sys/kern/kern_sig.c +++ b/sys/kern/kern_sig.c @@ -621,6 +621,15 @@ sig_ffs(sigset_t *set) return (0); } =20 +static bool +sigact_flag_test(struct sigaction *act, int flag) +{ + + return ((act->sa_flags & flag) !=3D 0 && + (__sighandler_t *)act->sa_sigaction !=3D SIG_IGN && + (__sighandler_t *)act->sa_sigaction !=3D SIG_DFL); +} + /* * kern_sigaction * sigaction @@ -679,7 +688,7 @@ kern_sigaction(td, sig, act, oact, flags) =20 ps->ps_catchmask[_SIG_IDX(sig)] =3D act->sa_mask; SIG_CANTMASK(ps->ps_catchmask[_SIG_IDX(sig)]); - if (act->sa_flags & SA_SIGINFO) { + if (sigact_flag_test(act, SA_SIGINFO)) { ps->ps_sigact[_SIG_IDX(sig)] =3D (__sighandler_t *)act->sa_sigaction; SIGADDSET(ps->ps_siginfo, sig); @@ -687,19 +696,19 @@ kern_sigaction(td, sig, act, oact, flags) ps->ps_sigact[_SIG_IDX(sig)] =3D act->sa_handler; SIGDELSET(ps->ps_siginfo, sig); } - if (!(act->sa_flags & SA_RESTART)) + if (sigact_flag_test(act, SA_RESTART)) SIGADDSET(ps->ps_sigintr, sig); else SIGDELSET(ps->ps_sigintr, sig); - if (act->sa_flags & SA_ONSTACK) + if (sigact_flag_test(act, SA_ONSTACK)) SIGADDSET(ps->ps_sigonstack, sig); else SIGDELSET(ps->ps_sigonstack, sig); - if (act->sa_flags & SA_RESETHAND) + if (sigact_flag_test(act, SA_RESETHAND)) SIGADDSET(ps->ps_sigreset, sig); else SIGDELSET(ps->ps_sigreset, sig); - if (act->sa_flags & SA_NODEFER) + if (sigact_flag_test(act, SA_NODEFER)) SIGADDSET(ps->ps_signodefer, sig); else SIGDELSET(ps->ps_signodefer, sig); @@ -935,6 +944,11 @@ execsigs(struct proc *p) sigqueue_delete_proc(p, sig); } ps->ps_sigact[_SIG_IDX(sig)] =3D SIG_DFL; + SIGDELSET(ps->ps_siginfo, sig); + SIGDELSET(ps->ps_sigintr, sig); + SIGDELSET(ps->ps_sigonstack, sig); + SIGDELSET(ps->ps_sigreset, sig); + SIGDELSET(ps->ps_signodefer, sig); } /* * Reset stack state to the user stack. --o8DTQsiwS+K7TY1f Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT9ebuAAoJEJDCuSvBvK1BpE4P/1OCAwh5It16HWT/Nzo9eRO+ NVxLO9R8UCRUvS+n1UIwXVNrottNsWOpSVL7olK/saG/k1RQUzp6lCdOftcfOE1W GSnzbTEP/2+zjSFQZut6ZvGD+UMjM1lNJmmXG8tQTDJNLcGY7XnwsG3fHoazwdzv RN78BHMgjpcmlPAmRFc7hdZu2UlC1RNxKS90g7JUX2nLgXgGni34z8ISqlJbs4xM k3iOkXSEFok+zQ9oZaJ1cKpP2j5LcRV8dX+Wpg79yRe0uihJO+9h/gYwcHjdfgIe uU/QMJhNZOnG5DSbW3VSXenTy1DinjxDd/eeCA7vT7dyc2rLdG5znwqueAftGvQO pVlGx1ncnCuSAEG64AZ/9CnlaZjvZls/Rc9t/5bpv51xoKkoEtOZHc8evyB01z3X JrKO9+L8K5GVBAOBp79WV9neDGC7DYwTBr7Ba5+2zJ+OFuELhbwfLe7ba1JgMsZl pPMwPsFdLvolMGv01KIb5iwaML/Aq6wVS4ZYKXbEQZ8vksOgQaY2aR+CroXeDhGC DtpQrxjvBjv/DmVAV68++yicQ7HkJnraW69Er2NDQ1JVVE7xE6Klp5qVY+7hqaQY DmUWljGcCYLj+lIsZMjzUiCUSNkVcrnz6SsK6I0owEdEKvyXnrELClDS7KXrKGwu qNBTL5l0dls057LdtEso =HJy7 -----END PGP SIGNATURE----- --o8DTQsiwS+K7TY1f--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140821123246.GH2737>