4 ms·
Well, the proper solution for the future would be for the kernel to save and restore a random seed using UEFI variables, a similar firmware mechanism or free sp
by devit 7y ago
Well, the proper solution for the future would be for the kernel to save and restore a random seed using UEFI variables, a similar firmware mechanism or free space in a boot sector or swap partition.
But of course this doesn't solve the problem of newer kernels on existing installations with no such stored seed and that don't pass command line argument telling the kernel where to store the seed.
- ars 7y agoOn those machines the old way works fine, but not all machine even have a place to store this data, on top of that people clone VM instances, and you don't want the same number each time. Read the previous https://news.ycombinator.com/item?id=21114524 https://news.ycombinator.com/item?id=21114524 story for more on the problem space and why what you wrote is not considered enough.
- mlyle 7y ago> Well, the proper solution for the future would be for the kernel to save and restore a random seed using UEFI variables, a similar firmware mechanism or free space in a boot sector or swap partition. This needs to be invalidated before numbers dependent on the seed are used, else you risk attacks where you get someone to generate the same random numbers on consecutive boots. In turn, if you crash during bootup at the wrong time, you're left without a seed.
- devit 7y agoYes, you need to update the seed immediately after reading it and before using it. There is no problem with a crash assuming that the seed write mechanism is crash-safe (which is achievable with block storage, but indeed I'm not sure whether firmware is properly designed and implemented).