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: <CAHmME9q6bm_pXer0aVq907-RevtH8nLPH=Uo2UU6gEKU6GaFwA@mail.gmail.com>
Date:   Wed, 16 Feb 2022 21:58:14 +0100
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Jann Horn <jannh@...gle.com>
Cc:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Andy Lutomirski <luto@...capital.net>,
        Boqun Feng <boqun.feng@...il.com>,
        Will Deacon <will@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Waiman Long <longman@...hat.com>,
        Sultan Alsawaf <sultan@...neltoast.com>,
        "Theodore Ts'o" <tytso@....edu>, Andy Lutomirski <luto@...nel.org>,
        Jonathan Neuschäfer <j.neuschaefer@....net>,
        LKML <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v3] random: remove batched entropy locking

On Wed, Feb 16, 2022 at 9:01 PM Jann Horn <jannh@...gle.com> wrote:
>
> On Fri, Feb 4, 2022 at 4:57 PM Sebastian Andrzej Siewior
> <bigeasy@...utronix.de> wrote:
> > On 2022-02-04 16:51:42 [+0100], Jason A. Donenfeld wrote:
> > > index 455615ac169a..3e54b90a3ff8 100644
> > > --- a/drivers/char/random.c
> > > +++ b/drivers/char/random.c
> > > @@ -1759,41 +1762,54 @@ u64 get_random_u64(void)
> > >       unsigned long flags;
> > >       struct batched_entropy *batch;
> > >       static void *previous;
> > > +     int next_gen;
> > >
> > >       warn_unseeded_randomness(&previous);
> > >
> > > -     batch = raw_cpu_ptr(&batched_entropy_u64);
> > > -     spin_lock_irqsave(&batch->batch_lock, flags);
> > > -     if (batch->position % ARRAY_SIZE(batch->entropy_u64) == 0) {
> > > +     batch = this_cpu_ptr(&batched_entropy_u64);
> > > +     local_lock_irqsave(&batch->lock, flags);
> >
> > Does this compile and work? From the looks of it, this should be:
> >
> >         local_lock_irqsave(&batched_entropy_u64.lock, flags);
> >         batch = this_cpu_ptr(&batched_entropy_u64);
> >
> > and we could do s/this_cpu_ptr/raw_cpu_ptr/
>
> Why raw_cpu_ptr? include/linux/percpu-defs.h says about raw_*() operations:
>
>  * Operations for contexts where we do not want to do any checks for
>  * preemptions.  Unless strictly necessary, always use [__]this_cpu_*()
>  * instead.
>
> So when I see a raw_*() percpu thing, I read it as "it is expected
> that we can migrate after this point (or we're in some really weird
> context where the normal context check doesn't work)". Is that
> incorrect?

If it says "contexts where we do not want to do any checks for
preemptions", then that would apply here I would think? We're taking a
local lock, which means afterwards there are no preemptions. For
context, the code that got committed after Sebastian's final review
is:

        local_lock_irqsave(&batched_entropy_u32.lock, flags);
        batch = raw_cpu_ptr(&batched_entropy_u32);

However, I think most other code uses this_cpu_ptr() instead? So not sure.

Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