673706 - Review uses of PK11_GenerateRandom on performance-critical threads (main thread, socket thread) to see if it blocks too long (e.g. by doing disk I/O)

Status: NEW

(Core :: Security: PSM, defect, P5)

Description

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

We are not sure if it is possible for PK11_GenerateRandom to block for a significant amount of time. If it can, then we need to ensure it is never called on the main thread, and/or add an explicit re-seeding operation to prevent reseeding from causing this blocking.

Comment 1

[David Dahl :ddahl]

Attachment: gdb session stepping through PK11_GenerateRandom

Just a snippet of a step through of PK11_GenerateRandom, I noticed some pthread activity. I am not sure what it means, just thought it might help. 

In bug 440046 I was crashing at one point and gdb said I should attach to another thread to get the stack, of course, the backtrace was unavailable:(

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

NSS's limit of 2^16 bytes per request is the upper bound on such limits 
required by NIST, in table 2,
http://csrc.nist.gov/publications/nistpubs/800-90/SP800-90revised_March2007.pdf

But note that that limit is the upper bound.  A lower limit would also be acceptable to NIST.  It's easy enough to call this function in a loop to get
more than the limit of bytes, and doind so also affords opportunity to give 
other events a chance.

Comment 3

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

See bug 440046 comment 260.

WebRTC code also has this problem.

We should create a wrapper function for Wan-Teh's suggestion in bug 440046 comment 260.