4 ms·

But is it really that difficult to seed the image for that first boot? For example, an installation process using an .iso image could, after verifying the .iso

But is it really that difficult to seed the image for that first boot? For example, an installation process using an .iso image could, after verifying the .iso, put a random seed inside the .iso (unpack-modify-pack) as a pre-configuration step. Like an extra preparation step after downloading. New installation = new pre-configuration step, to avoid seed reuse. The previous would apply to VMs and containers and such. For traditional embedded/IoT style devices, the step could be done at the factory when flashing the image. Or maybe there could be a small flash area with the seed as part of the initial flashing procedure. I guess some forms of installation end up being "problematic" to handle (ro root filesystems maybe).

saagarjha 7y ago
> unpack-modify-pack This seems eminently unfeasible for many applications, and it won't work at all for read-only filesystems as you've mentioned.
wahern 7y ago
A VirtIO-RNG driver has been in Linux for over 10 years: https://wiki.qemu.org/Features/VirtIORNG https://wiki.qemu.org/Features/VirtIORNG Randomness in VMs isn't a problem. If VM hypervisors aren't providing VirtIO-RNG, it's still just a quick fix and reboot away. The quickest way to make sure all hypervisors and hosting providers enable VirtIO-RNG, or something similar, is for the kernel to being assuming, loudly, that strong entropy is available at boot time. For embedded stuff SPI RNG chips and similar solutions have been available since forever, not to mention the on-chip sources on most modern ARM and x86 CPUs and SoCs. If a product designer (e.g. embedded device) or solution provider (cloud hosting) chooses to put their trust in RDRAND alone, then that's their choice--Linux shouldn't be second guessing it, or at least allow such a choice to dictate the semantics of its APIs.
- denton-scratch 7y ago
  VirtIO-RNG has not been officially accepted into Xen (it seems to be easier to incorporate into a PV DOMU). If you have RDRAND hardware, you could (I suppose) pipe it's output from DOM0 into an encrypted root terminal session on DOMU, and feed that into the pool. I personally don't want to rely on RDRAND. Unlike a tampered ADD instruction, a tampered RDRAND instruction would appear to be undetectable, even in principle. I wish Intel had given me the raw bits from their DRBG, instead of providing only the whitened stream. Or hell, give me both - but not just an opaque stream.

saagarjha 7y ago

> unpack-modify-pack This seems eminently unfeasible for many applications, and it won't work at all for read-only filesystems as you've mentioned.

wahern 7y ago

A VirtIO-RNG driver has been in Linux for over 10 years: https://wiki.qemu.org/Features/VirtIORNG https://wiki.qemu.org/Features/VirtIORNG Randomness in VMs isn't a problem. If VM hypervisors aren't providing VirtIO-RNG, it's still just a quick fix and reboot away. The quickest way to make sure all hypervisors and hosting providers enable VirtIO-RNG, or something similar, is for the kernel to being assuming, loudly, that strong entropy is available at boot time. For embedded stuff SPI RNG chips and similar solutions have been available since forever, not to mention the on-chip sources on most modern ARM and x86 CPUs and SoCs. If a product designer (e.g. embedded device) or solution provider (cloud hosting) chooses to put their trust in RDRAND alone, then that's their choice--Linux shouldn't be second guessing it, or at least allow such a choice to dictate the semantics of its APIs.

denton-scratch 7y ago
VirtIO-RNG has not been officially accepted into Xen (it seems to be easier to incorporate into a PV DOMU). If you have RDRAND hardware, you could (I suppose) pipe it's output from DOM0 into an encrypted root terminal session on DOMU, and feed that into the pool. I personally don't want to rely on RDRAND. Unlike a tampered ADD instruction, a tampered RDRAND instruction would appear to be undetectable, even in principle. I wish Intel had given me the raw bits from their DRBG, instead of providing only the whitened stream. Or hell, give me both - but not just an opaque stream.