WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/alpha/include/cpu.h?h=jd%2Fqueueboosts 2020-06-05T14:25:05Z 2020-06-05T14:25:05Z naddy naddy@openbsd.org 2020-06-05T14:25:05Z urn:sha1:4f1155a8e1b8d56b62802304c62b79d4e918eb9a ok dlg@, powerpc/sparc64 ok kettenis@, sparc64/alpha tested by deraadt@ 2020-05-31T06:23:56Z dlg dlg@openbsd.org 2020-05-31T06:23:56Z urn: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. 2019-03-24T06:19:26Z visa visa@openbsd.org 2019-03-24T06:19:26Z urn:sha1:a7f4c0eaa5a9c1b02cf8b788f1a2165abcf9ece2 Reminded by deraadt@ 2018-12-05T10:28:21Z jsg jsg@openbsd.org 2018-12-05T10:28:21Z urn:sha1:1a1181a966226532433438cb3741ae7cdc0727d4 including cpu.h machine/intr.h etc without first including param.h when MULTIPROCESSOR is defined. ok visa@ 2018-04-09T04:11:02Z deraadt deraadt@openbsd.org 2018-04-09T04:11:02Z urn:sha1:96dac833713356961e8a4ffe4b6f17726581cebc It would be better if this was filled in at trap time. ok guenther 2017-05-29T14:19:49Z mpi mpi@openbsd.org 2017-05-29T14:19:49Z urn:sha1:275e6a2f73daf87c4fca2936430979b529d958cc ok visa@, kettenis@ 2016-03-30T15:39:46Z afresh1 afresh1@openbsd.org 2016-03-30T15:39:46Z urn:sha1:baa60ee8e48204039a56b1beaf34f6f63891aa5d From Miod Vallat I trust miod deraadt@ 2016-03-01T19:17:37Z mmcc mmcc@openbsd.org 2016-03-01T19:17:37Z urn:sha1:3870118e4f70869b1aafe836d1f30fbf296da65b from Michal Mazurek, ok deraadt@ 2015-07-02T01:33:59Z dlg dlg@openbsd.org 2015-07-02T01:33:59Z urn:sha1:52776b7dd171c092a35f86a9ed8bd1c22cac9fb8 "shared reference pointers". srp allows concurrent access to a data structure by multiple cpus while avoiding interlocking cpu opcodes. it manages its own reference counts and the garbage collection of those data structure to avoid use after frees. internally srp is a twisted version of hazard pointers, which are a relative of RCU. jmatthew wrote the bulk of a hazard pointer implementation and changed bpf to use it to allow mpsafe access to bpfilters. however, at s2k15 we were trying to apply it to other data structures but the memory overhead of every hazard pointer would have blown out significantly in several uses cases. a bulk of our time at s2k15 was spent reworking hazard pointers into srp. this diff adds the srp api and adds the necessary metadata to struct cpuinfo on our MP architectures. srp on uniprocessor platforms has alternate code that is optimised because it knows there'll be no concurrent access to data by multiple cpus. srp is made available to the system via param.h, so it should be available everywhere in the kernel. the docs likely need improvement cos im too close to the implementation. ok mpi@ 2014-12-17T15:23:40Z deraadt deraadt@openbsd.org 2014-12-17T15:23:40Z urn:sha1:d3bbf02a7a302c79f935e42646e7e992804fa54a ok tedu