Closed Bug 489811 Opened 15 years ago Closed 15 years ago

RNG_SystemInfoForRNG called twice by nsc_CommonInitialize

Categories

(NSS :: Libraries, defect, P2)

defect

Tracking

(status1.9.2 beta1-fixed)

RESOLVED FIXED
3.12.3.1
Tracking Status
status1.9.2 --- beta1-fixed

People

(Reporter: neil, Assigned: nelson)

References

Details

(Keywords: verified1.9.1.1, Whiteboard: FIPS SUN_WANTS)

Attachments

(1 file)

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

Bug 466756 comment #99
From time to time I was running in to a slow script warning in the login manager code which turned out to be caused by trying to get the pk11tokendb service, which needed to initialise NSS, which was enumerating my IE cache. Clearing my IE cache resolved my problem.

Bug 466756 comment #100 From Nelson Bolyard (:MisterSSL)
Neil, yes, the code now limits the depth into the directories into which
it will descend looking for files.  Look for "maxDepth" in the code.

Perhaps we also need a limit on the number of files and/or immediate 
subdirectories of a single directory through which we will search.

Bug 466756 comment #103
All Temporary Internet Files are stored at the same depth:
%USERPROFILE%\Local Settings\Temporary Internet Files\Content.IE5\<salt>\<file>

For some reason I now see the scan happening four times (as recorded by printf()s I've added to EnumSystemFiles).

Bug 466756 comment #105
Seems to be caused by this block of code from pkcs11.c:

    rv = RNG_RNGInit();         /* initialize random number generator */
    if (rv != SECSuccess) {
    crv = CKR_DEVICE_ERROR;
    return crv;
    }
    rv = BL_Init();             /* initialize freebl engine */
    if (rv != SECSuccess) {
    crv = CKR_DEVICE_ERROR;
    return crv;
    }
    RNG_SystemInfoForRNG();

RNG_RNGInit() already calls RNG_SystemInfoForRNG() (via PR_CallOnce no less)!

>freebl3!RNG_SystemInfoForRNG(void)+0x223 [security\nss\lib\freebl\win_rand.c @ 358]
>freebl3!rng_init(void)+0x14c [security\nss\lib\freebl\drbg.c @ 420]
>nspr4!PR_CallOnce(struct PRCallOnceType * once = 0x0b938cf8, <function> * func = 0x0b8e73a0)+0x35 [nsprpub\pr\src\misc\prinit.c @ 808]
>freebl3!RNG_RNGInit(void)+0x13 [security\nss\lib\freebl\drbg.c @ 462]
>softokn3!RNG_RNGInit(void)+0x25 [security\nss\lib\freebl\loader.c @ 835]
>softokn3!nsc_CommonInitialize(void * pReserved = 0x0012d7d4, int isFIPS = 0)+0x57 [security\nss\lib\softoken\pkcs11.c @ 2582]

>freebl3!RNG_SystemInfoForRNG(void)+0x223 [security\nss\lib\freebl\win_rand.c @ 358]
>softokn3!RNG_SystemInfoForRNG(void)+0x22 [security\nss\lib\freebl\loader.c @ 1570]
>softokn3!nsc_CommonInitialize(void * pReserved = 0x0012d7d4, int isFIPS = 0)+0x91 [security\nss\lib\softoken\pkcs11.c @ 2602]
Assignee: nobody → rrelyea
Whiteboard: FIPS
Priority: -- → P2
Doug, is this an issue for Fennec?  (I assume it is, but ...)
Summary: Temporary Internet Files scanning can get slow → RNG_SystemInfoForRNG called twice by nsc_CommonInitialize
Whiteboard: FIPS → FIPS SUN_WANTS
Target Milestone: --- → 3.12.4
This appears to be the obvious solution.  Bob, please review.
Assignee: rrelyea → nelson
Status: NEW → ASSIGNED
Attachment #381652 - Flags: review?(rrelyea)
OS: Windows XP → All
Hardware: x86 → All
Whiteboard: FIPS SUN_WANTS → FIPS SUN_WANTS [Awaiting Softoken's Thaw]
Whiteboard: FIPS SUN_WANTS [Awaiting Softoken's Thaw] → FIPS SUN_WANTS
Comment on attachment 381652 [details] [diff] [review]
Patch v1 for NSS Trunk (checked in)

r+ that's what I was intending to do...

bob
Attachment #381652 - Flags: review?(rrelyea) → review+
Checking in pkcs11.c; new revision: 1.167; previous revision: 1.166
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
This patch was not included in Firefox 3.5 (and isn't even included on mozilla-central yet, AFAICT). I wonder whether this bug could be the cause of some of the startup slowdowns being reported in 3.5:

http://forums.mozillazine.org/viewtopic.php?f=38&t=1326105
Flags: blocking1.9.1.1?
(In reply to comment #5)
> I wonder whether this bug could be the cause of
> some of the startup slowdowns being reported in 3.5:
Note that this patch isn't a complete cure; at best it can only halve Ts.
Flags: blocking1.9.2?
I'm not sure _this_ bug is blocking 1.9.1.1, but some remedy of bug 501605 is... I'll let beltzner decide.
Flags: wanted1.9.1.x+
All the "untested" comments here make me nervous, despite the patch looking pretty simple. Definitely wanted, not sure it blocks 1.9.1.1 ... will come back around.

rrylea/nelson: what's the chance of this doing something untoward?
blocking1.9.1: --- → ?
bug 501605 comment 151 asks for a tag that we can use for Firefox 3.5.1 with this bug?
blocking1.9.1: ? → needed
Flags: blocking1.9.1.1? → blocking1.9.1.1+
Comment on attachment 381652 [details] [diff] [review]
Patch v1 for NSS Trunk (checked in)

This patch was tested before it was committed.
Attachment #381652 - Attachment description: Patch v1 for NSS Trunk (untested) → Patch v1 for NSS Trunk (checked in)
Pushed to 1.9.1 only as:

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/d40be78ef515  (including the bug 489811 fix)

Marking this bug fixed1.9.1.1
Keywords: fixed1.9.1.1
Comment on attachment 381652 [details] [diff] [review]
Patch v1 for NSS Trunk (checked in)

blapitest.c has the same RNG_Init, BL_Init, RNG_SystemInfoForRNG
sequence, so it needs a similar patch:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/cmd/bltest/blapitest.c&rev=1.58&mark=3271,3281#3271
I'll file a separate bug about blapitest.  It's just a QA test program, 
never seen by users.  In that program, this bug wastes a little time, but is 
otherwise harmless.
The bug fix is in NSS 3.12.3.1.
Target Milestone: 3.12.4 → 3.12.3.1
blocking1.9.1: needed → ---
Flags: wanted1.9.1.x+
Is this fixed on mozilla-1.9.2 as well? When did the fix land on mozilla-central?
Yes, this is fixed on mozilla-1.9.2.  Kai and I push NSS
CVS tags methodically.  If a tag is in mozilla-1.9.1, it
must have been baked in the less stable Hg repositories.
Thanks, Wan-Teh. Much appreciated. Setting appropriate flags.
Flags: blocking1.9.2? → blocking1.9.2+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: