Change Details

The goal of the regularly scheduled save-entropy job is to prevent seed reuse on crash or power loss. To that end, we should actually fsync the newly created data (and its directory entry) out to disk. Similarly, sync directory operations that "rotate" entropy files. PR: 230876

random(4): Attempt to persist entropy promptly The goal of saving entropy in Fortuna is two-fold: (1) to provide early availability of the random device (unblocking) on next boot; and (2), to have known, high-quality entropy available for that initial seed. We know it is high quality because it's output taken from Fortuna. The FS&K paper makes it clear that Fortuna unblocks when enough bits have been input that the output //may// be safely seeded. But they emphasize that the quality of various entropy sources is unknown, and a saved entropy file is essential for both availability and ensuring initial unpredictability. In FreeBSD we persist entropy using two mechanisms: 1. The /etc/rc.d/random shutdown() function, which is used for ordinary shutdowns and reboots; and, 2. A cron job that runs every dozen minutes or so to persist new entropy, in case the system suffers from power loss or a crash (bypassing the ordinary shutdown path). Filesystems are free to cache dirty data indefinitely, with arbitrary flush policy. Fsync must be used to ensure the data is persisted, especially for the cron job save-entropy which is oriented at power loss or crash safety. Ordinary shutdown may not need the fsync because unmount should flush out the dirty entropy file. But it is always possible power loss or crash occurs during the short window after rc.d/random shutdown runs and before the filesystem is unmounted, so the additional fsync there seems harmless. PR: 230876

The goal of the regularly scheduledrandom(4): Attempt to persist entropy promptly The goal of save-ing entropy job isin Fortuna is two-fold: (1) to prevent seedovide early reuse on crash or power loss. To that endavailability of the random device (unblocking) on next boot; and (2), we should actually fsync theto newly created data (and its directory entry) out to diskhave known, high-quality entropy available for that initial seed. We know it is high quality because it's output taken from Fortuna. SimilarlyThe FS&K paper makes it clear that Fortuna unblocks when enough bits have been input that the output //may// be safely seeded. But they emphasize that the quality of various entropy sources is unknown, and a saved entropy file is essential for both availability and ensuring initial unpredictability. In FreeBSD we persist entropy using two mechanisms: 1. The /etc/rc.d/random shutdown() function, which is used for ordinary shutdowns and reboots; and, 2. A cron job that runs every dozen minutes or so to persist new entropy, in case the system suffers from power loss or a crash (bypassing the ordinary shutdown path). Filesystems are free to cache dirty data indefinitely, with arbitrary flush policy. Fsync must be used to ensure the data is persisted, especially for the cron job save-entropy which is oriented at power loss or crash safety. Ordinary shutdown may not need the fsync because unmount should flush out the dirty entropy file. But it is always possible power loss or crash occurs during the short window after rc.d/random shutdown runs and before the filesystem is unmounted, sync directory operaso the additions that "rotate" entropy filesal fsync there seems harmless. PR: 230876