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)
Directories for /usr/lib{,32}/{i18n,private} were missing from the mtree
file, which caused installworld to install the files that should be in
the directory as the name of the directory.
interpreted the listed items as port numbers of TCP services.
A service with no suffix still works and recognized as a TCP service for
backward compatibility. It should be updated with /tcp suffix.
PR: 194292
MFC after: 1 week
for i386/amd64. Rather, it only works on i386/amd64 and should only be
built there. Rather than change the default based on which
architecutre, do things more directly by only building it on
i386/amd64 and having it always on. This is how we handle other
options that are relevant only for a few architectures.
Summary:
Add a polling loop (1Hz) to monitor the battery and AC status, to notify devd
like ACPI does for power monitoring. This allows /etc/rc.d/power_profile to
work on PowerPC laptops
Test Plan:
Tested on a Titanium PowerBook, configuring economy_cpu_freq and
performance_cpu_freq, disabling powerd.
Reviewers: #powerpc, nwhitehorn
Reviewed By: nwhitehorn
Subscribers: rpaulo
Differential Revision: https://reviews.freebsd.org/D937
This will prevent vim users from accidentally checking in buggy mtree files
(mixed tabs/spaces).
MFC after: 2 weeks
Sponsored by: EMC / Isilon Storage Division
It defines a variable and its default value in load_rc_config() just after
rc.conf is loaded. "rcvar" command shows the current and the default values.
This is an attempt to solve a problem that rc.d scripts from third-party
software do not have entries in /etc/defaults/rc.conf. The fact that
load_rc_config() reads rc.conf only once and /etc/rc invokes the function
before running rc.d scripts made developers confused for a long time because
load_rc_config() just before run_rc_command() in each rc.d script overrides
variables only when the script is directly invoked, not from /etc/rc.
Variables defined in set_rcvar are always set in load_rc_config() after
loading rc.conf. An rc.d script can now be written in a self-contained
manner regarding the related variables as follows:
---
name=foo
rcvar=foo_enable
set_rcvar foo_enable YES "Enable $name"
set_rcvar foo_flags "-s" "Flags to $name"
...
load_rc_config $name
run_rc_command "$@"
---
collision for "no" as a country code with "NO" meaning "do not load any
keymap" (which also has been the default value in etc/defaults/rc.conf
for a long time).
The result of this collision is, that "kbdcontrol -l no" will load the
Norwegian keymap, while "keymap=no" in rc.conf was interpreted as the
lower case spelling of "NO" meaning "no keyboard" (and "no.kbd" was not
loaded).
Fix this by matching only the upper-case spelling "NO" in rc.d/syscons
when deciding whether to load a keymap file.
This will lead to "no.kbd" being loaded, if the until now valid (but
non-default) spelling "no" was used in an individual rc.conf file to mean
"no keyboard". But all alternatives I could think of introduce a larger
violation of POLA ...
Reported by: Gyrd Thane Lange (gyrd-se at thanelange.no)
MFC after: 3 days
Makefiles should not assume that source files can be overwritten. This is the
common case for Perforce source trees.
This is a followup commit to r211243 in the same vein.
MFC after: 1 month
Sponsored by: Spectra Logic
MFSpectraBSD: r1036319 on 2014/01/29, r1046711 on 2014/03/06
This is cleaner and eliminates the unneeded startup of KVP daemon on
systems that do not run as a Hyper-V guest.
Submitted by: hrs
X-MFC-with: 271493, 271688, 271699
run when asked for by the user. Right now, hv_kvpd is run on every boot.
Don't do that.
Add hv_kvpd_enable= for this script to be run.
MFC with 271493
MFC after: 2 weeks
Relnotes: yes
The following warnings were displayed:
sysctl: net.inet.ip.sourceroute=0: Operation not permitted
sysctl: net.inet.ip.accept_sourceroute=0: Operation not permitted
many thanks for their continued support of FreeBSD.
While I'm there, also implement a new build knob, WITHOUT_HYPERV to
disable building and installing of the HyperV utilities when necessary.
The HyperV utilities are only built for i386 and amd64 targets.
This is a stable/10 candidate for inclusion with 10.1-RELEASE.
Submitted by: Wei Hu <weh microsoft com>
MFC after: 1 week
addresses generated by an address range specification. The default
value is 2048. This can be increased by setting $netif_ipexpand_max
in rc.conf.
- Fix warning messages when an address range spec exceeds the upper limit.
PR: 186841
Mounting something in /tmp such as a build jail with nullfs mounts for
some directories can result in very surprising results the next day.
MFC after: 2 weeks
Relnotes: yes
