Commit Graph

168 Commits

Author SHA1 Message Date
Adrian Chadd
a09968c479 Convert the random entropy harvesting code to use a const void * pointer
rather than just void *.

Then, as part of this, convert a couple of mbuf m->m_data accesses
to mtod(m, const void *).

Reviewed by:	markm
Approved by:	security-officer (delphij)
Sponsored by:	Netflix, Inc.
2013-11-01 20:53:49 +00:00
Konstantin Belousov
7c3547bacd Utilize the stronger guarantees on the call arguments from the
harvester, which now always calls hwrngs with the buffer length
multiple of the word size.  This allows to remove the excessive memory
accesses to temporary buffer when saving the entropy word.

Streamline the assembly and unify it between i386 and amd64.

Reviewed by:	markm, des
Approved by:	so (des)
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
2013-10-17 07:57:58 +00:00
Mark Murray
4024528a27 Make sure a vaiable is always initialised. 2013-10-12 23:19:01 +00:00
Mark Murray
63edd2efc3 Fix a problem where the priority order of yarrow,dummy can get reversed
to dummy,yarrow and break the usability of /dev/random.

Fix the name of the tunable to something logical that 'sysctl kern.random'
emits.

Submitted by:	des@ (the idea, code by me)
2013-10-12 23:15:06 +00:00
Mark Murray
9c9797f7c5 Fix for i386. 2013-10-11 20:53:25 +00:00
Mark Murray
663c239342 Fix a constant printf which is (int) on some architectures and (long int) on others. 2013-10-10 07:39:19 +00:00
Dag-Erling Smørgrav
997b0a641d 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.
2013-10-09 20:14:16 +00:00
Mark Murray
1b24a3a73b Sigh. I can't even get a single #ifdef right. Who's got the hat? 2013-10-09 18:11:15 +00:00
Dag-Erling Smørgrav
1b277d38f6 staticize struct random_hardware_source 2013-10-09 17:51:38 +00:00
Mark Murray
6a7ba84834 Wrap some policy-rich code in 'if NOTYET' until we can thresh out what it really needs to do. 2013-10-09 17:50:36 +00:00
Dag-Erling Smørgrav
aa1c90971f Re-add /dev/urandom for compatibility purposes. 2013-10-09 09:13:12 +00:00
Dag-Erling Smørgrav
85bbc612af comment nit 2013-10-09 09:12:44 +00:00
Dag-Erling Smørgrav
3e8957ea85 Add missing include guards and move the existing ones out of the
implementation namespace.
2013-10-09 09:11:14 +00:00
Mark Murray
b9887f5053 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.
2013-10-08 22:14:07 +00:00
Mark Murray
898f83f9eb MFC - tracking commit. 2013-10-08 19:07:48 +00:00
Mark Murray
623f70165f 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)
2013-10-08 18:48:11 +00:00
Dimitry Andric
e7ad54b2b4 Now our binutils's assembler supports the Intel Random Number Generator
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
2013-10-08 17:26:28 +00:00
Dag-Erling Smørgrav
db3fcaf970 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.
2013-10-08 11:05:26 +00:00
Mark Murray
6e818c871f 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.
2013-10-08 06:54:52 +00:00
Mark Murray
1a3c1f06dd 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.
2013-10-06 22:45:02 +00:00
Mark Murray
ad1f331196 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.
2013-10-06 12:40:32 +00:00
Mark Murray
eee1352e67 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>
2013-10-06 12:35:29 +00:00
Mark Murray
095ed2c9f3 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.
2013-10-06 09:55:28 +00:00
Mark Murray
f02e47dc1e 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)
2013-10-04 06:55:06 +00:00
Mark Murray
27650413ea MFC - tracking update. 2013-10-02 18:07:43 +00:00
Mark Murray
9365bad8a2 Fix verbose output line; needs <NL>
Submitted by:	Sean Bruno <sean_bruno@yahoo.com>
Approved by:	re (glebius)
2013-09-08 16:48:03 +00:00
Mark Murray
7c2af6212d Fix the build; Certain linkable symbols need to always be present.
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).
2013-09-07 22:07:36 +00:00
Mark Murray
7737ec4198 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>
2013-08-30 17:47:53 +00:00
Mark Murray
77de2c3f58 Separate out the Software RNG entropy harvesting queue and thread into its own files.
Submitted by:	 Arthur Mesh <arthurmesh@gmail.com>
2013-08-30 11:42:57 +00:00
Mark Murray
111e60c2ad Remove the short-lived namei experiment. 2013-08-26 19:07:03 +00:00
Mark Murray
f8530155da 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.
2013-08-26 18:29:51 +00:00
Mark Murray
ddbfa6b19e 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>
2013-08-24 13:54:56 +00:00
David E. O'Brien
5711939b63 * 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: so (des)
2013-08-09 15:31:50 +00:00
David E. O'Brien
0e6a0799a9 Back out r253779 & r253786. 2013-07-31 17:21:18 +00:00
David E. O'Brien
4e368a0f8f 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, obrien
Obtained from: Juniper Networks
Reviewed by: obrien
2013-07-29 20:58:09 +00:00
David E. O'Brien
99ff83da74 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, obrien
Obtained from: Juniper Networks
Reviewed by: obrien
2013-07-29 20:26:27 +00:00
David E. O'Brien
d0961945bb Refactor random_systat to be a *random_systat. This avoids unnecessary
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
2013-07-09 23:47:28 +00:00
Andrey A. Chernov
2b50ce65be Attempt to mitigate poor initialization of arc4 by one-shot
reinitialization from yarrow right after good entropy is harvested.

