WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/i386/include?h=jd%2Fqueueboosts 2020-05-31T06:23:56Z 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. 2020-05-27T15:16:04Z visa visa@openbsd.org 2020-05-27T15:16:04Z urn:sha1:9df0f941a91e9f67cc4e63514cb174cb2a5783fd Nothing uses the header anymore. OK deraadt@ mpi@ 2020-05-25T06:37:52Z mpi mpi@openbsd.org 2020-05-25T06:37:52Z urn:sha1:53eafee545642f7a24ded8233a3af65e0607e825 ok kettenis@, visa@ 2020-05-13T08:32:43Z mpi mpi@openbsd.org 2020-05-13T08:32:43Z urn:sha1:d9d379e18bce8270f9231aedb56c5e08d7d15204 While here use the kqfilter equivalent to `seltrue' to ensure both interfaces are coherent. ok visa@ 2020-04-29T08:53:45Z kettenis kettenis@openbsd.org 2020-04-29T08:53:45Z urn:sha1:1dfa729c7db980850323a4d2665732da667ac609 amd64/arm64/armv7/sparc64 and move it to the end of machdep.c. Rework the actual implementation for the MC14818 compatible RTC into something that can be used as a todr_handle just like on amd64. ok sthen@ 2020-02-20T06:12:14Z jsg jsg@openbsd.org 2020-02-20T06:12:14Z urn:sha1:29aa4a0f82304f8cea18befd646e6282fb5374ff 2019-12-20T07:55:30Z jsg jsg@openbsd.org 2019-12-20T07:55:30Z urn:sha1:8ceddddeec776d7aef2ea40d73b529c2005441bd Even with the latest microcode this is not set on all CPUs with TSX, but is set on CPUs which don't need MDS mitigations. MDS mitigations also mitigate TSX Asynchronous Abort (TAA) but aren't done if the CPU claims to not be affected by MDS (MDS_NO). According to "Deep Dive: Intel Transactional Synchronization Extensions (Intel TSX) Asynchronous Abort" CPUs requiring additional mitigations for this are: 06-8e-0c Whiskey Lake (ULT refresh) 06-55-0{6,7} 2nd Gen Xeon Scalable Processors based on Cascade Lake 06-9e-0d Coffee Lake R Currently TSX is disabled unconditionally when possible even if TAA_NO is set. We don't currently do MDS mitigations on i386. Attempt to disable TSX regardless to match amd64. 2019-12-19T17:46:32Z mpi mpi@openbsd.org 2019-12-19T17:46:32Z urn:sha1:4e56a79ff6919835058578830b0f9b65c66ea6d4 the kernel. ok mlarkin@, visa@ 2019-12-08T12:25:30Z mpi mpi@openbsd.org 2019-12-08T12:25:30Z urn:sha1:e5451c3360c6bc5b6bce9c9984b196e3da4488e6 Its last consumer is now gone and it has certainly not been used since the introduction of PAE back in 2015. ok kettenis@, jsg@ 2019-11-07T14:44:52Z mpi mpi@openbsd.org 2019-11-07T14:44:52Z urn:sha1:6d6b8a876ccc0691e0769b505db074d6e7d968ef