3 ms·

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

• viraptor 7y ago
  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 https://wiki.qemu.org/Features/VirtIORNG but as far as I know AWS does not support it yet.
  • mehrdadn 7y ago
    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.
    • viraptor 7y ago
      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.
      • mehrdadn 7y ago
        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.
        • viraptor 7y ago
          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)
      • loeg 7y ago
        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.
        • viraptor 7y ago
          Sure. Same applies to CPUs and rdrand... yet here we are.
          • loeg 7y ago
            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.
  • loeg 7y ago
    "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.
    • viraptor 7y ago
      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)
• loeg 7y ago
  It absolutely could and should! This is called out in like, 2003 in FS&K Fortuna.
• Gibbon1 7y ago
  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.