> 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?

For some hypervisors this is solved in a different way: https://wiki.qemu.org/Features/VirtIORNG but as far as I know AWS does not support it yet.

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)

If you can't trust your cloud provider to give you good boot time entropy you shouldn't host your VMs on them at all.

Sure. Same applies to CPUs and rdrand... yet here we are.

Not all CPUs have rdrand? Yes, trust it on x86 when it is present. Otherwise... Linux runs on a lot of arch that are not x86.

I agree that the LKML fear-mongering over RDRAND is doing more harm than good.

"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)

It absolutely could and should! This is called out in like, 2003 in FS&K Fortuna.

Seems to me that providing a way to either store a random seed or provide a canned one on boot is a bootloader/system problem not a Linux OS problem.