[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHmME9r-wTkNGVj0sBOM5LVY=jdAw99gne-1g-mwjBnk3q7VqQ@mail.gmail.com>
Date: Fri, 24 Jun 2022 15:04:19 +0200
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: "Maciej W. Rozycki" <macro@...am.me.uk>
Cc: LKML <linux-kernel@...r.kernel.org>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Arnd Bergmann <arnd@...db.de>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>
Subject: Re: [PATCH v6 09/17] mips: use fallback for random_get_entropy()
instead of just c0 random
Hey Maciej,
On Wed, Apr 27, 2022 at 3:29 AM Jason A. Donenfeld <Jason@...c4.com> wrote:
>
> Hey Maciej,
>
> On Tue, Apr 26, 2022 at 09:28:39PM +0100, Maciej W. Rozycki wrote:
> > On Sat, 23 Apr 2022, Jason A. Donenfeld wrote:
> >
> > > diff --git a/arch/mips/include/asm/timex.h b/arch/mips/include/asm/timex.h
> > > index b05bb70a2e46..8cfa485d19e6 100644
> > > --- a/arch/mips/include/asm/timex.h
> > > +++ b/arch/mips/include/asm/timex.h
> > [...]
> > > + if (cpu_has_3kex)
> > > + c0_random = (read_c0_random() >> 8) & 0x3f;
> >
> > Hmm, I wonder whether we do need to mask the contents of the register out
> > here given that known implementations return zeros in reserved bits. Even
> > though R3000 documentation I have access to makes no guarantee as to the
> > values of the reserved bits here I think we can safely proceed according
> > to what systems we do actually support do (even though it only saves one
> > instruction).
> >
> > > else
> > > - return 0; /* no usable register */
> > > + c0_random = read_c0_random() & 0x3f;
> >
> > Here the architecture guarantees unused bits to be zero, but the number
> > of them varies between implementations. However we'll only ever use this
> > leg for the R4000/R4400 processors, which have 48 TLB entries, and for the
> > Ingenic XBurst cores, which I have now verified in documentation (which
> > user-reported dumps from /proc/cpuinfo are consistent with) that have 32
> > TLB entries. So I think this mask operation can go as well.
> >
> > I guess these updates can be made with a follow-up change though.
>
> There is lots of optimization potential on a few fronts we've identified
> in this thread. Let's save these for a follow-up. I'd rather this
> initial one be at least somewhat simple, so that as it gets optimized,
> it'll be easy to handle regressions. Also, it probably makes sense for
> you to send the patches for these, since you have both the hardware
> chops and the hardware itself to assess these ideas. I am interested in
> the topic though, so please do CC me.
Everything has been upstream for a little while now, which means
development of this can move back to the proper MIPS tree like normal.
Did you want to submit some optimizations? Would be happy to look at
whatever you have in mind.
Jason
Powered by blists - more mailing lists