On Tue, Sep 17, 2019 at 09:33:40AM +0200, Martin Steigerwald wrote: > However this again would be burdening users with an issue they should > not have to care about. Unless userspace developers care enough and > manage to take time to fix the issue before updated kernels come to their > systems. Cause again it would be users systems that would not be > working. Just cause kernel and userspace developers did not agree and > chose to fight with each other instead of talking *with* each other. It has nothing to do with fighting at all, it has to do with offering what applications *need* without breaking existing assumptions that make most applications work. And more importantly it involves not silently breaking applications which need good randomness for long lived keys because the breakage will not be visible initially and can hit them hard later. Right now most applications which block in the early stages are only victim of the current situation and their developers possibly didn't understand the possible impacts of lack of entropy (or how real an issue it was). These applications do need to be able to get low-quality random without blocking forever, provided these are not accidently used by those who need security. At some point, just like for any syscall, the doc makes the difference. > At least with killing gdm Systemd may restart it if configured to do so. > But if it doesn't, the user is again stuck with a non working system > until restarting gdm themselves. > > It may still make sense to make the API harder to use, No. What is hard to use is often misused. It must be harder to misuse it, which means it should be easier to correctly use it. The choice of flag names and the emission of warnings definitely helps during the development stage. > but it does not > replace talking with userspace developers and it would need some time to > allow for adapting userspace applications and services. Which is how adding new flags can definitely help even if adoption takes time. By the way in this discussion I am a userspace developer and have been hit several times by libraries switching to getrandom() that silently failed to respond in field. As a userspace developer, I really want to see a solution to this problem. And I'm fine if the kernel decides to kill haproxy for using getrandom() with the old settings, at least users will notice, will complain to me and will update. Willy
