Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAHmME9qy0N3BvDo-0jkS+om0N3Yk--ZAyKvSKshzDBzvuoP+UA@mail.gmail.com>
 <20220623180555.1345684-1-Jason@zx2c4.com> <YrS2jtI+mt99AOz1@sol.localdomain>
In-Reply-To: <YrS2jtI+mt99AOz1@sol.localdomain>
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
Date:   Thu, 23 Jun 2022 20:56:14 +0200
Message-ID: <CAHmME9rbOt14sHkPVgb7yysYSXk-eiwzkp9PzPnyO_9HyrmQ3Q@mail.gmail.com>
Subject: Re: [PATCH v2] timekeeping: contribute wall clock to rng on time change
To:     Eric Biggers <ebiggers@kernel.org>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        stable <stable@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Jun 23, 2022 at 8:53 PM Eric Biggers <ebiggers@kernel.org> wrote:
>
> 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@vger.kernel.org
> > Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.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?

Also nice find as the raw_spin_lock itself is problematic on RT,
because add_device_randomness can take a normal one. I'll do some
hoisting.

Jason