Commit Graph

132 Commits

Author SHA1 Message Date
obrien
af0e2ca5b5 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
ache
60f7807df1 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
9157a1f8c6 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
delphij
c3efc41585 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
kib
7b37f0ff96 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
kib
dac91f5998 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
kib
361bfae5c2 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
das
3d0182b53d Generate a warning if the kernel's arc4random() is seeded with bogus entropy. 2012-01-16 20:18:10 +00:00
jkim
ff2010b86c Enable hardware RNG for VIA Nano processors.
PR:		kern/163974
2012-01-09 23:20:30 +00:00
brucec
6d9b42b486 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
kib
a6922e1e8c Finish r210923, 210926. Mark some devices as eternal.
MFC after:	2 weeks
2011-01-04 10:59:38 +00:00
kib
6a41cd83d7 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
markm
1dd056c920 There is rubbish here
It is time to take it out
Now it is cleaner
2009-05-25 22:50:11 +00:00
cperciva
657dc776d3 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
simon
ab5beb74a6 Correct a random value disclosure in random(4).
Security:	FreeBSD-SA-07:09.random
2007-11-29 16:06:12 +00:00
julian
51d643caa6 Rename the kthread_xxx (e.g. kthread_create()) calls
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.
2007-10-20 23:23:23 +00:00
rwatson
3588274784 Don't save SYSCTL_ADD_*() results in a local variable just to throw them
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
2007-05-28 18:20:15 +00:00
rwatson
6dd98d5d4e Rather than repeatedly setting and discarding local variable 'o' based
on the return values of various run-time sysctl additions, just ignore
the return value.

Found with:	Coverity Prevent(tm)
CID:		562
2007-05-27 18:54:58 +00:00
jhb
9081d44243 Use pause() rather than tsleep() on stack variables and function pointers. 2007-02-27 17:23:29 +00:00
rwatson
10d0d9cf47 Sweep kernel replacing suser(9) calls with priv(9) calls, assigning
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>
2006-11-06 13:42:10 +00:00
mr
98b081a3da Now even more style(9)ish.
Submitted by:	pjd
2006-07-13 11:47:36 +00:00
mr
4af607ffd5 Use the already stored VIA RNG probe information
instead of probing again.
Adjust style(9) somewhat in probe.c

Reviewed by:	pjd
MFC after:	1 week
2006-07-13 09:15:14 +00:00
mr
883bd6a55e Use the already stored VIA RNG probe information
instead of probing again.

