1854288 - Preload NSS's dynamically loaded dependent libraries in the fork server

Status: RESOLVED WONTFIX

(Core :: IPC, task)

Description

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

For bug 1840512, we're trying to avoid different processes within Firefox having incompatible versions of resources they load, even if there's been a software update since the application was started. The fork server inherently takes care of that for the executable and libxul, and we can preload other dependencies before forking.

And this is where NSS comes in. It loads a PKCS#11 module, libsoftokn3, which provides the implementations of the usual cryptographic algorithms. In turn, it then dynamically loads another library generically called freebl to get the actual implementations, which could depend on detected CPU features; this capability was historically used on architectures like SPARC (and may still be?), while on x86 there is only one version of the library but it's still dynamically loaded. Also, apparently for FIPS-140-related reasons, the library (when it's not subarch-dependent) was originally libfreebl3 but now it's libfreeblpriv3 instead, at least on some OSes. (That's my understanding of the situation; hopefully I haven't misrepresented it too much here.)

Complicating things yet further, Firefox can use either a bundled NSS or one built separately by an external package system. So, even if we change our own build of NSS to statically link these dependencies (see bug 1543545), that may not help in all cases.

One approach, which I've written a patch for, is to dlopen these libraries before forking. This raises problems with the freebl naming: we probably want libfreeblpriv3 but it's possible we might want libfreebl3 (or some other name?) instead, depending on build configuration that we might not be able to easily determine (if NSS was built separately). Loading both of them also raises some concerns: if we load the libfreeblpriv3 that was built from in-tree source and the libfreebl3 from an OS package (for example), could one of them shadow the other's symbols?

I considered trying to get softokn to load freebl itself, but it looks like that's only possible via initializing all of softokn, which may be excessively heavyweight here, and seems to do some kind of RNG initialization which could be problematic before forking (note that the sandbox replaces fork and doesn't currently support pthread_atfork hooks).

Two more possibilities:

• Have the parent process use dl_iterate_phdr to look for an object whose soname contains freebl and pass that to the forkserver, assuming that NSS has been initialized early enough.

• Ignore this issue completely, and assume that softokn being a PKCS#11 module means that version skew won't be a significant issue. I don't know how reasonable that is.

Comment 1

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Kai, do you know whether we need to be concerned about version skew between libnss3 and libsoftokn3? Or do you know who else I could ask?

Comment 2

[Kai Engert [:KaiE:]]

Jed, those interactions are indeed very complex. It was primarily implemented by Bob Relyea.

I'm currently not a maintainer of NSS. Besides Bob, you could reach out Mozilla's NSS team.

Comment 3

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Redirecting needinfo per comment #2.

Comment 4

[Robert Relyea]

Logically NSS can use other versions of softoken, and we've used that in past when we locked doen softoken to a FIPS validated version, If NSS loads an old softoken, then some features may not work.

Anyway, one way you can force the loading is to call NSS_Init, and NSS_Finalize. You can just call NSS_NoDB_Init() and NSS_Finalize and it will initialize without opening the database (so you don't need to get access to the profile). NSS_Finalize doesn't unload the libraries so they should be there at fork time.

NOTE: softoken isn't the only library NSS dlopens. softoken is just one of possibly many PKCS #11 modules that get loaded (builtins, for instance, or user installed smart cards). If you call NSS_Init with the actual database, NSS will load all the PKCS #11 modules as well.

bob

Comment 5

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Thanks for the info. It sounds like version skew between NSS and softokn isn't a problem, so this bug doesn't need to be fixed.

But, if it turns out that we do need to do something about later on, I believe that child processes always use NSS_NoDB_Init (see here), so that may simplify things.