[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-cvs
Subject:    CVS: cvs.openbsd.org: src
From:       David Gwynne <dlg () openbsd ! org>
Date:       2020-05-31 6:23:59
Message-ID: 9739e387f1b35ebe () openbsd ! org
[Download RAW message or body]

CVSROOT:	/cvs
Module name:	src
Changes by:	dlg@cvs.openbsd.org	2020/05/31 00:23:59

Modified files:
	sys/dev        : rnd.c 
	sys/arch/alpha/alpha: machdep.c 
	sys/arch/alpha/include: cpu.h 
	sys/arch/amd64/amd64: machdep.c 
	sys/arch/amd64/include: cpu.h 
	sys/arch/arm/include: cpu.h 
	sys/arch/arm64/arm64: machdep.c 
	sys/arch/arm64/include: cpu.h 
	sys/arch/armv7/armv7: armv7_machdep.c 
	sys/arch/hppa/hppa: machdep.c 
	sys/arch/hppa/include: cpu.h 
	sys/arch/i386/i386: machdep.c 
	sys/arch/i386/include: cpu.h 
	sys/arch/landisk/landisk: machdep.c 
	sys/arch/loongson/loongson: machdep.c 
	sys/arch/luna88k/luna88k: machdep.c 
	sys/arch/m88k/include: cpu.h 
	sys/arch/macppc/macppc: machdep.c 
	sys/arch/mips64/include: cpu.h 
	sys/arch/octeon/octeon: machdep.c 
	sys/arch/powerpc/include: cpu.h 
	sys/arch/powerpc64/include: cpu.h 
	sys/arch/powerpc64/powerpc64: machdep.c 
	sys/arch/sgi/sgi: machdep.c 
	sys/arch/sh/include: cpu.h 
	sys/arch/sparc64/include: cpu.h 
	sys/arch/sparc64/sparc64: machdep.c 

Log message:
introduce "cpu_rnd_messybits" for use instead of nanotime in dev/rnd.c.

rnd.c uses nanotime to get access to some bits that change quickly
between events that it can mix into the entropy pool. it doesn't
use nanotime to get a monotonically increasing set or ordered and
accurate timestamps, it just wants something with bits that change.

there's been discussions for years about letting rnd use a clock
that's super fast to read, but not necessarily accurate, but it
wasn't until recently that i figured out it wasn't interested in
time at all, so things like keeping a fast clock coherent between
cpu cores or correct according to ntp is unecessary. this means we
can just let rnd read the cycle counters on cpus and things will
be fine.  cpus with cycle counters that vary in their speed and
arent kept consistent between cores may even be desirable in this
context.

so this is the first step in converting rnd.c to reading cycle
counter. it copies the nanotime backend to each arch, and they can
replace it with something MD as a second step later on.

djm@ suggested rnd_messybytes, but we landed on cpu_rnd_messybits.
thanks to visa for his eyes.
ok deraadt@ visa@
deraadt@ says he will help handle any MD fallout that occurs.

[prev in list] [next in list] [prev in thread] [next in thread]