linux-kernel - Re: [PATCH v2] timekeeping: contribute wall clock to rng on time change

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]

Message-ID: <YrS2jtI+mt99AOz1@sol.localdomain>
Date:   Thu, 23 Jun 2022 11:53:02 -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 Mailing List <linux-crypto@...r.kernel.org>,
        stable@...r.kernel.org
Subject: Re: [PATCH v2] timekeeping: contribute wall clock to rng on time
 change

On Thu, Jun 23, 2022 at 08:05:55PM +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>
> ---
>  kernel/time/timekeeping.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> index 8e4b3c32fcf9..89b894b3ede8 100644
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -23,6 +23,7 @@
>  #include <linux/pvclock_gtod.h>
>  #include <linux/compiler.h>
>  #include <linux/audit.h>
> +#include <linux/random.h>
>  
>  #include "tick-internal.h"
>  #include "ntp_internal.h"
> @@ -1331,6 +1332,8 @@ int do_settimeofday64(const struct timespec64 *ts)
>  		goto out;
>  	}
>  
> +	add_device_randomness(&ts, sizeof(ts));
> +
>  	tk_set_wall_to_mono(tk, timespec64_sub(tk->wall_to_monotonic, ts_delta));

This is now nested inside:

	raw_spin_lock_irqsave(&timekeeper_lock, flags);
	write_seqcount_begin(&tk_core.seq);

Could there be a deadlock if random_get_entropy() in add_device_randomness()
falls back to reading the monotonic clock?

- Eric