On Thu, Jun 23, 2022 at 06:52:26PM +0200, Jason A. Donenfeld wrote:
The rng's random_init() function contributes the real time to the rng at boot time, so that events can at least start in relation to something particular in the real world. But this clock might not yet be set that point in boot, so nothing is contributed. In addition, the relation between minor clock changes from, say, NTP, and the cycle counter is potentially useful entropic data.
This commit addresses this by mixing in a time stamp on calls to settimeofday and adjtimex. No entropy is credited in doing so, so it doesn't make initialization faster, but it is still useful input to have.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Jason A. Donenfeld Jason@zx2c4.com
Good idea.
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index 8e4b3c32fcf9..ad55da792f13 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c
This doesn't compile:
kernel/time/timekeeping.c: In function ‘do_settimeofday64’: kernel/time/timekeeping.c:1350:9: error: implicit declaration of function ‘add_device_randomness’ [-Werror=implicit-function-declaratio ] 1350 | add_device_randomness(&xt, sizeof(xt)); | ^~~~~~~~~~~~~~~~~~~~~
@@ -1346,6 +1346,9 @@ int do_settimeofday64(const struct timespec64 *ts) if (!ret) audit_tk_injoffset(ts_delta);
- ktime_get_real_ts64(&xt);
- add_device_randomness(&xt, sizeof(xt));
- return ret;
Isn't the new time already available in 'ts'? Is the call to ktime_get_real_ts64() necessary?
} EXPORT_SYMBOL(do_settimeofday64); @@ -2475,6 +2478,9 @@ int do_adjtimex(struct __kernel_timex *txc) ntp_notify_cmos_timer();
- ktime_get_real_ts64(&ts);
- add_device_randomness(&ts, sizeof(ts));
- return ret;
}
adjtimex() actually triggers a gradual adjustment of the clock, rather than setting it immediately. Is there a way to mix in the target time rather than the current time as this does?
- Eric