>> I have an idea for a patch to change _xfer_secondary_pool >> to use extract_buf rather than extract_entropy; is all that >> FIPS stuff needed for purely internal transfers?
> That's not the part of extract_entropy() which is critical. What's > critical is the control over only transfering entropy when there is at > least a certain minimum amount of entropy. This provides the > Yarrow-like avalanche property which is required to provide recovery > after the internal state of the entropy pools have been exposed. I do understand the importance of catastrophic reseeding, but I don't see that implemented in extract_entropy(). Extract_entropy() itself contains a call to xfer_secondary_pool, but that is a no-op in the case I'm considering (when it's called from _xfer_secondary_pool) because in that case, r is the the input_pool, which doesn't have an r->pull pool. The number of bytes transferred is adjusted by account(), but it's only adjusted downward. (If it were adjusted up, that would be a buffer overrun.) Normal reads seem to ask for a reseed equal in size to read itself, which is "ctastrophic" enough. The only *minimum* reseed transfer size I can see is enforced in _xfer_secondary_pool and push_to_pool, which use random_read_wakeup_bits (default 64) as a minimum reseed. (Prehaps increase this?) standards, IMHO.) Now, having said all that, I'll try to avoid embarrassing myself in public again and ask... what am I missing? On other matters... If I play around with getting the entropy locking right, do you have a strong preference for the single-lock or two-lock design? I can't decide which to start with. The latter is an extensive core code change, but I can easily convince myself there are no deadlock issues. That's the one I described with separate adder and extractor locks and code paths, two "amount of entropy ever added" variables, ane one "amont of entropy ever removed". The single-lock design is hopefully less code, but (to me, at least) less obviously deadlock-free. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
