Date: Sun, 26 Aug 2018 11:19:38 +0100 From: David Chisnall <theraven@FreeBSD.org> To: Willem Jan Withagen <wjw@digiware.nl> Cc: freebsd current <freebsd-current@freebsd.org> Subject: Re: Warnings about dlclose before thread exit. __cxa_thread_call_dtors Message-ID: <4BBFC07B-F995-42DD-8C93-5E93AE6AE1DD@FreeBSD.org> In-Reply-To: <6a57c77d-944d-166b-07a3-263aac8fe297@digiware.nl> References: <4b231ed8-f853-fb7e-06a7-b1bd57028ced@digiware.nl> <6a57c77d-944d-166b-07a3-263aac8fe297@digiware.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
The FreeBSD implementation here looks racy. If one thread dlcloses an = object while another thread is exiting, we can end up calling a function = at an invalid memory address. It also looks as if it may be possible to = unload one library, load another at the same address, and end up = executing entirely the wrong code, which would have some serious = security implications. The GNU/Linux equivalent of this function locks the DSO in memory until = all references to it have gone away. A call to dlclose() on GNU/Linux = will not actually unload the library until all threads with destructors = in that library have been unloaded. I believe that this reuses the same = reference counting mechanism that allows the same library to be dlopened = and dlclosed multiple times. It would be nice if the FreeBSD version had the same behaviour, because = this is almost certainly expected in code written on other platforms. David > On 18 Aug 2018, at 14:18, Willem Jan Withagen <wjw@digiware.nl> wrote: >=20 > Hi, >=20 > I've sent the question below to the Ceph-devel list, asking if any = recent changes would be able to cause this. >=20 > But then of course this could stem from FreeBSD libs, and of ports.... > So the question here is if anybody has gotten these "warnings" in = other tools. >=20 > --WjW >=20 >=20 > -------- Forwarded Message -------- > Subject: Warnings about dlclose before thread exit > Date: Sat, 18 Aug 2018 14:46:35 +0200 > From: Willem Jan Withagen <wjw@digiware.nl> > To: Ceph Development <ceph-devel@vger.kernel.org> >=20 > Hi, >=20 > I've have upgraded to FreeBSD ALPHA 12.0, but I don't think the errors = them from there. Although they could be in one of the libs that came = along with the upgrade. >=20 > I'm getting these warnings during rbd and ceph (maybe even more) = invocations that indicate that indicate a possible problem because: > =3D=3D=3D > It could be possible that a dynamically loaded library, use > thread_local variable but is dlclose()'d before thread exit. The > destructor of this variable will then try to access the address, > for calling it but it's unloaded, so it'll crash. We're using > __elf_phdr_match_addr() to detect and prevent such cases and so > prevent the crash. > =3D=3D=3D > this is from : = https://github.com/freebsd/freebsd/blob/master/lib/libc/stdlib/cxa_thread_= atexit_impl.c >=20 > Now it could be that dlclose() and thread exit are just closed to one = another. But still this is hard core embedded in libc already since = 2017, so I'm sort of expecting that a recent change has caused this. >=20 > And as indicated it is a possible cause for crashed, because = thread_exit is going to clean up things that are no longer there. >=20 > Now the 20 dollar question is: > Where was this introduced?? >=20 > Otherwise I'll have to try and throw my best gdb capabilities at it, = and try to invoke an rbd call and see where it activates this warning. >=20 > --WjW > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BBFC07B-F995-42DD-8C93-5E93AE6AE1DD>