Remove residual blank line at start of MakefileThis is a residual of the $FreeBSD$ removal.MFC After: 3 days (though I'll just run the command on the branches)Sponsored by: Netflix
sys: Remove $FreeBSD$: one-line sh patternRemove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
rdrand_rng: Build with -fPIC on i386 when using GCC.ld.bfd requires an R_386_PLT32 relocation for calls to ifuncsrather than R_386_PC32. (lld permits R_386_PC32.)Reviewed by: kibDifferential R
rdrand_rng: Build with -fPIC on i386 when using GCC.ld.bfd requires an R_386_PLT32 relocation for calls to ifuncsrather than R_386_PC32. (lld permits R_386_PC32.)Reviewed by: kibDifferential Revision: https://reviews.freebsd.org/D40811
show more ...
sys/modules: normalize .CURDIR-relative paths to SRCTOPThis simplifies make output/logicTested with: `cd sys/modules; make ALL_MODULES=` on amd64MFC after: 1 monthSponsored by: Dell EMC Isilon
This is the much-discussed major upgrade to the random(4) device, known to you all as /dev/random.This code has had an extensive rewrite and a good series of reviews, both by the author and other p
This is the much-discussed major upgrade to the random(4) device, known to you all as /dev/random.This code has had an extensive rewrite and a good series of reviews, both by the author and other parties. This means a lot of code has been simplified. Pluggable structures for high-rate entropy generators are available, and it is most definitely not the case that /dev/random can be driven by only a hardware souce any more. This has been designed out of the device. Hardware sources are stirred into the CSPRNG (Yarrow, Fortuna) like any other entropy source. Pluggable modules may be written by third parties for additional sources.The harvesting structures and consequently the locking have been simplified. Entropy harvesting is done in a more general way (the documentation for this will follow). There is some GREAT entropy to be had in the UMA allocator, but it is disabled for now as messing with that is likely to annoy many people.The venerable (but effective) Yarrow algorithm, which is no longer supported by its authors now has an alternative, Fortuna. For now, Yarrow is retained as the default algorithm, but this may be changed using a kernel option. It is intended to make Fortuna the default algorithm for 11.0. Interested parties are encouraged to read ISBN 978-0-470-47424-2 "Cryptography Engineering" By Ferguson, Schneier and Kohno for Fortuna's gory details. Heck, read it anyway.Many thanks to Arthur Mesh who did early grunt work, and who got caught in the crossfire rather more than he deserved to.My thanks also to folks who helped me thresh this out on whiteboards and in the odd "Hallway track", or otherwise.My Nomex pants are on. Let the feedback commence!Reviewed by: trasz,des(partial),imp(partial?),rwatson(partial?)Approved by: so(des)
Back out r253779 & r253786.
Decouple yarrow from random(4) device.* Make Yarrow an optional kernel component -- enabled by "YARROW_RNG" option. The files sha2.c, hash.c, randomdev_soft.c and yarrow.c comprise yarrow.* ran
Decouple yarrow from random(4) device.* Make Yarrow an optional kernel component -- enabled by "YARROW_RNG" option. The files sha2.c, hash.c, randomdev_soft.c and yarrow.c comprise yarrow.* random(4) device doesn't really depend on rijndael-*. Yarrow, however, does.* Add random_adaptors.[ch] which is basically a store of random_adaptor's. random_adaptor is basically an adapter that plugs in to random(4). random_adaptor can only be plugged in to random(4) very early in bootup. Unplugging random_adaptor from random(4) is not supported, and is probably a bad idea anyway, due to potential loss of entropy pools. We currently have 3 random_adaptors: + yarrow + rdrand (ivy.c) + nehemeiah* Remove platform dependent logic from probe.c, and move it into corresponding registration routines of each random_adaptor provider. probe.c doesn't do anything other than picking a specific random_adaptor from a list of registered ones.* If the kernel doesn't have any random_adaptor adapters present then the creation of /dev/random is postponed until next random_adaptor is kldload'ed.* Fix randomdev_soft.c to refer to its own random_adaptor, instead of a system wide one.Submitted by: arthurmesh@gmail.com, obrienObtained from: Juniper NetworksReviewed by: obrien