711032 - Defer certificate validation configuration so that it doesn't occur during startup (during nsNSSComponent::Init)

Status: RESOLVED FIXED

(Core :: Security: PSM, enhancement)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

+++ This bug was initially created as a clone of Bug #711014 +++

http://hg.mozilla.org/mozilla-central/annotate/beac16509534/security/manager/ssl/src/nsNSSComponent.cpp#l1753

The following calls can be deferred to the time that the first time certificate validation is done:

setValidationOptions(mPrefBranch);
RegisterMyOCSPAIAInfoCallback();
mHttpForNSS.initTable();
mHttpForNSS.registerHttpClient();

InstallLoadableRoots();

In addition, we can initialize NSS with NSS_NoDB_Init, and then load the certificate database at the same time we do other cert validation configuration. Besides executing less code (and thus touching fewer code pages) during startup, we would avoid reading/parsing the database.

This is less likely to be a win compared to bug 711014 or bug 711015 since CERT_* and OCSP_* functions live in libnss along with NSS_NoDB_Init(). Accordingly, we may have to move the CERT_* and OCSP_* functions out of libnss (in a NSS/libraries bug) for this to have maximum positive impact.

Comment 1

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Note that nss_Init--called by NSS_Init() and NSS_NoDB_Init--calls (at least) the following certificate-validation-related functions:

	cert_CreateSubjectKeyIDHashTable();

	pkixError = PKIX_Initialize
	    (PKIX_FALSE, PKIX_MAJOR_VERSION, PKIX_MINOR_VERSION,
	    PKIX_MINOR_VERSION, &actualMinorVersion, &plContext);

We would have to write a new variant of NSS_Init() to completely eliminate any dependency on cert validation code in PSM during startup.

Comment 2

[Sean Leonard]

Certain unorganized notes on how to make NSS/PSM startup much faster:

Much to my surprise, firefox.exe (Firefox 9.0.1) only dynamically links to kernel32.dll, user32.dll, and msvcr80.dll. Mac OS X: firefox-bin only links to libmozutils.dylib, libstdc++.6.dylib, and the standard Mac OS X frameworks (Cocoa, Exceptionhandling, CoreFoundation, libSystem.B.dylib).

This could be a performance problem. If the Firefox executable linked (for example) to nss3.dll, nspr4.dll, xpcom.dll, and so forth, OS components could figure out how to lay out the memory much faster, and could precompute the runtime loader tables.

Right when firefox.exe starts up, it ought to spawn a worker thread that calls NSS_Init(), before even XPCOM loads. A global lock should be initialized and set.

In the PSM nsNSSComponent::Init() function, the code ought to wait on the lock so that NSS finishes initializing in the other thread.

Simple as that. On a multicore system, NSS can take its time to load and initialize any crypto tokens, but this will occupy another core while the rest of Firefox boots itself up. It takes quite awhile for other subsystems of Firefox to initialize and those subsystems have no dependence on NSS or PSM.

Comment 3

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Sean Leonard from comment #2)
> Right when firefox.exe starts up, it ought to spawn a worker thread that
> calls NSS_Init(), before even XPCOM loads. A global lock should be
> initialized and set.
> 
> In the PSM nsNSSComponent::Init() function, the code ought to wait on the
> lock so that NSS finishes initializing in the other thread.

I filed bug 724059 regarding your linkage suggestions. We cannot do the above before XPCOM loads, because we need to know the profile directory which isn't available until other XPCOM components have loaded. But, really, we shouldn't be doing the disk I/O for reading the certificate database, key database, the security module database, or the root built-in module DLL during startup at all, even on a background thread, because other parts of Gecko (e.g. the disk cache) need to do more urgent I/O.

Comment 4

[Sean Leonard]

Ok.

When you say "we cannot do the above before XPCOM loads", which thing are you referring to? You mean NSS_Init, because you need the profile directory, right? So, you need to wait for the profile-after-change event, or something else?

It could be slightly before the profile-after-change event; specifically, the kickoff can be hardcoded to immediately after the profile directory is known. Since XPCOM is around, NSPR is also around so you don't need to wait for that.


Re: the "more urgent I/O". Ok, I can understand that; however, if you lower the worker thread's priority, the OS can take that into consideration when doing disk I/O. Usually, disk I/O priority is based on the thread I/O priority. PRThreadPriority is the NSPR type to use. It can be set as part of PR_CreateThread.

In general, if Firefox itself is starting up, it is probably going to want to check for updates at https://*.mozilla.org fairly early. This may not happen literally during process startup but I think it is scheduled to happen reasonably quickly. If the user sets their homepage to somewhere like facebook.com, gmail.com, or twitter.com (not unreasonable; facebook gets 1/5 of all page views nowadays), they are going to exercise SSL, which in turn is going to exercise NSS. At a minimum, NSS needs to see the built-in root database and the non-root certificate database for any per-site overrides.

Comment 5

[Dana Keeler (she/her) [:keeler]]

Most of the code mentioned in comment 0 has been removed or taken care of in bug 1372656. I don't think we can run setValidationOptions off the main thread since it uses prefs. I spent a long time exploring using NSS_NoDB_Init and it's unlikely we'll go that route.