5 ms·

but it doesn't, so it isn't a solution

by Kubuxu 5y ago

eternityforest 5y ago
I'm sure the kernel devs can make it happen, I don't see why VM devs wouldn't want to add this if thry saw clear demand. They probably couldn't just use RDRAND and the like since Linux doesn't seem to trust that though, so the API could be tricky.
- zamadatix 5y ago
  Being able to have a solution isn't enough, even having a solution in hand people could switch to isn't enough. You need to actually show no currently working setups are going to break as a result of the change, regardless what those setups could do to avoid breaking after the change.
  - hypertele-Xii 5y ago
    How exactly can existing code break if you change randomness? It's already random! Changing random from random to random shouldn't make a difference.
    - sundarurfriend 5y ago
      "break" in this case means made less random/more prone to malicious attacks, hence made less secure. The code won't break in the sense of visibly failing; it'd just silently switch to being less correct and more vulnerable - which is arguably worse.
    - wutbrodo 5y ago
      There's an example described in the article, unless I'm misunderstanding this thread. It doesn't change the output distribution, but rather the behavior around the interface, causing certain users of the old interface to block forever on the new.
loeg 5y ago
No, that's wrong. There are actually a number of ways VM hosts can and do expose host entropy to guests. On x86, for example, they can allow the guest to use RDRAND/RDSEED. On anything with PCI devices, there's VirtIORNG: https://wiki.qemu.org/Features/VirtIORNG https://wiki.qemu.org/Features/VirtIORNG . VM hypervisors absolutely implement this service, or similar guest services, and hosting providers enable them.
- ufo 5y ago
  Sure. But the issue here is when these features are not used correcly. For non-vms, linux uses cpu jitter as a fallback if the random device is missing or misconfigured. But for vms, that fallback doesn't work as well.

but it doesn't, so it isn't a solution

by Kubuxu 5y ago

but it doesn't, so it isn't a solution

I'm sure the kernel devs can make it happen, I don't see why VM devs wouldn't want to add this if thry saw clear demand. They probably couldn't just use RDRAND and the like since Linux doesn't seem to trust that though, so the API could be tricky.

zamadatix 5y ago
Being able to have a solution isn't enough, even having a solution in hand people could switch to isn't enough. You need to actually show no currently working setups are going to break as a result of the change, regardless what those setups could do to avoid breaking after the change.
- hypertele-Xii 5y ago
  How exactly can existing code break if you change randomness? It's already random! Changing random from random to random shouldn't make a difference.
  - sundarurfriend 5y ago
    "break" in this case means made less random/more prone to malicious attacks, hence made less secure. The code won't break in the sense of visibly failing; it'd just silently switch to being less correct and more vulnerable - which is arguably worse.
  - wutbrodo 5y ago
    There's an example described in the article, unless I'm misunderstanding this thread. It doesn't change the output distribution, but rather the behavior around the interface, causing certain users of the old interface to block forever on the new.

loeg 5y ago

No, that's wrong. There are actually a number of ways VM hosts can and do expose host entropy to guests. On x86, for example, they can allow the guest to use RDRAND/RDSEED. On anything with PCI devices, there's VirtIORNG: https://wiki.qemu.org/Features/VirtIORNG https://wiki.qemu.org/Features/VirtIORNG . VM hypervisors absolutely implement this service, or similar guest services, and hosting providers enable them.

ufo 5y ago
Sure. But the issue here is when these features are not used correcly. For non-vms, linux uses cpu jitter as a fallback if the random device is missing or misconfigured. But for vms, that fallback doesn't work as well.