aboutsummaryrefslogtreecommitdiff
path: root/sys/dev/random/probe.c
Commit message (Collapse)AuthorAgeFilesLines
* 1) example (partially humorous random_adaptor, that I call "EXAMPLE")Mark Murray2013-08-241-62/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * It's not meant to be used in a real system, it's there to show how the basics of how to create interfaces for random_adaptors. Perhaps it should belong in a manual page 2) Move probe.c's functionality in to random_adaptors.c * rename random_ident_hardware() to random_adaptor_choose() 3) Introduce a new way to choose (or select) random_adaptors via tunable "rngs_want" It's a list of comma separated names of adaptors, ordered by preferences. I.e.: rngs_want="yarrow,rdrand" Such setting would cause yarrow to be preferred to rdrand. If neither of them are available (or registered), then system will default to something reasonable (currently yarrow). If yarrow is not present, then we fall back to the adaptor that's first on the list of registered adaptors. 4) Introduce a way where RNGs can play a role of entropy source. This is mostly useful for HW rngs. The way I envision this is that every HW RNG will use this functionality by default. Functionality to disable this is also present. I have an example of how to use this in random_adaptor_example.c (see modload event, and init function) 5) fix kern.random.adaptors from kern.random.adaptors: yarrowpanicblock to kern.random.adaptors: yarrow,panic,block 6) add kern.random.active_adaptor to indicate currently selected adaptor: root@freebsd04:~ # sysctl kern.random.active_adaptor kern.random.active_adaptor: yarrow Submitted by: Arthur Mesh <arthurmesh@gmail.com> Notes: svn path=/projects/random_number_generator/; revision=254784
* * Add random_adaptors.[ch] which is basically a store of random_adaptor's.David E. O'Brien2013-08-091-46/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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, obrien Obtained from: Juniper Networks Reviewed by: so (des) Notes: svn path=/head/; revision=254147
* Back out r253779 & r253786.David E. O'Brien2013-07-311-15/+46
| | | | Notes: svn path=/head/; revision=253845
* Decouple yarrow from random(4) device.David E. O'Brien2013-07-291-46/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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, obrien Obtained from: Juniper Networks Reviewed by: obrien Notes: svn path=/head/; revision=253779
* Refactor random_systat to be a *random_systat. This avoids unnecessaryDavid E. O'Brien2013-07-091-4/+4
| | | | | | | | | | | | structure copying in random_ident_hardware(). This change will also help further modularization of random(4) subsystem. Submitted by: arthurmesh@gmail.com Reviewed by: obrien Obtained from: Juniper Networks Notes: svn path=/head/; revision=253122
* Rename the IVY_RNG option to RDRAND_RNG.Konstantin Belousov2012-09-131-2/+2
| | | | | | | | Based on submission by: Arthur Mesh <arthurmesh@gmail.com> MFC after: 2 weeks Notes: svn path=/head/; revision=240455
* Add support for new Intel on-CPU Bull Mountain random numberKonstantin Belousov2012-09-051-3/+33
| | | | | | | | | | | | | | | | | | | | | | generator, found on IvyBridge and supposedly later CPUs, accessible with RDRAND instruction. From the Intel whitepapers and articles about Bull Mountain, it seems that we do not need to perform post-processing of RDRAND results, like AES-encryption of the data with random IV and keys, which was done for Padlock. Intel claims that sanitization is performed in hardware. Make both Padlock and Bull Mountain random generators support code covered by kernel config options, for the benefit of people who prefer minimal kernels. Also add the tunables to disable hardware generator even if detected. Reviewed by: markm, secteam (simon) Tested by: bapt, Michael Moll <kvedulv@kvedulv.de> MFC after: 3 weeks Notes: svn path=/head/; revision=240135
* Enable hardware RNG for VIA Nano processors.Jung-uk Kim2012-01-091-2/+2
| | | | | | | PR: kern/163974 Notes: svn path=/head/; revision=229887
* Now even more style(9)ish.Michael Reifenberger2006-07-131-1/+1
| | | | | | | Submitted by: pjd Notes: svn path=/head/; revision=160326
* Use the already stored VIA RNG probe informationMichael Reifenberger2006-07-131-1/+1
| | | | | | | | | | | instead of probing again. Adjust style(9) somewhat in probe.c Reviewed by: pjd MFC after: 1 week Notes: svn path=/head/; revision=160325
* Use the already stored VIA RNG probe informationMichael Reifenberger2006-07-121-13/+4
| | | | | | | | | instead of probing again. MFC after: 1 week Notes: svn path=/head/; revision=160311
* malloc.h relies on param.h for a definition of MAXCPU. I guess that there isScott Long2005-05-301-0/+1
| | | | | | | | other header pollution that makes this work right now, but it falls over when doing a RELENG_5 -> HEAD upgrade. Notes: svn path=/head/; revision=146797
* Check that we have at least a 586-class CPU before calling do_cpuid().Ian Dowse2005-02-061-0/+3
| | | | | | | | | | | This fixes booting on a number of 486 processors. PR: i386/75686 Reviewed by: markm MFC after: 1 week Notes: svn path=/head/; revision=141405
* Fix pc98 build.Yoshihiro Takahashi2004-04-111-3/+3
| | | | Notes: svn path=/head/; revision=128109
* Reorganise the entropy device so that high-yield entropy sourcesMark Murray2004-04-091-0/+68
can more easily be used INSTEAD OF the hard-working Yarrow. The only hardware source used at this point is the one inside the VIA C3 Nehemiah (Stepping 3 and above) CPU. More sources will be added in due course. Contributions welcome! Notes: svn path=/head/; revision=128059
generated by cgit v1.3 (git 2.53.0) at 2026-10-24 03:32:34 +0000