lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 23 Jun 2022 10:39:09 -0700
From:   Eric Biggers <ebiggers@...nel.org>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-crypto@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] timekeeping: contribute wall clock to rng on time change

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@...r.kernel.org
> Signed-off-by: Jason A. Donenfeld <Jason@...c4.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