On Mon, 14 Feb 2022, Jason A. Donenfeld wrote:
>
> So the only systems we're actually talking about without a good cycle
> counter are non-Amiga m68k? If so, that'd be a pretty terrific finding.
> It'd mean that this idea can move forward, and we only need to worry
> about some m68k museum pieces with misconfigured userspaces...
>
A processor cycle counter is helpful when mounting a timing attack but my
museum pieces don't suffer from that problem.
Also, they are and always were immune from spectre, meltdown etc.
You misrepresent those secure hardware designs as being problematic, just
because of some bad advice on some random blogs about RNG API usage.
Do you have a phone that no longer gets updates from its vendor? Have you
tried patching it?
Your insecure museum pieces are the real problem, not my secure ones.
On Sat, Feb 12, 2022 at 06:05:54PM -0500, Joshua Kinard wrote:
> On 2/11/2022 16:07, Jason A. Donenfeld wrote:
> > This is very much an RFC patch, or maybe even an RFG -- request for
> > grumbles. This topic has come up a million times, and usually doesn't go
> > anywhere. This time I thought I'd bring it up with a slightly narrower
> > focus. Before you read further, realize that I do not intend to merge
> > this without there being an appropriate amount of consensus for it and
> > discussion about it.
> >
> > Ever since Linus' 50ee7529ec45 ("random: try to actively add entropy
> > rather than passively wait for it"), the RNG does a haveged-style jitter
> > dance around the scheduler, in order to produce entropy (and credit it)
> > for the case when we're stuck in wait_for_random_bytes(). How ever you
> > feel about the Linus Jitter Dance is beside the point: it's been there
> > for three years and usually gets the RNG initialized in a second or so.
> >
What about the case where a small amount of entropy is avalable?
> >
> > As a matter of fact, this is what happens currently when people use
> > getrandom(2).
> >
> > So, given that the kernel has grown this mechanism for seeding itself
> > from nothing, and that this procedure happens pretty fast, maybe there's
> > no point any longer in having /dev/urandom give insecure bytes. In the
> > past we didn't want the boot process to deadlock, which was
> > understandable. But now, in the worst case, a second goes by, and the
> > problem is resolved. It seems like maybe we're finally at a point when
> > we can get rid of the infamous "urandom read hole".
> >
Why not keep the distinction between /dev/random and /dev/urandom when a
good entropy source is not avalable?
> >
> > Maybe. And this is why this is a request for grumbles patch: the Linus
> > Jitter Dance relies on random_get_entropy() returning a cycle counter
> > value. The first lines of try_to_generate_entropy() are:
> >
> > stack.now = random_get_entropy();
> > /* Slow counter - or none. Don't even bother */
> > if (stack.now == random_get_entropy())
> > return;
> >
> > So it would appear that what seemed initially like a panacea does not in
> > fact work everywhere. Where doesn't it work?
> >
> > On every platform, random_get_entropy() is connected to get_cycles(),
> > except for three: m68k, MIPS, and RISC-V.
> >
>
> [snip]
>
> >
> > I think what this adds up to is that this change would positively affect
> > everybody, except for _possibly_ negatively affecting poorly configured
> > non-Amiga m68k systems and the MIPS R6000 and R6000A. Does that analysis
> > seem correct to folks reading, or did I miss something?
> >
> > Are there other cases where the cycle counter does exist but is simply
> > too slow? Perhaps some computer historians can chime in here.
> >
> > [snip]
This should realy be a config flag. (URANDOM_SECURE_RANDOM?).
>
>
> --
> Joshua Kinard
> Gentoo/MIPS
> [email protected]
> rsa6144/5C63F4E3F5C6C943 2015-04-27
> 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943
>
> "The past tempts us, the present confuses us, the future frightens us. And
> our lives slip away, moment by moment, lost in that vast, terrible in-between."
>
> --Emperor Turhan, Centauri Republic