wireguard-openbsd/sys/arch/sgi, branch jd/queueboostsWireGuard implementation for the OpenBSD kernelhttps://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/sgi?h=jd%2Fqueueboosts2020-06-06T10:54:41ZAdjust sgi bootblocks' iostrategy routines2020-06-06T10:54:41Zvisavisa@openbsd.org2020-06-06T10:54:41Zurn:sha1:d3d7dc897d09cd2ea8b6a6d87bb2334cb6ed5714
Return an error if write is requested, only reading is implemented.
Set *cnt only if the pointer is non-NULL.
Let sgi bootblocks build again.2020-06-06T10:53:09Zvisavisa@openbsd.org2020-06-06T10:53:09Zurn:sha1:6aebf02881192ece4e58eb13039194602a60fc17Fix previous commit.2020-06-06T10:52:30Zvisavisa@openbsd.org2020-06-06T10:52:30Zurn:sha1:1228c36969f6da3d9ebfa17c7e30fa9ba94ade0dcpu_rnd_messybits() for mips642020-06-05T13:35:20Zvisavisa@openbsd.org2020-06-05T13:35:20Zurn:sha1:3af745964ca685cce92508264ccd88e529f6f467
Use CP0 Count as a basis. Also take noise from virtual memory activity
by including BadVAddr.
OK deraadt@ dlg@
introduce "cpu_rnd_messybits" for use instead of nanotime in dev/rnd.c.2020-05-31T06:23:56Zdlgdlg@openbsd.org2020-05-31T06:23:56Zurn:sha1:01802d2cc63d886227ab3b39e923ff13cf516166
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.
Retire <machine/varargs.h>.2020-05-27T15:16:04Zvisavisa@openbsd.org2020-05-27T15:16:04Zurn:sha1:9df0f941a91e9f67cc4e63514cb174cb2a5783fd
Nothing uses the header anymore.
OK deraadt@ mpi@
sgi had the same bug as sparc64 -- failed to put readdir and fchmod2020-05-26T16:43:36Zderaadtderaadt@openbsd.org2020-05-26T16:43:36Zurn:sha1:b60dc35abe6f89ed2053faff8b6c9ef4aa4de57e
operations for ufs and ufs2 into the file_system[] array ...
increment version numbers, due to recent RB_GOODSEED and fchmod +T changes2020-05-26T14:00:40Zderaadtderaadt@openbsd.org2020-05-26T14:00:40Zurn:sha1:ed5a52b6bdf7c7f007d222e270b64343a6f85fc8/etc/random.seed reuse can now be detected. The stat +T bit marks the file2020-05-26T13:47:27Zderaadtderaadt@openbsd.org2020-05-26T13:47:27Zurn:sha1:e4a6744d811c9dacc6cbd14518ea6671acce58e9
(fchmod +T by bootcode, chmod 600 by /etc/rc). If the seed is reused, and
HWRNG isn't available, the kernel won't get RB_GOODSEED indication...
fchmod() will be needed soon.2020-05-25T16:27:05Zderaadtderaadt@openbsd.org2020-05-25T16:27:05Zurn:sha1:f4f4862db931eae2a44b7a9352f1884c8df6572a
ok kettenis