MFC after:	1 week
2006-07-12 20:29:11 +00:00
jhb
d535a5cb81 Change msleep() and tsleep() to not alter the calling thread's priority
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.
2006-04-17 18:20:38 +00:00
ps
46c91127c8 Remove GIANT from device random.
Submitted by:	ups
2005-12-20 21:41:52 +00:00
scottl
5753345cf7 malloc.h relies on param.h for a definition of MAXCPU. I guess that there is
other header pollution that makes this work right now, but it falls over when
doing a RELENG_5 -> HEAD upgrade.
2005-05-30 05:01:44 +00:00
markm
9e31cd3993 Revert to the more correct array size, and correct a KASSERT to
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
2005-03-29 11:08:45 +00:00
phk
2e5f4224e9 Fix off-by-one (too little!) array size problem.
Detected by:	Coverity (ID#661)
2005-03-18 07:13:35 +00:00
ume
73402ef817 stop including rijndael-api-fst.h from rijndael.h.
this is required to integrate opencrypto into crypto.
2005-03-11 15:42:51 +00:00
joerg
c85a3e95f7 netchild's mega-patch to isolate compiler dependencies into a central
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
2005-03-02 21:33:29 +00:00
iedowse
552b43ee44 Check that we have at least a 586-class CPU before calling do_cpuid().
This fixes booting on a number of 486 processors.

PR:		i386/75686
Reviewed by:	markm
MFC after:	1 week
2005-02-06 16:55:52 +00:00
phk
6ab1262cc8 Check O_NONBLOCK not IO_NDELAY.
Don't include vnode.h
2004-12-22 17:29:37 +00:00
jhb
753a25978f Don't change the priority to PUSER when sleeping, just keep the current
priority.
2004-11-05 20:15:06 +00:00
rwatson
e75806b324 (1) Move from O(n) list copies to O(1) list concatenation, which is
supported for STAILQ via STAILQ_CONCAT().

(2) Maintain a count of the number of entries in the thread-local entropy
    fifo so that we can keep the other fifo counts in synch.

MFC after:	3 weeks
MFC with:	randomdev_soft.c revisions 1.5 and 1.6
Suggested by:   jhb (1)
2004-11-03 10:02:50 +00:00
rwatson
7b853afb00 Annotate that get_cyclecount() can be expensive on some platforms,
which juxtaposes nicely with the comment just above on how the
harvest function must be cheap.
2004-10-18 19:29:13 +00:00
rwatson
8917c3df21 Assert that the entropy source category provided by a caller submitting
entropy is valid, as an invalid source will cause dereferencing of an
array of queues to an incorrect memory location.
2004-10-12 14:57:14 +00:00
rwatson
f669b22e75 Modify entropy harvesting locking strategy:
- Trade off granularity to reduce overhead, since the current model
  doesn't appear to reduce contention substantially: move to a single
  harvest mutex protecting harvesting queues, rather than one mutex
  per source plus a mutex for the free list.

- Reduce mutex operations in a harvesting event to 2 from 4, and
  maintain lockless read to avoid mutex operations if the queue is
  full.

- When reaping harvested entries from the queue, move all entries from
  the queue at once, and when done with them, insert them all into a
  thread-local queue for processing; then insert them all into the
  empty fifo at once.  This reduces O(4n) mutex operations to O(2)
  mutex operations per wakeup.

In the future, we may want to look at re-introducing granularity,
although perhaps at the granularity of the source rather than the
source class; both the new and old strategies would cause contention
between different instances of the same source (i.e., multiple
network interfaces).

Reviewed by:	markm
2004-10-09 22:04:13 +00:00
rwatson
ede585e991 Perform a lockless read to test whether an entropy havesting fifo is
full, avoiding the cost of mutex operations if it is.  We re-test
once the mutex is acquired to make sure it's still true before doing
the -modify-write part of the read-modify-write.  Note that due to
the maximum fifo depth being pretty deep, this is unlikely to improve
harvesting performance yet.

Approved by:	markm
2004-08-11 03:33:32 +00:00
markm
4cc8ba8712 Add module versions. 2004-08-02 20:42:28 +00:00
markm
011bdc845d Start the entropy device insecure/unblocked. I'll be handing over
responsibility for critical randomness requirements (like sshd)
to rc.d/*

Requested by: many
2004-07-18 09:07:58 +00:00
phk
5c95d686a1 Do a pass over all modules in the kernel and make them return EOPNOTSUPP
for unknown events.

A number of modules return EINVAL in this instance, and I have left
those alone for now and instead taught MOD_QUIESCE to accept this
as "didn't do anything".
2004-07-15 08:26:07 +00:00
jhb
900e7c295d Trim a few things from the dmesg output and stick them under bootverbose to
cut down on the clutter including PCI interrupt routing, MTRR, pcibios,
etc.

Discussed with:	USENIX Cabal
2004-07-01 07:46:29 +00:00
phk
dfd1f7fd50 Do the dreaded s/dev_t/struct cdev */
Bump __FreeBSD_version accordingly.
2004-06-16 09:47:26 +00:00
phk
d6f7d2bde6 Add some missing <sys/module.h> includes which are masked by the
one on death-row in <sys/kernel.h>
2004-05-30 17:57:46 +00:00
markm
f34e8fe1dd Add a Davies-Meyer style hash to the output. This is still pure
Nehemiah chip, but the work is all done in hardware.

There are three opportunities to add other entropy; the Data
Buffer, the Cipher's IV and the Cipher's key. A future commit
will exploit these opportunities.
2004-04-17 19:26:53 +00:00
markm
8106e11ada More removal of the abortive locking code; malloc buffers when
needed, rather than potentially reusing contents.
2004-04-17 19:23:15 +00:00
markm
ebabd2ca88 Attempts to make this device Giant-free were ill-conceived as
uiomove(9) is not properly locked. So, return to NEEDGIANT
mode. Later, when uiomove is finely locked, I'll revisit.

While I'm here, provide some temporary debugging output to
help catch blocking startups.
2004-04-16 17:10:54 +00:00
markm
c23e5e71d7 Default to harvesting everything. This is to help give a faster
startup. harvesting can be turned OFF in etc/rc.d/* if it is a
burden.
2004-04-16 17:07:11 +00:00
markm
7743e85352 Fix "sleeping without a mutex" panic. 2004-04-12 09:13:24 +00:00
nyan
3341cc4adb Fix pc98 build. 2004-04-11 09:13:42 +00:00