FreeBSD source tree https://cgit-dev.freebsd.org/src-test/atom?h=main 2020-10-10T21:48:06Z 2020-10-10T21:48:06Z Conrad Meyer cem@FreeBSD.org 2020-10-10T21:48:06Z urn:sha1:10b1a17594a27f83c3ddbce44814f15a0b6bab91 There is no functional change for the existing Fortuna random(4) implementation, which remains the default in GENERIC. In the FenestrasX model, when the root CSPRNG is reseeded from pools due to an (infrequent) timer, child CSPRNGs can cheaply detect this condition and reseed. To do so, they just need to track an additional 64-bit value in the associated state, and compare it against the root seed version (generation) on random reads. This revision integrates arc4random(9) into that model without substantially changing the design or implementation of arc4random(9). The motivation is that arc4random(9) is immediately reseeded when the backing random(4) implementation has additional entropy. This is arguably most important during boot, when fenestrasX is reseeding at 1, 3, 9, 27, etc., second intervals. Today, arc4random(9) has a hardcoded 300 second reseed window. Without this mechanism, if arc4random(9) gets weak entropy during initial seed (and arc4random(9) is used early in boot, so this is quite possible), it may continue to emit poorly seeded output for 5 minutes. The FenestrasX push-reseed scheme corrects consumers, like arc4random(9), as soon as possible. Reviewed by: markm Approved by: csprng (markm) Differential Revision: https://reviews.freebsd.org/D22838 2020-09-08T15:39:19Z Mitchell Horne mhorne@FreeBSD.org 2020-09-08T15:39:19Z urn:sha1:66245bc5360ccff5d734bded0d22d436bc11b2a9 Doing it this way eliminates the assumption about homogeneous support for the feature, since HWCAP values are only set if support is present on all CPUs. Reviewed by: tuexen, markj MFC after: 1 week Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D26032 2020-09-01T21:25:23Z Mateusz Guzik mjg@FreeBSD.org 2020-09-01T21:25:23Z urn:sha1:1060326fb64947686dc13e07af5d71b32cd8a88f 2020-09-01T04:37:55Z Warner Losh imp@FreeBSD.org 2020-09-01T04:37:55Z urn:sha1:cffca129a9b2e061dd9f2eea8124607d2086a813 Save 7k of text space by using simpler crc32 for standalone case. we don't need all that fancy optimization in the boot loader, so use a simplified version of the CRC function. We could save more by doing it one bit at a time rather than 32, but this is the biggest savings at the smallest performance hit. With LUA and verfied exec, gptboot, gptzfsboot and friends are pushing the ~530k limit and every little bit helps. Reviewed By: allanjude Differential Revision: https://reviews.freebsd.org/D24225 2020-08-13T20:48:14Z Conrad Meyer cem@FreeBSD.org 2020-08-13T20:48:14Z urn:sha1:8a0edc914ffdda876987add5128da3ee236a6a12 Add prng(9) as a replacement for random(9) in the kernel. There are two major differences from random(9) and random(3): - General prng(9) APIs (prng32(9), etc) do not guarantee an implementation or particular sequence; they should not be used for repeatable simulations. - However, specific named API families are also exposed (for now: PCG), and those are expected to be repeatable (when so-guaranteed by the named algorithm). Some minor differences from random(3) and earlier random(9): - PRNG state for the general prng(9) APIs is per-CPU; this eliminates contention on PRNG state in SMP workloads. Each PCPU generator in an SMP system produces a unique sequence. - Better statistical properties than the Park-Miller ("minstd") PRNG (longer period, uniform distribution in all bits, passes BigCrush/PractRand analysis). - Faster than Park-Miller ("minstd") PRNG -- no division is required to step PCG-family PRNGs. For now, random(9) becomes a thin shim around prng32(). Eventually I would like to mechanically switch consumers over to the explicit API. Reviewed by: kib, markj (previous version both) Discussed with: markm Differential Revision: https://reviews.freebsd.org/D25916 2020-05-23T17:51:06Z Emmanuel Vadot manu@FreeBSD.org 2020-05-23T17:51:06Z urn:sha1:353d02e9276de65b4814fe3be161e74f8e59c9d7 This variant get a random number up to the limit passed as the argument. This is simply a copy of the libc version. Sponsored-by: The FreeBSD Foundation Reviewed by: cem, hselasky (previous version) Differential Revision: https://reviews.freebsd.org/D24962 2020-02-26T14:26:36Z Pawel Biernacki kaktus@FreeBSD.org 2020-02-26T14:26:36Z urn:sha1:7029da5c36f2d3cf6bb6c81bf551229f416399e8 r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are still not MPSAFE (or already are but aren’t properly marked). Use it in preparation for a general review of all nodes. This is non-functional change that adds annotations to SYSCTL_NODE and SYSCTL_PROC nodes using one of the soon-to-be-required flags. Mark all obvious cases as MPSAFE. All entries that haven't been marked as MPSAFE before are by default marked as NEEDGIANT Approved by: kib (mentor, blanket) Commented by: kib, gallatin, melifaro Differential Revision: https://reviews.freebsd.org/D23718 2019-12-26T19:41:09Z Conrad Meyer cem@FreeBSD.org 2019-12-26T19:41:09Z urn:sha1:f3bae413e9d0ee6dd48cab41fc353039d49bbde7 srandom(9) is meaningless on SMP systems or any system with, say, interrupts. One could never rely on random(9) to produce a reproducible sequence of outputs on the basis of a specific srandom() seed because the global state was shared by all kernel contexts. As such, removing it is literally indistinguishable to random(9) consumers (as compared with retaining it). Mark random(9) as deprecated and slated for quick removal. This is not to say we intend to remove all fast, non-cryptographic PRNG(s) in the kernel. It/they just won't be random(9), as it exists today, in either name or implementation. Before random(9) is removed, a replacement will be provided and in-tree consumers will be converted. Note that despite the name, the random(9) interface does not bear any resemblance to random(3). Instead, it is the same crummy 1988 Park-Miller LCG used in libc rand(3). 2019-11-21T11:22:08Z Andrew Turner andrew@FreeBSD.org 2019-11-21T11:22:08Z urn:sha1:849aef496d2ae19961310f4e92f3a0b928732d26 Update the NetBSD Kernel Concurrency Sanitizer (KCSAN) runtime to work in the FreeBSD kernel. It is a useful tool for finding data races between threads executing on different CPUs. This can be enabled by enabling KCSAN in the kernel config, or by using the GENERIC-KCSAN amd64 kernel. It works on amd64 and arm64, however the later needs a compiler change to allow -fsanitize=thread that KCSAN uses. Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D22315 2019-10-30T10:06:57Z Andrew Turner andrew@FreeBSD.org 2019-10-30T10:06:57Z urn:sha1:44e446a1b399ac24657caa50196de4c082e03a14 Because of the previous naming scheme the old ID_AA64PFR0_EL1 macro collided with a potential macro for the register of the same name. To fix this collision rename these macros. Sponsored by: DARPA, AFRL