summaryrefslogtreecommitdiffstats
path: root/sys/dev/random
Commit message (Collapse)AuthorAgeFilesLines
* MFC r292782: Replace sys/crypto/sha2/sha2.c with lib/libmd/sha512c.cavg2017-02-272-2/+2
| | | | | | | cperciva's libmd implementation is 5-30% faster The same was done for SHA256 previously in r263218 Approved by: secteam
* Adjust initialization of random(9) so it is usable earlier.jhb2016-02-107-19/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | A few existing SYSINITs expect the in-kernel PRNG (random(9)) to be useable at SI_SUB_RANDOM / SI_ORDER_ANY. However, the random(4) overhaul merged for 10.0 performs all of its initialization at SI_SUB_DRIVERS (since it is tied in with creating the /dev/random character device). This has changed in HEAD where the random initialization is split such that the in-kernel random(9) is initialized at SI_SUB_RANDOM and the supporting bits for userland random(4) (such as /dev/random) are initialized later. However, the changes in HEAD are large and invasive. Instead, this change is being directly committed to stable/10. This change moves most of the random(9)/random(4) initialization to SI_SUB_RANDOM with the exception that the creation of the harvesting kernel process and the /dev/random character device are deferred to new SYSINITs that run at SI_SUB_DRIVERS. This fixes the "random device not loaded; using insecure entropy" message output during boot on some systems. PR: 205800 Reviewed by: markm, so@ Approved by: so Approved by: re (gjb) Tested by: Mark Saad <nonesuch@longcount.org>
* MFC r267984:delphij2014-07-111-1/+1
| | | | | | | | Use Intel's official name (Secure Key) per Intel® Digital Random Number Generator (DRNG) Software Implementation Guide. Reviewed by: kib Approved by: so
* MFC r256670:kib2013-11-011-32/+25
| | | | | | | | Rewrite RDRAND support: Remove the excessive memory accesses to temporary buffer. Streamline the assembly and unify it between i386 and amd64. Approved by: re (glebius)
* MFC:markm2013-10-134-7/+19
| | | | | | | | | | | | There is an issue (not seen in our testing) where "yarrow" and "dummy" switch priorities, and the users are left with no usable /dev/random. The fix assigns priories to these and gives the users what they want. The override tuneable has a stupid name (blame me!) and this fixes it to be something that 'sysctl kern.random' emits and is the right thing to set. Approved by: re (gjb) Approved by: secteam (cperciva)
* Merge from project branch via main. Uninteresting commits are trimmed.markm2013-10-1219-501/+866
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Refactor of /dev/random device. Main points include: * Userland seeding is no longer used. This auto-seeds at boot time on PC/Desktop setups; this may need some tweeking and intelligence from those folks setting up embedded boxes, but the work is believed to be minimal. * An entropy cache is written to /entropy (even during installation) and the kernel uses this at next boot. * An entropy file written to /boot/entropy can be loaded by loader(8) * Hardware sources such as rdrand are fed into Yarrow, and are no longer available raw. ------------------------------------------------------------------------ r256240 | des | 2013-10-09 21:14:16 +0100 (Wed, 09 Oct 2013) | 4 lines Add a RANDOM_RWFILE option and hide the entropy cache code behind it. Rename YARROW_RNG and FORTUNA_RNG to RANDOM_YARROW and RANDOM_FORTUNA. Add the RANDOM_* options to LINT. ------------------------------------------------------------------------ r256239 | des | 2013-10-09 21:12:59 +0100 (Wed, 09 Oct 2013) | 2 lines Define RANDOM_PURE_RNDTEST for rndtest(4). ------------------------------------------------------------------------ r256204 | des | 2013-10-09 18:51:38 +0100 (Wed, 09 Oct 2013) | 2 lines staticize struct random_hardware_source ------------------------------------------------------------------------ r256203 | markm | 2013-10-09 18:50:36 +0100 (Wed, 09 Oct 2013) | 2 lines Wrap some policy-rich code in 'if NOTYET' until we can thresh out what it really needs to do. ------------------------------------------------------------------------ r256184 | des | 2013-10-09 10:13:12 +0100 (Wed, 09 Oct 2013) | 2 lines Re-add /dev/urandom for compatibility purposes. ------------------------------------------------------------------------ r256182 | des | 2013-10-09 10:11:14 +0100 (Wed, 09 Oct 2013) | 3 lines Add missing include guards and move the existing ones out of the implementation namespace. ------------------------------------------------------------------------ r256168 | markm | 2013-10-08 23:14:07 +0100 (Tue, 08 Oct 2013) | 10 lines Fix some just-noticed problems: o Allow this to work with "nodevice random" by fixing where the MALLOC pool is defined. o Fix the explicit reseed code. This was correct as submitted, but in the project branch doesn't need to set the "seeded" bit as this is done correctly in the "unblock" function. o Remove some debug ifdeffing. o Adjust comments. ------------------------------------------------------------------------ r256159 | markm | 2013-10-08 19:48:11 +0100 (Tue, 08 Oct 2013) | 6 lines Time to eat crow for me. I replaced the sx_* locks that Arthur used with regular mutexes; this turned out the be the wrong thing to do as the locks need to be sleepable. Revert this folly. # Submitted by: Arthur Mesh <arthurmesh@gmail.com> (In original diff) ------------------------------------------------------------------------ r256138 | des | 2013-10-08 12:05:26 +0100 (Tue, 08 Oct 2013) | 10 lines Add YARROW_RNG and FORTUNA_RNG to sys/conf/options. Add a SYSINIT that forces a reseed during proc0 setup, which happens fairly late in the boot process. Add a RANDOM_DEBUG option which enables some debugging printf()s. Add a new RANDOM_ATTACH entropy source which harvests entropy from the get_cyclecount() delta across each call to a device attach method. ------------------------------------------------------------------------ r256135 | markm | 2013-10-08 07:54:52 +0100 (Tue, 08 Oct 2013) | 8 lines Debugging. My attempt at EVENTHANDLER(multiuser) was a failure; use EVENTHANDLER(mountroot) instead. This means we can't count on /var being present, so something will need to be done about harvesting /var/db/entropy/... . Some policy now needs to be sorted out, and a pre-sync cache needs to be written, but apart from that we are now ready to go. Over to review. ------------------------------------------------------------------------ r256094 | markm | 2013-10-06 23:45:02 +0100 (Sun, 06 Oct 2013) | 8 lines Snapshot. Looking pretty good; this mostly works now. New code includes: * Read cached entropy at startup, both from files and from loader(8) preloaded entropy. Failures are soft, but announced. Untested. * Use EVENTHANDLER to do above just before we go multiuser. Untested. ------------------------------------------------------------------------ r256088 | markm | 2013-10-06 14:01:42 +0100 (Sun, 06 Oct 2013) | 2 lines Fix up the man page for random(4). This mainly removes no-longer-relevant details about HW RNGs, reseeding explicitly and user-supplied entropy. ------------------------------------------------------------------------ r256087 | markm | 2013-10-06 13:43:42 +0100 (Sun, 06 Oct 2013) | 6 lines As userland writing to /dev/random is no more, remove the "better than nothing" bootstrap mode. Add SWI harvesting to the mix. My box seeds Yarrow by itself in a few seconds! YMMV; more to follow. ------------------------------------------------------------------------ r256086 | markm | 2013-10-06 13:40:32 +0100 (Sun, 06 Oct 2013) | 11 lines Debug run. This now works, except that the "live" sources haven't been tested. With all sources turned on, this unlocks itself in a couple of seconds! That is no my box, and there is no guarantee that this will be the case everywhere. * Cut debug prints. * Use the same locks/mutexes all the way through. * Be a tad more conservative about entropy estimates. ------------------------------------------------------------------------ r256084 | markm | 2013-10-06 13:35:29 +0100 (Sun, 06 Oct 2013) | 5 lines Don't use the "real" assembler mnemonics; older compilers may not understand them (like when building CURRENT on 9.x). # Submitted by: Konstantin Belousov <kostikbel@gmail.com> ------------------------------------------------------------------------ r256081 | markm | 2013-10-06 10:55:28 +0100 (Sun, 06 Oct 2013) | 12 lines SNAPSHOT. Simplify the malloc pools; We only need one for this device. Simplify the harvest queue. Marginally improve the entropy pool hashing, making it a bit faster in the process. Connect up the hardware "live" source harvesting. This is simplistic for now, and will need to be made rate-adaptive. All of the above passes a compile test but needs to be debugged. ------------------------------------------------------------------------ r256042 | markm | 2013-10-04 07:55:06 +0100 (Fri, 04 Oct 2013) | 25 lines Snapshot. This passes the build test, but has not yet been finished or debugged. Contains: * Refactor the hardware RNG CPU instruction sources to feed into the software mixer. This is unfinished. The actual harvesting needs to be sorted out. Modified by me (see below). * Remove 'frac' parameter from random_harvest(). This was never used and adds extra code for no good reason. * Remove device write entropy harvesting. This provided a weak attack vector, was not very good at bootstrapping the device. To follow will be a replacement explicit reseed knob. * Separate out all the RANDOM_PURE sources into separate harvest entities. This adds some secuity in the case where more than one is present. * Review all the code and fix anything obviously messy or inconsistent. Address som review concerns while I'm here, like rename the pseudo-rng to 'dummy'. # Submitted by: Arthur Mesh <arthurmesh@gmail.com> (the first item) ------------------------------------------------------------------------ r255319 | markm | 2013-09-06 18:51:52 +0100 (Fri, 06 Sep 2013) | 4 lines Yarrow wants entropy estimations to be conservative; the usual idea is that if you are certain you have N bits of entropy, you declare N/2. ------------------------------------------------------------------------ r255075 | markm | 2013-08-30 18:47:53 +0100 (Fri, 30 Aug 2013) | 4 lines Remove short-lived idea; thread to harvest (eg) RDRAND enropy into the usual harvest queues. It was a nifty idea, but too heavyweight. # Submitted by: Arthur Mesh <arthurmesh@gmail.com> ------------------------------------------------------------------------ r255071 | markm | 2013-08-30 12:42:57 +0100 (Fri, 30 Aug 2013) | 4 lines Separate out the Software RNG entropy harvesting queue and thread into its own files. # Submitted by: Arthur Mesh <arthurmesh@gmail.com> ------------------------------------------------------------------------ r254934 | markm | 2013-08-26 20:07:03 +0100 (Mon, 26 Aug 2013) | 2 lines Remove the short-lived namei experiment. ------------------------------------------------------------------------ r254928 | markm | 2013-08-26 19:35:21 +0100 (Mon, 26 Aug 2013) | 2 lines Snapshot; Do some running repairs on entropy harvesting. More needs to follow. ------------------------------------------------------------------------ r254927 | markm | 2013-08-26 19:29:51 +0100 (Mon, 26 Aug 2013) | 15 lines Snapshot of current work; 1) Clean up namespace; only use "Yarrow" where it is Yarrow-specific or close enough to the Yarrow algorithm. For the rest use a neutral name. 2) Tidy up headers; put private stuff in private places. More could be done here. 3) Streamline the hashing/encryption; no need for a 256-bit counter; 128 bits will last for long enough. There are bits of debug code lying around; these will be removed at a later stage. ------------------------------------------------------------------------ r254784 | markm | 2013-08-24 14:54:56 +0100 (Sat, 24 Aug 2013) | 39 lines 1) example (partially humorous random_adaptor, that I call "EXAMPLE") * 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> Submitted by: Dag-Erling Smørgrav <des@FreeBSD.org>, Arthur Mesh <arthurmesh@gmail.com> Reviewed by: des@FreeBSD.org Approved by: re (delphij) Approved by: secteam (des,delphij)
* Now our binutils's assembler supports the Intel Random Number Generatordim2013-10-081-2/+2
| | | | | | | | | | extensions, we can change the .byte directives in sys/dev/random/ivy.c to plain 'rdrand' mnemonics. This already worked for clang users, but now it will also work for gcc users. Approved by: re (kib) Approved by: so (des) MFC after: 1 week
* Fix verbose output line; needs <NL>markm2013-09-081-1/+1
| | | | | Submitted by: Sean Bruno <sean_bruno@yahoo.com> Approved by: re (glebius)
* Fix the build; Certain linkable symbols need to always be present.markm2013-09-076-19/+13
| | | | | | | | | | | | | Pass the pointy hat please. Also unblock the software (Yarrow) generator for now. This will be reverted; Yarrow needs to block until secure, not this behaviour of serving as soon as asked. Folks with specific requiremnts will be able to (can!) unblock this device with any write, and are encouraged to do so in /etc/rc.d/* scripting. ("Any" in this case could be "echo '' > /dev/random" as root).
* Remove short-lived idea; thread to harvest (eg) RDRAND enropy into the usual ↵markm2013-08-302-73/+0
| | | | | | harvest queues. It was a nifty idea, but too heavyweight. Submitted by: Arthur Mesh <arthurmesh@gmail.com>
* Separate out the Software RNG entropy harvesting queue and thread into its ↵markm2013-08-303-197/+296
| | | | | | own files. Submitted by: Arthur Mesh <arthurmesh@gmail.com>
* Remove the short-lived namei experiment.markm2013-08-261-5/+0
|
* Snapshot of current work;markm2013-08-267-193/+253
| | | | | | | | | | | | | | | 1) Clean up namespace; only use "Yarrow" where it is Yarrow-specific or close enough to the Yarrow algorithm. For the rest use a neutral name. 2) Tidy up headers; put private stuff in private places. More could be done here. 3) Streamline the hashing/encryption; no need for a 256-bit counter; 128 bits will last for long enough. There are bits of debug code lying around; these will be removed at a later stage.
* 1) example (partially humorous random_adaptor, that I call "EXAMPLE")markm2013-08-246-72/+351
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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>
* * Add random_adaptors.[ch] which is basically a store of random_adaptor's.obrien2013-08-0910-107/+392
| | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* Back out r253779 & r253786.obrien2013-07-3110-399/+107
|
* Decouple yarrow from random(4) device.obrien2013-07-292-0/+207
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
* Decouple yarrow from random(4) device.obrien2013-07-298-107/+192
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
* Refactor random_systat to be a *random_systat. This avoids unnecessaryobrien2013-07-094-27/+27
| | | | | | | | | 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
* Attempt to mitigate poor initialization of arc4 by one-shotache2013-04-191-0/+2
| | | | | | | reinitialization from yarrow right after good entropy is harvested. Approved by: secteam (delphij) MFC after: 1 week
* MFcalloutng (r236314 by mav):davide2013-03-041-3/+4
| | | | | | | | Specify that wakeup rate of 7.5-10Hz is enough for yarrow harvesting thread. Sponsored by: Google Summer of Code 2012, iXsystems inc. Tested by: flo, marius, ian, markj, Fabian Keil
* Correct a typo introduced in r153575, which gives inverted logic whendelphij2013-02-261-1/+1
| | | | | | | | | handling blocking semantics when seeding. PR: kern/143298 Submitted by: James Juran <james juran baesystems com> Reviewed by: markm MFC after: 3 days
* Rename the IVY_RNG option to RDRAND_RNG.kib2012-09-132-3/+3
| | | | | Based on submission by: Arthur Mesh <arthurmesh@gmail.com> MFC after: 2 weeks
* Add support for new Intel on-CPU Bull Mountain random numberkib2012-09-054-32/+156
| | | | | | | | | | | | | | | | | | | 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
* Add support for the extended FPU states on amd64, both for nativekib2012-01-211-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 64bit and 32bit ABIs. As a side-effect, it enables AVX on capable CPUs. In particular: - Query the CPU support for XSAVE, list of the supported extensions and the required size of FPU save area. The hw.use_xsave tunable is provided for disabling XSAVE, and hw.xsave_mask may be used to select the enabled extensions. - Remove the FPU save area from PCB and dynamically allocate the (run-time sized) user save area on the top of the kernel stack, right above the PCB. Reorganize the thread0 PCB initialization to postpone it after BSP is queried for save area size. - The dumppcb, stoppcbs and susppcbs now do not carry the FPU state as well. FPU state is only useful for suspend, where it is saved in dynamically allocated suspfpusave area. - Use XSAVE and XRSTOR to save/restore FPU state, if supported and enabled. - Define new mcontext_t flag _MC_HASFPXSTATE, indicating that mcontext_t has a valid pointer to out-of-struct extended FPU state. Signal handlers are supplied with stack-allocated fpu state. The sigreturn(2) and setcontext(2) syscall honour the flag, allowing the signal handlers to inspect and manipilate extended state in the interrupted context. - The getcontext(2) never returns extended state, since there is no place in the fixed-sized mcontext_t to place variable-sized save area. And, since mcontext_t is embedded into ucontext_t, makes it impossible to fix in a reasonable way. Instead of extending getcontext(2) syscall, provide a sysarch(2) facility to query extended FPU state. - Add ptrace(2) support for getting and setting extended state; while there, implement missed PT_I386_{GET,SET}XMMREGS for 32bit binaries. - Change fpu_kern KPI to not expose struct fpu_kern_ctx layout to consumers, making it opaque. Internally, struct fpu_kern_ctx now contains a space for the extended state. Convert in-kernel consumers of fpu_kern KPI both on i386 and amd64. First version of the support for AVX was submitted by Tim Bird <tim.bird am sony com> on behalf of Sony. This version was written from scratch. Tested by: pho (previous version), Yamagi Burmeister <lists yamagi org> MFC after: 1 month
* Generate a warning if the kernel's arc4random() is seeded with bogus entropy.das2012-01-161-0/+8
|
* Enable hardware RNG for VIA Nano processors.jkim2012-01-091-2/+2
| | | | PR: kern/163974
* Fix typos - remove duplicate "the".brucec2011-02-211-1/+1
| | | | | | PR: bin/154928 Submitted by: Eitan Adler <lists at eitanadler.com> MFC after: 3 days
* Finish r210923, 210926. Mark some devices as eternal.kib2011-01-041-2/+2
| | | | MFC after: 2 weeks
* Use the fpu_kern_enter() interface to properly separate usermode FPUkib2010-06-051-1/+11
| | | | | | | | | | | | | | context from in-kernel execution of padlock instructions and to handle spurious FPUDNA exceptions that sometime are raised when doing padlock calculations. Globally mark crypto(9) kthread as using FPU. Reviewed by: pjd Hardware provided by: Sentex Communications Tested by: pho PR: amd64/135014 MFC after: 1 month
* There is rubbish heremarkm2009-05-252-11/+8
| | | | | It is time to take it out Now it is cleaner
* Make sure arc4random(9) is properly seeded when /etc/rc.d/initrandom returns.cperciva2008-11-242-3/+24
| | | | | | Approved by: so (cperciva) Approved by: re (kensmith) Security: FreeBSD-SA-08:11.arc4random
* Correct a random value disclosure in random(4).simon2007-11-291-0/+1
| | | | Security: FreeBSD-SA-07:09.random
* Rename the kthread_xxx (e.g. kthread_create()) callsjulian2007-10-202-3/+3
| | | | | | | | | | | to kproc_xxx as they actually make whole processes. Thos makes way for us to add REAL kthread_create() and friends that actually make theads. it turns out that most of these calls actually end up being moved back to the thread version when it's added. but we need to make this cosmetic change first. I'd LOVE to do this rename in 7.0 so that we can eventually MFC the new kthread_xxx() calls.
* Don't save SYSCTL_ADD_*() results in a local variable just to throw themrwatson2007-05-281-15/+9
| | | | | | | | away; preserve the ones that are needed for further calls in the init function and ignore the rest entirely. Found with: Coverity Prevent(tm) CID: 563
* Rather than repeatedly setting and discarding local variable 'o' basedrwatson2007-05-271-9/+7
| | | | | | | | on the return values of various run-time sysctl additions, just ignore the return value. Found with: Coverity Prevent(tm) CID: 562
* Use pause() rather than tsleep() on stack variables and function pointers.jhb2007-02-271-1/+1
|
* Sweep kernel replacing suser(9) calls with priv(9) calls, assigningrwatson2006-11-061-1/+2
| | | | | | | | | | | | | specific privilege names to a broad range of privileges. These may require some future tweaking. Sponsored by: nCircle Network Security, Inc. Obtained from: TrustedBSD Project Discussed on: arch@ Reviewed (at least in part) by: mlaier, jmg, pjd, bde, ceri, Alex Lyashkov <umka at sevcity dot net>, Skip Ford <skip dot ford at verizon dot net>, Antoine Brodin <antoine dot brodin at laposte dot net>
* Now even more style(9)ish.mr2006-07-131-1/+1
| | | | Submitted by: pjd
* Use the already stored VIA RNG probe informationmr2006-07-131-1/+1
| | | | | | | | instead of probing again. Adjust style(9) somewhat in probe.c Reviewed by: pjd MFC after: 1 week
* Use the already stored VIA RNG probe informationmr2006-07-121-13/+4
| | | | | | instead of probing again. MFC after: 1 week
* Change msleep() and tsleep() to not alter the calling thread's priorityjhb2006-04-171-4/+2
| | | | | | | | | | | | if the specified priority is zero. This avoids a race where the calling thread could read a snapshot of it's current priority, then a different thread could change the first thread's priority, then the original thread would call sched_prio() inside msleep() undoing the change made by the second thread. I used a priority of zero as no thread that calls msleep() or tsleep() should be specifying a priority of zero anyway. The various places that passed 'curthread->td_priority' or some variant as the priority now pass 0.
* Remove GIANT from device random.ps2005-12-206-16/+69
| | | | Submitted by: ups
* malloc.h relies on param.h for a definition of MAXCPU. I guess that there isscottl2005-05-301-0/+1
| | | | | other header pollution that makes this work right now, but it falls over when doing a RELENG_5 -> HEAD upgrade.
* Revert to the more correct array size, and correct a KASSERT tomarkm2005-03-291-2/+2
| | | | | | | | only allow proper values. ENTROPYSOURCE is a maxval+1, not an allowable number. Suggested loose protons in the solution: phk Prefers to keep the pH close to seven: markm
* Fix off-by-one (too little!) array size problem.phk2005-03-181-1/+1
| | | | Detected by: Coverity (ID#661)
* stop including rijndael-api-fst.h from rijndael.h.ume2005-03-112-2/+2
| | | | this is required to integrate opencrypto into crypto.
* netchild's mega-patch to isolate compiler dependencies into a centraljoerg2005-03-021-2/+2
| | | | | | | | | | | | | | | | place. This moves the dependency on GCC's and other compiler's features into the central sys/cdefs.h file, while the individual source files can then refer to #ifdef __COMPILER_FEATURE_FOO where they by now used to refer to #if __GNUC__ > 3.1415 && __BARC__ <= 42. By now, GCC and ICC (the Intel compiler) have been actively tested on IA32 platforms by netchild. Extension to other compilers is supposed to be possible, of course. Submitted by: netchild Reviewed by: various developers on arch@, some time ago
* Check that we have at least a 586-class CPU before calling do_cpuid().iedowse2005-02-061-0/+3
| | | | | | | | This fixes booting on a number of 486 processors. PR: i386/75686 Reviewed by: markm MFC after: 1 week
* Check O_NONBLOCK not IO_NDELAY.phk2004-12-222-3/+1
| | | | Don't include vnode.h
OpenPOWER on IntegriCloud