On 10/18/2010 05:06 PM, Brian Smith wrote: > [I cannot participate in any legal discussions now. Please don't ask > me questions about legal stuff.] > > We (Mozilla) are are exploring some approaches to statically link NSS > into Firefox to reduce dynamic linkage overhead caused by the NSS > shared libraries and to allow for whole-program optimization (and dead > code removal) for NSS based on Firefox performance profiles.
Before you spend a lot of time doing so, I think you really want to explore what your really get in benefit. NSS is already split into shared libraries with different functionality in it. I suggest seeing if there may be further benefits for additional splitting. There are several reasons *NOT* to do static linking, you've touched on a few, but there are several others: One's you've mentioned: 1) FIPS strategy. 2) System NSS platforms. There are several others: 3) NSS team support. NSS used to be static libraries. The team has long ago dropped explicit support for static libraries and is very unlikely to pick it up. 4) NSS internal symbols. The NSS team regularly changes internal symbols in our shared libraries. We control what symbols applications use by controlling the symbols exported from these libraries. If you statically bind, you have no warning if you accidentally call one of these internal functions that we later modify. This may lock older versions of FF out of important security fixes (or require someone to spend a significant amount of time backporting a lot of fixes). 5) Some Pluggins use NSS. The access NSS symbols through the shared libraries. Statically linking could make those symbols inaccessible. 6) Static bindings can change they way certain types of initialization works. I can pretty much guarantee that if you statically bind today, you will likely crash on shutdown, probably on some startup cases. 7) Some shared libraries are broken out so that they only get loaded if you need them, like libnssdbm, for instance, would only get loaded if you need to read a legacy database. In your statically linking case it would always get loaded. (Note: Chrome never loads it because chrome has always used the sql database). None of these are show stoppers, if the benefit is great enough, they can be overcome, but the do lead to a pretty big wall. The burden of proof lies in 1) showing that the benefit is great enough. and 2) that same benefit isn't more easily achieved through other means (such as going to shared db -- the benefit of ditching all of libnssdbm is likely to be greater than any benefit you get by dropping some random .o (if any) by statically linking. bob > I am interested in what others think of this approach and what > approach other client software developers are planning to take. I am > also interested in knowing how I can help get reviews of the necessary > patches in a short time frame. I am not an NSS reviewer but I can at > least pre-review patches to save other reviewers time (as I did for > the TLS 1.1/1.2 patches) and I could give such reviews much higher > priority if others respond in kind. I think the case needs to be made that the benefit is worth this. > > Changing the way that NSS (Softoken and FreeBL, in particular) is > linked into Firefox means changing the strategy for FIPS 140 > compliance of the browser, and FIPS 140 compliance is an important > concern. But, the vast majority of our users--and all of our mobile > users--run in normal (non-FIPS) mode and we need to optimize for that > case so that people pay (performance-wise) for FIPS mode only when > they enable FIPS mode--even if that would mean that the FIPS mode > would have more overhead than it has now. This has always been the strategy. FIPS mode is not the optimized path. > The approach outlined below is very similar in spirit to the bypass > mode added to NSS to improve the performance of Sun's NSS-based > products.Basically, we just want NSS to be optimized for clients like > Firefox as much as it is optimized for the server products that use > it, like Nelson mentioned during our lunch meeting. I think this > approach will cause minimal disruption to other products using NSS > while still allowing us to make necessary performance improvements and > size reductions in Firefox. Just so you know, I was never a fan of bypass. The benefit was slight, and we (Red Hat) don't actually turn it on. It was really a marketing ploy, which was necessary because of some server out there. I know of no new NSS products that use it. That being said, I'm ok with trying to do client side optimizations -- within reason -- and without completely gutting our architecture. > > 1. Create a supported configuration of NSPR+NSS (in the NSS CVS trunk) > that that supports static linking with profile-guided optimization > (PGO) and whole-program optimization (WPO). Wan-Teh has already > written patches to do this for Chrome and those patches have been > tweaked by others at Mozilla. But, we need reviewers for the patches > after they are cleaned up. See [1] and [2]. > > 2. Update the NSS source code (primarily in libssl, Softoken, and > FreeBL) to allow us to exclude dead code sections from the build when > the the compiler's WPO cannot remove them automatically (e.g. libssl's > server-side code code when linked into Firefox, the bypass mode code, > and anything in FreeBL/Softoken that isn't actually used by Firefox). How much are you really going to save here? It seems to me that the first thing you need is that number. The second question is "is static linking really the way to get there?". I am very much against huge efforts to save fractions of percent, especially huge efforts that are disruptive to other users of NSS. > > 3. Decouple the release of the FIPS-validated Softoken from the > release of the browser. For example, if we need to ship a version of > Firefox that needs some crypto bits that are in a version of > Softoken/FreeBL that hasn't yet been validated, then we will ship the > release with the newer NSS and provide the FIPS-validated version > afterwards. Put another way, FIPS mode issues won't block Firefox. > (Because of Firefox Sync, we are now always going to have crypto > features that won't work in FIPS mode.) Sigh, ignoring FIPS mode in a feature, is usually a red flag. It means you are handling CSP's where you really shouldn't be. Firefox Sync *CAN* be implemented in FIPS mode, and we should work to make sure that happens. FIPS mode isn't just a check box. If you *CAN'T* work in FIPS mode, it usually means you need to take another look at your architecture. (That doesn't mean you need to ship with FIPS mode, or take any overhead it requires in your base usage, but it does mean if it's not possible to work in FIPS mode, you need to rethink). > > 4. Provide a "FIPS mode" option in Firefox wherein the > statically-linked Softoken and FreeBL are disabled in favor of the use > of a dynamically-loaded FIPS-validated PKCS#11 module. If Softoken is > the FIPS-validated module, then NSPR and NSS must support being loaded > multiple times into the same process (once statically linked, and at > least once dynamically linked). While I don't believe the case for statically binding has even been begun to be made, assuming you successfully make such a case and dealing with the other issues above, In that case, you can still have static NSS with an externally loaded softoken. Your static NSS still needs to load PKCS #11 modules to get token support. That loading can just as easily load and external softoken as well. You don't need to then try to load the rest of NSS. > 5. Add the few missing bits to FreeBL that would be needed to have a > 100% bypass mode (no PKCS#11 usage) in the client part of libssl, and > then remove most/all of the statically-linked copy of Softoken from > Firefox in favor of using the FreeBL interface directly. We would > still support the non-bypass mode specifically for FIPS mode. I have > done some experiments with this and it seems like it doesn't require > much additional code added to FreeBL; I can probably eliminate as much > code as I add. I am *VERY* much against this unless you can show mean *SIGNIFICANT* benefit so such changes. You still need the PKCS #11 layer for token support, so you can't remove code. So you are trying to save a few micro seconds??? Did I explain to you that I thought bypass was a bad idea from the beginning;)? Did I also meantion that I know of no new users of bypass? My target directions would be the eventual removal of bypass once the legacy users no longer exist. As you can see I would not be in favor of expanding bypass. > > 6. Remove the FIPS-validated Softoken from the default Firefox > distribution, and distribute it as part of an add-on. This is not a bad idea in general (even without trying to statically link). > > 7. Use operating-system APIs for client authentication, so that client > certificates and smart cards are stored and managed by the operating > system's APIs and tools. I know there is a PKCS#11 interface to native > OS interfaces in NSS already, but I think we can provide a better > experience for users by just using the native APIs--and probably do so > with little maintenance cost (in NSS) and notably less overhead. Note > that this means we will never support client authentication with > static ECDH/DH encryption keys; we will only support key exchange > mechanisms where the client has to provide a signature. I agree with the first part, but strongly disagree with the second. Please try loading the capi library and tell me where the user interaction can be improved by going directly to the OS. I don't think you can do this without either modifying libssl (which would not likely be taken by the NSS team), or by using the OS for your ssl library itself. > > 8. On platforms where we use the system NSS shared libraries, allow a > configuration where the system NSS libraries are used for client > cert/smartcard support while the built-in static NSS is used for > everything else. This, of course, is 'meets minimum' for any proposal. bob > > Cheers, > Brian > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=534471 > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=561842 >
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
