linux-kernel - Re: [PATCH v6 09/17] mips: use fallback for random_get

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: <YmicjVbkcppfzE1E@zx2c4.com>
Date:   Wed, 27 Apr 2022 03:29:49 +0200
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     "Maciej W. Rozycki" <macro@...am.me.uk>
Cc:     linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
        tglx@...utronix.de, 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 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.

Jason