Approved by:    secteam (delphij)
MFC after:      1 week
2013-04-19 00:30:52 +00:00
Davide Italiano
36d0b73102 MFcalloutng (r236314 by mav):
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
2013-03-04 16:16:23 +00:00
Xin LI
498b4407b9 Correct a typo introduced in r153575, which gives inverted logic when
handling blocking semantics when seeding.

PR:		kern/143298
Submitted by:	James Juran <james juran baesystems com>
Reviewed by:	markm
MFC after:	3 days
2013-02-26 18:33:23 +00:00
Konstantin Belousov
c5e3d0ab11 Rename the IVY_RNG option to RDRAND_RNG.
Based on submission by:	Arthur Mesh <arthurmesh@gmail.com>
MFC after:	2 weeks
2012-09-13 10:12:16 +00:00
Konstantin Belousov
ef9461ba0e Add support for new Intel on-CPU Bull Mountain random number
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
2012-09-05 13:18:51 +00:00
Konstantin Belousov
8c6f8f3d5b Add support for the extended FPU states on amd64, both for native
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
2012-01-21 17:45:27 +00:00
David Schultz
a7eaecefba Generate a warning if the kernel's arc4random() is seeded with bogus entropy. 2012-01-16 20:18:10 +00:00
Jung-uk Kim
ee5f87f458 Enable hardware RNG for VIA Nano processors.
PR:		kern/163974
2012-01-09 23:20:30 +00:00
Rebecca Cran
6bccea7c2b Fix typos - remove duplicate "the".
PR:	bin/154928
Submitted by:	Eitan Adler <lists at eitanadler.com>
MFC after: 	3 days
2011-02-21 09:01:34 +00:00
Konstantin Belousov
23b70c1ae2 Finish r210923, 210926. Mark some devices as eternal.
MFC after:	2 weeks
2011-01-04 10:59:38 +00:00
Konstantin Belousov
04c49e68de Use the fpu_kern_enter() interface to properly separate usermode FPU
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
2010-06-05 16:00:53 +00:00
Mark Murray
84e17f8297 There is rubbish here
It is time to take it out
Now it is cleaner
2009-05-25 22:50:11 +00:00
Colin Percival
8c85a7fb78 Make sure arc4random(9) is properly seeded when /etc/rc.d/initrandom returns.
Approved by:	so (cperciva)
Approved by:	re (kensmith)
Security:	FreeBSD-SA-08:11.arc4random
2008-11-24 17:39:39 +00:00