When the issue came up with the OpenSSH hang, I failed to be convinced why this should be a problem at all. Perhaps someone can enlighten me after reading my thoughts in the thread there? https://news.ycombinator.com/item?id=20463586
> Sounds like the real problem is some part of the system can't be bothered to persist its state.
That's just a special case when you do a reboot. There are many cases where the system starts and there's either no previous state, or the previous state is explicitly killed to prevent sharing.
For example a lot of AWS instances will boot once once in their lifetime, and will do that from a shared AMI. You can't reuse a shared random seed in that case or getting random values from one VM would allow you to predict new values on another.
So persisting the state will help desktop users, but that's addressing only a specific version of this problem, not solving it for everyone.
> You can't reuse a shared random seed in that case or getting random values from one VM would allow you to predict new values on another.
Why can't AWS seed you with a random number before giving you control? In fact does it not do that already? If it doesn't, either I'm surprised, or I don't understand why it's not possible.
AWS does not touch your drives itself. (Apart from what you configure) It would be a drama on its own if they tried. And even if they did try, what about encrypted partitions, filesystems which they don't support, systems configured for a different seed location, etc?
What do you mean they don't touch your drive? Do they just give you a blank disk with no bootable OS (in which case, doesn't that mean you yourself are now responsible for seeding when you install the OS)? I know whenever I've dealt with a cloud VM, it's come with an OS set up by the vendor, but if it's not, then the OS installer needs to seed the image. So my point is, whoever sets up the system seems responsible for seeding it. If AWS gives me a VM, I expect it to come seeded with a unique number, and of course I don't expect them to touch anything after giving me control. Anything I set up beyond that is my responsibility to seed properly. I don't understand why this would be a drama.
They give you a VM with an image you choose. It may be an image you prepare or one they provide. But no modifications to the file contents since creation.
Drama would come from the same place as "we shouldn't trust rdrand". That's still avoiding the issue of: sometimes can't write that seed in some configurations.
Yeah, so while creating it, they seed it. If you don't trust that, you install another OS yourself, with a kernel your trust, and seed it yourself when installing, from whatever sources of randomness you want. I fail to see why this wouldn't work.
They can't seed it while creating the AMI. If they did that, everyone would share the initial seed and I could boot up the published image, run the generator with that seed, and be able to predict (for example) what ssh key your server will have.
(Or if you meant creating the VM, as explained before they can't do that for encrypted volumes for example)
"EFI variables." Or shove it in an ACPI table. Or any of the myriad other ways BIOSes communicate data to the operating system via RAM rather than disk image. Edit: or the virtio-rng interface, as another commenter reminds me.
Yup. There are ways to do that without a disk seed. They need to be actually implemented on both sides though, so some standardisation is needed. (Or at least one popular solution)
