Pitchforks for RDSEED

Posted Feb 8, 2024 18:27 UTC (Thu) by dullfire (guest, #111432)
Parent article: Pitchforks for RDSEED

> Many systems run with panic_on_warn enabled; on such systems, a warning will cause a system crash. That would turn a random-number-generator failure into a denial-of-service problem.

Sorry but this is a bad statement. The if the system is running with panic_on_warn then the system has explicitly been told to panic (effectively go offline) on a warning event. Which means that it can't be a "denial-of-service" when it is behaving exactly the way the admins[0] requested. Additionally, panic_on_warn turns any ability to generate warnings into a DoS by that definition.

Would you call an admin ssh-ing in running a "sudo reboot" a "denial of service". If so, that makes the term so broad as to be useless.

Further more: If this is occurring after a retry loop of 10 (which, if I did my math right, has less than a 0.001% chance of happening if a 'normal' RDSEED has a failure rate of 30%), then most likely the best case is someone is simply probing you system (or your host) for weaknesses. In the worst case, there's an actual attack in progress. Immediately an panic might be the correct response.

[0] Alternately a non-"admin" managed to control your kernel command line (or equivalent), but if that is the case, you have other, very different, and much worse problems.

panic_on_warn

Posted Feb 8, 2024 18:29 UTC (Thu) by corbet (editor, #1) [Link]

Yes, the system is behaving as configured in that setting. Still, developers need to be (and are) aware that issuing warnings can have that effect in a fairly wide swath of deployed systems and consider warnings carefully.

Pitchforks for RDSEED

Posted Feb 9, 2024 0:08 UTC (Fri) by Jannes (subscriber, #80396) [Link] (1 responses)

I understood this as an *unprivileged* process being able to bring down the entire machine. That's probably not the admin's intention.

A misbehaving app should just crash itself, not bring down the entire kernel and thereby DOSsing all other apps.

Pitchforks for RDSEED

Posted Feb 24, 2024 15:14 UTC (Sat) by DanilaBerezin (guest, #168271) [Link]

But the process isn't bringing down the machine, a failing `RDSEED` -- which is kernel functionality -- is. I think a warning is warranted in this case especially when the only known cause for this is a deliberate attack on the randomness subsystem. If crash on warn is enabled and this warning causes the system to crash, that would be the admins fault.

Pitchforks for RDSEED

Posted Feb 9, 2024 10:42 UTC (Fri) by taladar (subscriber, #68407) [Link] (1 responses)

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.

Pitchforks for RDSEED

Posted Feb 10, 2024 15:26 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

> If this is occurring after a retry loop of 10 (which, if I did my math right, has less than a 0.001% chance of happening if a 'normal' RDSEED has a failure rate of 30%)

That sounds like you're assuming events are independent. I feel like there's some level of dependence when one is right after another (i.e., failures will cluster).