wireguard-openbsd/sys/arch/sh, branch jd/queueboostsWireGuard implementation for the OpenBSD kernelhttps://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/sh?h=jd%2Fqueueboosts2020-05-31T06:23:56Zintroduce "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@
Make inittodr() and resettodr() MI.2020-05-16T14:44:44Zketteniskettenis@openbsd.org2020-05-16T14:44:44Zurn:sha1:5fcf2a4b8103efd7bc779ac85e97dbbe7542aaf4
ok deraadt@, mpi@, visa@
ok cheloha@ as well (would have preferred in new file for this code)
Use the same inittodr()/resettodr() implementation as on2020-05-11T13:27:38Zketteniskettenis@openbsd.org2020-05-11T13:27:38Zurn:sha1:449137a4e062bb10f1f3ba762343a6a53b688f02
amd64/arm64/armv7/hppa/i386/macppc/mips64/sparc64 and move it to the end
of sh_machdep.c. Wrap the existing sh_clock.rtc hooks into something
that can be used as a todr_handle.
ok mpi@
db_addr_t -> vaddr_t2019-11-07T16:08:07Zmpimpi@openbsd.org2019-11-07T16:08:07Zurn:sha1:52de38dfad83669953521277a64804bf85027c8eSubstitute boolean_t/TRUE/FALSE by int/1/0.2019-11-07T15:58:39Zmpimpi@openbsd.org2019-11-07T15:58:39Zurn:sha1:1d47df5535a8eecf36a407d475096db35dd70ad6If uvm_map_inentry returns false then a signal has been delivered, and2019-09-06T12:22:01Zderaadtderaadt@openbsd.org2019-09-06T12:22:01Zurn:sha1:a0da50afa400c90214087c1ffef69c7f438478e9
userret() must be called on trap() exit to deliver it, rather than
repeating the same cause infinitely. discovered by George Koehler
ok kettenis bluhm visa
I wrote the pc-page-writeable and sp-not-MAP_STACK code to be shared, and2019-07-09T23:48:06Zderaadtderaadt@openbsd.org2019-07-09T23:48:06Zurn:sha1:6e2ca2cbbd046982272b6b2bd0b1f22e6313563b
then ran into the messaging being poor. Then I fixed the messages. But
there are two sub-cases of sp-not-MAP_STACK -- one at syscall time, and
another at regular userland trap (on some architectures), and I bungled
that messaging. Correct that now, while I look for yet another better way...
discovered by millert, who ran an pre-MAP_STACK binary.
print the cpu model in the correct place (only)2019-07-07T14:41:55Zderaadtderaadt@openbsd.org2019-07-07T14:41:55Zurn:sha1:12c7b941245c003ecab76ad6af25a5b7b3ae0ebblandisk/sh didn't have the code for checking if sp is on MAP_STACK2019-06-28T05:51:43Zderaadtderaadt@openbsd.org2019-06-28T05:51:43Zurn:sha1:c2e8fdfa702725e2b67cb798bf7c018b805638da
memory, so let's add that where it seems to work
gap noticed by miod