Pitchforks for RDSEED

Posted Feb 9, 2024 10:42 UTC (Fri) by taladar (subscriber, #68407)
In reply to: Pitchforks for RDSEED by dullfire
Parent article: Pitchforks for RDSEED

I don't think you can calculate the probability of repeated failures in the retry loop like that. It is not as if they are independent events. If entropy is exhausted in one RDSEED instruction it will not be just as likely to be restored to a usable level if the next CPU instruction is another RDSEED as it would be for a random RDSEED occurring after many other instructions.

Pitchforks for RDSEED

Posted Feb 9, 2024 13:58 UTC (Fri) by dullfire (guest, #111432) [Link]

I was actually just thinking about that.

I think you MIGHT be able to maintain that probably format, if there's a change (possibly delays) you can make to make the next RDSEED mostly unrelated to the first. Also note that isn't not necessary to try accounting for things like another thread attempting to drain entropy (since that would be an attack, in which case a warning, or panic if panic_on_warn, is a perfectly sane response)

IF that's possible[0], then you just need to pick a loop count that makes the likelyhood of successive failures unreasonably small.

Although, honestly I think the sanest course of action would simply to dedicated hardware (that requires privilege to access to use) in the non-cloud case. In my humble opinion the whole notion of confidential cloud compute is intractable, so I have no proposed solutions for it .

[0] I think it should be, but have no proof.