Differential D32478
kern: random: use a spinlock for the reseed lock Authored by kevans on Oct 13 2021, 7:12 AM. Tags None Referenced Files
Details
read_random() will often induce a reseed in fortuna; make the reseed The fX implementation has the same issue in the standard read path with X-NetApp-PR: #69
Diff Detail
Event TimelineComment Actions I don't believe anything should be consuming random in interrupt contexts. Could you elaborate on the scenario / bug? Comment Actions I'll double check tomorrow, but it's some downstream code that's iirc trying to consume random in the net epoch... but I might be crossing memories on that one. It's definitely downstream stuff, at least. :-) Comment Actions OK, without going into too much detail, the downstream code is periodically polling random in what's effectively a swi. Comment Actions Anything else I can do to better elucidate on NetApp's needs? When you say "should be" here, do you consider it a fundamentally bad idea or just that it's not a scenario that should be happening in stock FreeBSD? Comment Actions I meant fundamentally bad idea. Very little work should happen in interrupt context. Taking a global lock and running AES in software is somewhat expensive. Also, I am concerned about the effect — of making this a spinlock — on all the non-SWI code that formerly blocked but would now spin on the lock. Comment Actions Sure, fair enough; I think it's a not-quite-interrupt-context but they treat it as such for 'other reasons', but I don't fully understand the context (it's a bit of an atypical application). But given that:
I'm going to push it back downstream and abandon this, since it's a low-maintenance diff for them to maintain. Thanks! |