Re: nss symbols vs openssl symbols

On 4/16/21 11:12 AM, Thomas Klausner wrote:
> Hi Ryan!
>
> Thanks for the reply.
>
> Bob's reply was quite helpful already with his hint that nothing
> should link against softokn3 or freebl. This was a bug in pkgsrc
> previously, but I fixed it after his message. Nothing in pkgsrc now
> links against either of the two directly. I think I followed all of
> his advice.
>
> nss seems to take great care to be interoperable with openssl. But I
> still don't understand how this works in detail. Perhaps you can shed
> some more light on this to help me debug this problem.
>
> Bob wrote that NSS hides the conflicting symbols through a dynamically
> loaded object and a function table.  I assume this means using
> dlopen(). I'm not sure about the function table.

NSS hides the symbols with shared libraries that only export a curated 
set of public symbols. Each nss shared library has it's own symbol list 
found in {sharedlibname}.def so lib/nss/nss.def lib/util/nssutil.def 
lib/ssl/ssl.def etc.

The NSS build system massages this file to whatever system the OS uses 
to create an use an explicit export list for your shared library.

When you link with NSS, you need to link with the NSS shared library, 
namley libnss3.so libnssutil3.so libssl3.so and libsmime3.so (depending 
on how much of NSS you need). libsoftken3 will be automatically loaded 
by libnss3.so and it in term will automatically load libfreebl* as 
needed. So only the last two are dlopened. You should not link with any 
libnss*.a files, or all bets are off on working with something like openssl.

If you are doing all this and still running into issues, it's likely the 
build system (either your own or the NSS build system) isn't correctly 
processing the .def file for your platform. The command to process the 
.def file is set with the symbol PROCESS_MAP_FILE and is set in your 
{OS}.mk file in nss/coreconf.

Linux, for instance, sets the command as follows:

PROCESS_MAP_FILE = grep -v ';-' $< | \
         sed -e 's,;+,,' -e 's; DATA ;;' -e 's,;;,,' -e 's,;.*,;,' > $@
This removes all the lines with ;- , then removes all occurrences of 
';+',' DATA ',';;', and then all commands '; to the end of the line'

Linux later adds the directive -Wl,-c,$(MAPFILE) to it's shared library 
linking command.

It looks like openBSD has the same processing line as linux, and adds 
-Wl,--version-script,$(MAPFILE) which sounds right to me.

(Some unsupported OSs ignore the MAPFILE, and they could be subject to 
symbol collisions).

bob


>
> I looked at the code a bit and see that HASH_Update calls a function
> indirectly, which in pk11cxt.c is forwarded and finally used in
> pkcs11c.c - which however, then uses the wrong function, the one from
> openssl.
>
> Can you please explain in more detail how the function table works?
> In my case, it seems the wrong MD5_Update function is used when
> openssl is linked into the binary.
>
> Perhaps it's a difference in linker behavior on NetBSD?
>
> As for pkgsrc - I cited the patches in my original email. The whole
> package information is [1], the Makefile contains the flags used when
> compiling and the patches directory the patches used.  If you see what
> the problem is, that'd be very helpful, but I don't think it's
> something that's something obvious any longer.
>
> [1] https://github.com/NetBSD/pkgsrc/tree/trunk/devel/nss
>
> Thanks,
>   Thomas
>

-- 
You received this message because you are subscribed to the Google Groups "[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-tech-crypto/8c271011-93c3-529f-6e08-deff68d9bb32%40redhat.com.