Created new issue for it - https://github.com/cloudius-systems/osv/issues/1178
On Sunday, November 28, 2021 at 9:18:34 AM UTC-5 Nadav Har'El wrote: > On Sun, Nov 28, 2021 at 3:15 PM Waldek Kozaczuk <jwkoz...@gmail.com> > wrote: > >> As Nadav noted when reviewing my patch to hide/expose some libc and other >> libraries related symbols, some of those defined in the bsd/ part of the >> tree which originate from FreeBSD, may not necessarily "do" what their >> Linux equivalent "do" even though their share the same name. > > > On one hand, I agree - we have entire directories, like bsd/, where > nothing in there is supposed to be a glibc ABI so we don't need to > advertise. > > On the other hand, I worry what will happen if later want to go more into > the direction of a "modular" kernel, where pieces of the kernel are separe > shared objects and loaded separately. If we ever want to do that, it is > quite possible that some of these symbols from one shared object should be > visible to other shared objects - but not to the application. I'm worried > maybe the "hidden" mechanism will not be delicate enough. > > Maybe we will need something more delicate than just "hidden" (I'm afraid > I don't remember enough about the dynamic linker to recommend something > specific): We will need some symbols to be exported by the kernel or pieces > of it compiled as shared objects, but change the dynamic linker to make > certain symbols visible only to specific shared objects (i.e., other kernel > pieces) and not others (i.e., user application). > > Of course, we don't have to do it now. > > > >> Since then I have sent new version of the patch that would hide all these >> symbols BUT only if we enable hiding symbols in kernel which will be an >> optional build mechanism feature. But I wonder if we should hide those >> symbols proactively no matter what? >> >> Here are the symbols: >> >> - inet_aton, inet_ntoa, inet_ntoa_r - this is most serious one >> actually because on one hand we have those implemented in >> bsd/sys/libkern/[inet_aton.c, inet_ntoa.c] and we also have the musl >> versions in musl_1.1.24/src/network/[inet_aton.c, inet_ntoa.c] with __ >> version which then have aliases defined for those. I am afraid in the end >> we are exposing the FreeBSD versions of these 3 functions not the musl >> ones >> as we should. >> - mtx_lock and related mtx_* ones which are defined and used >> internally in bsd/ subtree and happen to collide with C11 mtx_* symbols >> (see https://en.cppreference.com/w/c/thread) >> - some symbols that are part of libbsd.so library on Linux (see >> https://gitlab.freedesktop.org/libbsd/libbsd) because any app that >> depends on libbsd.so will see OSv version (should it?): >> - >> - arc4random >> - MD5Final >> - MD5Init >> - MD5Update >> - RPC related xdr_* functions - they may not have same implementation >> os the thier Linux counterpart >> >> > Good list. > > >> What do you think? >> Waldek >> >> -- >> You received this message because you are subscribed to the Google Groups >> "OSv Development" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to osv-dev+u...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/osv-dev/7ef8c6b1-2201-48c3-a606-2dca3bc37335n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/osv-dev/7ef8c6b1-2201-48c3-a606-2dca3bc37335n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/fc44afdf-410d-4bcd-89d8-fc17dd731024n%40googlegroups.com.
