Commit Graph

1208 Commits

Author SHA1 Message Date
Conrad Meyer
58b5b90d6a Fixup UPDATING text for r349253
Requested by:	delphij
2019-06-21 00:33:45 +00:00
Conrad Meyer
c363b16c63 sys: Remove DEV_RANDOM device option
Remove 'device random' from kernel configurations that reference it (most).
Replace perhaps mistaken 'nodevice random' in two MIPS configs with 'options
RANDOM_LOADABLE' instead.  Document removal in UPDATING; update NOTES and
random.4.

Reviewed by:	delphij, markm (previous version)
Approved by:	secteam(delphij)
Differential Revision:	https://reviews.freebsd.org/D19918
2019-06-21 00:16:30 +00:00
Dimitry Andric
efc5c4420a Upgrade our copies of clang, llvm, lld, lldb, compiler-rt, libc++,
libunwind and openmp to the upstream release_80 branch r363030
(effectively, 8.0.1 rc2).  The 8.0.1 release should follow this within a
week or so.

MFC after:	2 weeks
2019-06-12 21:10:37 +00:00
Bjoern A. Zeeb
4c62bffef5 Fix dpcpu and vnet panics with complex types at the end of the section.
Apply a linker script when linking i386 kernel modules to apply padding
to a set_pcpu or set_vnet section.  The padding value is kind-of random
and is used to catch modules not compiled with the linker-script, so
possibly still having problems leading to kernel panics.

This is needed as the code generated on certain architectures for
non-simple-types, e.g., an array can generate an absolute relocation
on the edge (just outside) the section and thus will not be properly
relocated. Adding the padding to the end of the section will ensure
that even absolute relocations of complex types will be inside the
section, if they are the last object in there and hence relocation will
work properly and avoid panics such as observed with carp.ko or ipsec.ko.

There is a rather lengthy discussion of various options to apply in
the mentioned PRs and their depends/blocks, and the review.
There seems no best solution working across multiple toolchains and
multiple version of them, so I took the liberty of taking one,
as currently our users (and our CI system) are hitting this on
just i386 and we need some solution.  I wish we would have a proper
fix rather than another "hack".

Also backout r340009 which manually, temporarily fixed CARP before 12.0-R
"by chance" after a lead-up of various other link-elf.c and related fixes.

PR:			230857,238012
With suggestions from:	arichardson (originally last year)
Tested by:		lwhsu
Event:			Waterloo Hackathon 2019
Reported by:		lwhsu, olivier
MFC after:		6 weeks
Differential Revision:	https://reviews.freebsd.org/D17512
2019-06-08 17:44:42 +00:00
Baptiste Daroussin
45a13fd899 Move back group, master.passwd and shells to etc directory
Use the .PATH mechanism instead so keep installing them from lib/libc/gen

While here revert 347961 and 347893 which are no longer needed

Discussed with:	manu
Tested by:	manu
ok manu@
2019-05-23 18:37:05 +00:00
Brad Davis
862dc23d73 Add note to UPDATING for users of mergemaster after the move of master.passwd
and group in r347638.

Approved by:	allanjude (mentor)
2019-05-18 19:36:23 +00:00
Conrad Meyer
e199792d23 Revert r346292 (permit_nonrandom_stackcookies)
We have a better, more comprehensive knob for this now:
kern.random.initial_seeding.bypass_before_seeding=1.

Requested by:	delphij
Sponsored by:	Dell EMC Isilon
2019-05-13 23:37:44 +00:00
Mark Johnston
aa0a893384 Add an UPDATING entry and bump __FreeBSD_version for r347532.
Reported by:	rgrimes, Oliver Pinter <oliver.pinter@hardenedbsd.org>
2019-05-13 18:48:08 +00:00
Jens Schweikhardt
82455a3319 Correct a handful of typos. 2019-05-11 19:31:54 +00:00
Andrew Gallatin
542970fa2d Remove IPSEC from GENERIC due to performance issues
Having IPSEC compiled into the kernel imposes a non-trivial
performance penalty on multi-threaded workloads due to IPSEC
refcounting. In my benchmarks of multi-threaded UDP
transmit (connected sockets), I've seen a roughly 20% performance
penalty when the IPSEC option is included in the kernel (16.8Mpps
vs 13.8Mpps with 32 senders on a 14 core / 28 HTT Xeon
2697v3)). This is largely due to key_addref() incrementing and
decrementing an atomic reference count on the default
policy. This cause all CPUs to stall on the same cacheline, as it
bounces between different CPUs.

Given that relatively few users use ipsec, and that it can be
loaded as a module, it seems reasonable to ask those users to
load the ipsec module so as to avoid imposing this penalty on the
GENERIC kernel. Its my hope that this will make FreeBSD look
better in "out of the box" benchmark comparisons with other
operating systems.

Many thanks to ae for fixing auto-loading of ipsec.ko when
ifconfig tries to configure ipsec, and to cy for volunteering
to ensure the the racoon ports will load the ipsec.ko module

Reviewed by:	cem, cy, delphij, gnn, jhb, jpaetzel
Differential Revision:	https://reviews.freebsd.org/D20163
2019-05-09 22:38:15 +00:00
Kyle Evans
251a32b5b2 tun/tap: merge and rename to tuntap
tun(4) and tap(4) share the same general management interface and have a lot
in common. Bugs exist in tap(4) that have been fixed in tun(4), and
vice-versa. Let's reduce the maintenance requirements by merging them
together and using flags to differentiate between the three interface types
(tun, tap, vmnet).

This fixes a couple of tap(4)/vmnet(4) issues right out of the gate:
- tap devices may no longer be destroyed while they're open [0]
- VIMAGE issues already addressed in tun by kp

[0] emaste had removed an easy-panic-button in r240938 due to devdrn
blocking. A naive glance over this leads me to believe that this isn't quite
complete -- destroy_devl will only block while executing d_* functions, but
doesn't block the device from being destroyed while a process has it open.
The latter is the intent of the condvar in tun, so this is "fixed" (for
certain definitions of the word -- it wasn't really broken in tap, it just
wasn't quite ideal).

ifconfig(8) also grew the ability to map an interface name to a kld, so
that `ifconfig {tun,tap}0` can continue to autoload the correct module, and
`ifconfig vmnet0 create` will now autoload the correct module. This is a
low overhead addition.

(MFC commentary)

This may get MFC'd if many bugs in tun(4)/tap(4) are discovered after this,
and how critical they are. Changes after this are likely easily MFC'd
without taking this merge, but the merge will be easier.

I have no plans to do this MFC as of now.

Reviewed by:	bcr (manpages), tuexen (testing, syzkaller/packetdrill)
Input also from:	melifaro
Relnotes:	yes
Differential Revision:	https://reviews.freebsd.org/D20044
2019-05-08 02:32:11 +00:00
Conrad Meyer
3782136ff1 random(4): Restore availability tradeoff prior to r346250
As discussed in that commit message, it is a dangerous default.  But the
safe default causes enough pain on a variety of platforms that for now,
restore the prior default.

Some of this is self-induced pain we should/could do better about; for
example, programmatic CI systems and VM managers should introduce entropy
from the host for individual VM instances.  This is considered a future work
item.

On modern x86 and Power9 systems, this may be wholly unnecessary after
D19928 lands (even in the non-ideal case where early /boot/entropy is
unavailable), because they have fast hardware random sources available early
in boot.  But D19928 is not yet landed and we have a host of architectures
which do not provide fast random sources.

This change adds several tunables and diagnostic sysctls, documented
thoroughly in UPDATING and sys/dev/random/random_infra.c.

PR:		230875 (reopens)
Reported by:	adrian, jhb, imp, and probably others
Reviewed by:	delphij, imp (earlier version), markm (earlier version)
Discussed with:	adrian
Approved by:	secteam(delphij)
Relnotes:	yeah
Security:	related
Differential Revision:	https://reviews.freebsd.org/D19944
2019-04-18 20:48:54 +00:00
Conrad Meyer
ba57dad4b0 stack_protector: Add tunable to bypass random cookies
This is a stopgap measure to unbreak installer/VM/embedded boot issues
introduced (or at least exposed by) in r346250.

Add the new tunable, "security.stack_protect.permit_nonrandom_cookies," in
order to continue boot with insecure non-random stack cookies if the random
device is unavailable.

For now, enable it by default.  This is NOT safe.  It will be disabled by
default in a future revision.

There is follow-on work planned to use fast random sources (e.g., RDRAND on
x86 and DARN on Power) to seed when the early entropy file cannot be
provided, for whatever reason.  Please see D19928.

Some better hacks may be used to make the non-random __stack_chk_guard
slightly less predictable (from delphij@ and mjg@); those suggestions are
left for a future revision.  I think it may also be plausible to move stack
guard initialization far later in the boot process; potentially it could be
moved all the way to just before userspace is started.

Reported by:	many
Reviewed by:	delphij, emaste, imp (all w/ caveat: this is a stopgap fix)
Security:	yes
Sponsored by:	Dell EMC Isilon
Differential Revision:	https://reviews.freebsd.org/D19927
2019-04-16 18:47:20 +00:00
Conrad Meyer
f3d2512db6 random(4): Add is_random_seeded(9) KPI
The imagined use is for early boot consumers of random to be able to make
decisions based on whether random is available yet or not.  One such
consumer seems to be __stack_chk_init(), which runs immediately after random
is initialized.  A follow-up patch will attempt to address that.

Reported by:	many
Reviewed by:	delphij (except man page)
Approved by:	secteam(delphij)
Differential Revision:	https://reviews.freebsd.org/D19926
2019-04-16 17:12:17 +00:00
Rick Macklem
bcf55f6463 Add an entry to UPDATING for r345895, which affects the use of nfsuserd daemons
built from head sources between July 6, 2017 and Aug. 22, 2018.
2019-04-04 23:40:30 +00:00
Konstantin Belousov
fc56fdf35a Add UPDATING note for geom_uzip(4)/xz, and bump geom_uzip(4) man page date.
Sponsored by:	The FreeBSD Foundation
MFC after:	3 days
2019-03-23 10:13:01 +00:00
Alan Somers
123af6ec70 Rename fuse(4) to fusefs(4)
This makes it more consistent with other filesystems, which all end in "fs",
and more consistent with its mount helper, which is already named
"mount_fusefs".

Reviewed by:	cem, rgrimes
MFC after:	2 weeks
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D19649
2019-03-20 21:48:43 +00:00
Warner Losh
ed651a7496 Tweak wording a little.
Submitted by: peterj@
2019-03-12 06:01:43 +00:00
Warner Losh
359d22d4e9 Augment ino64 entry
When updating across this change (the introduction of ino64), the
"fast and loose" practice of rebooting to multiuser and then doing an
installworld fails with missing symbols. Recommend strongly that users
do this in single user mode. The multiuser case only ever works by
accident because its requirements are stronger than is supported
accross this change. It usually works because critical symbols don't
change their version number in libc, which wasn't the case here.
2019-03-09 17:17:59 +00:00
Warner Losh
274cfcd71c Fix a number of entries (almost all mine) that were > 80 columns.
When reading UPDATING from single user in vi, I noticed a few wrapped,
so fix them to not wrap.
	expand -8 UPDATING | awk 'length > 80'
made this easy to find all the offenders.
2019-03-09 17:17:55 +00:00
Warner Losh
8ed2d94ad6 Misc fixes based on upgrading a laptop from 11.1R to -current
Add note about needing to start zfs because mount -a doesn't do that.
Add the word 'supported' before 'older branches' for older binaries.
Add note about options in custom config files as well.
2019-03-09 17:17:44 +00:00
Dimitry Andric
1791078b17 Set tentative merge date, and bump __FreeBSD_version. 2019-03-04 19:23:11 +00:00
Dimitry Andric
a8fe8db49a Merge ^/head r344178 through r344512. 2019-02-25 11:59:29 +00:00
Warner Losh
625bdc784e Add an UPDATING entry for the removal of drm and drm2
Also bump FreeBSD version to 1300013 since this series is a big
change.
2019-02-19 19:37:09 +00:00
Dimitry Andric
c981cbbd13 Merge ^/head r343956 through r344177. 2019-02-15 21:50:45 +00:00
Warner Losh
deb17a3ba3 Fix small typo.
Differential Review: https://reviews.freebsd.org/D19193
2019-02-14 17:04:04 +00:00
Andriy Voskoboinyk
5864456d1a Add UPDATING entry for IEEE80211_AMPDU_AGE and AH_SUPPORT_AR5416 options
removal

Notified by:	ian
2019-02-14 09:21:19 +00:00
Dimitry Andric
9e43c218d5 Merge ^/head r343807 through r343955. 2019-02-10 12:49:34 +00:00
Warner Losh
8590b14e9d Remove a few stray "All Rights Reserved." declarations on stuff I've
written.
2019-02-05 21:28:29 +00:00
Dimitry Andric
c2c227a536 Merge ^/head r343571 through r343711. 2019-02-03 11:41:43 +00:00
Konstantin Belousov
c75f49f7d8 Make iflib a loadable module.
iflib is already a module, but it is unconditionally compiled into the
kernel.  There are drivers which do not need iflib(4), and there are
situations where somebody might not want iflib in kernel because of
using the corresponding driver as module.

Reviewed by:	marius
Discussed with:	erj
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks
Differential revision:	https://reviews.freebsd.org/D19041
2019-01-31 19:05:56 +00:00
Dimitry Andric
0bf31f1fdc Update version numbers, and regenerate config headers for llvm, clang,
lld and lldb.  Update ObsoleteFiles.inc and OptionalObsoleteFiles.inc.
2019-01-20 18:34:30 +00:00
John Baldwin
7f124c950a Update the note about the need for COMPAT_FREEBSD<n> kernel options.
Rather than mentioning the requirement for 4.x binaries but not
explaining why (it was assuming an upgrade from 4.x to 5.0-current),
explain when compat options are needed (for running existing host
binaries) in a more general way while using a more modern example
(COMPAT_FREEBSD11 for 11.x binaries).  While here, explicitly mention
that a GENERIC kernel should always work.

Reported by:	Robert Huff <roberthuff@rcn.com>
Reviewed by:	imp
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D18740
2019-01-15 18:20:20 +00:00
Rebecca Cran
83a41dd0ef Add UPDATING entry for r342635.
Sponsored by:	Netflix
2018-12-31 00:15:05 +00:00
Rick Macklem
d493fe42f9 Add an UPDATING message for r342286. 2018-12-20 22:26:54 +00:00
Warner Losh
beab3c4bf4 Fix the date
The first part of the mips pruning has been commited. This part
is uncontested. Fix the date in the UPDATING file to reflect when
I made the commit. The contested parts will be committed (or not)
once those discussions complete.
2018-12-19 22:56:31 +00:00
Warner Losh
31733a7d2e Remove support for running 32-bit kernels on 64-bit hardware.
This was useful in bring up. However, it causes more issues than the
support is worth (64-bit atomics being chief among them).

Discussed on: freebsd-mips@
Differential Revision: https://reviews.freebsd.org/D18543
2018-12-19 22:54:29 +00:00
Warner Losh
0bb183ed8d Remove support for the now very old SiByte MIPS platform. It's not
relevant and is unused. It's also getting in the way of progress in
some admittedly minor ways. Better to retire it to reduce the burden
on the project.

Discussed on: freebsd-mips@
Differential Revision: https://reviews.freebsd.org/D18543
2018-12-19 22:54:03 +00:00
George V. Neville-Neil
53fc043d41 Remove, the now very outdated, timed.
Submitted by:	Kyle Spiers ksspiers at gmail
Reviewed by:	bcr,brooks,bz,sbruno
Relnotes:	yes
Differential Revision:	https://reviews.freebsd.org/D18505
2018-12-15 21:34:40 +00:00
Dimitry Andric
70f308d0f5 Fix dates that I set into the future incorrectly.
Noticed by:		ler
2018-12-13 06:59:55 +00:00
Dimitry Andric
2bf1d8b75f Set tentative merge date, and add UPDATING note. 2018-12-11 17:39:49 +00:00
Marius Strobl
b34bb3bf03 - Add a belated UPDATING entry for the ixlv(4) -> iavf(4) rename in r339338.
- Likewise, add ixlv.4.gz to OLD_FILES,
- and link if_ixlv.ko to if_iavf.ko in order to aid a bit in the transition.
2018-11-27 12:11:16 +00:00
Ed Maste
df27a97e56 UPDATING: add note for r340984 (ld.bfd removal)
Sponsored by:	The FreeBSD Foundation
2018-11-26 17:22:23 +00:00
Andrew Turner
30c5db2b88 Enable the BSD crtbegin/crtend by default.
It has passed an exp run on amd64 and i386, and has testing on arm64. On
other architectures it is expected to run, however it can be disabled by
building world with -DWITHOUT_BSD_CRTBEGIN.

Sponsored by:	DARPA, AFRL
2018-11-23 16:45:07 +00:00
Stefan Eßer
1894626876 Prepare move of ctm from base to a port (misc/ctm) by:
- Adding a note to UPDATING
- Adding a note to the history section of the manpage ctm.1
- Adding a message printed to STDERR to the ctm program

This version is meant for release in FreeBSD-12.0 and should remain in
FreeBSD-12 over its life-time.

A follow-up commit will remove ctm from -CURRENT after the MFC to 12
has happened.

Approved by:	imp, rgrimes, bcr (man-page)
MFC after:	3 days
Relnotes:	yes
Differential Revision:	https://reviews.freebsd.org/D17969
2018-11-14 08:45:48 +00:00
Ben Woods
9c66c1df48 Add UPDATING entry for newsyslog.conf changes introduced by r340318
Approved by:	cem
Differential Revision:	https://reviews.freebsd.org/D17936
2018-11-10 16:58:07 +00:00
Warner Losh
468002c56c Add updating entry for DRM
Update messaging for which drm module to install. Add guidance on what
hardware is supported (which should be copied into the release
notes). Note: the in tree drivers are abandonware. There has been no
organized support for them for many years, and the plan is to still
remove them for all but arm once the transition to drm-*kmod is
complete. Also note that WITHOUT_MODULE_DRM and WITHOUT_MODULE_DRM2
should generally be added to src.conf for anybody using the drm-*kmod
ports. That will become default in 13 soon, however.

Approved by: FreeBSD Graphics Team
Relnotes: Yes
MFC After: 3 days
Differential Revision: https://reviews.freebsd.org/D17451
2018-10-20 19:14:46 +00:00
Glen Barber
b958317950 - Update head to 13.0-CURRENT.
- Bump MACHINE_TRIPLE, TARGET_TRIPLE, FBSD_MAJOR, FBSD_CC_VER,
  FREEBSD_CC_VERSION, OS_VERSION.
- Update comment in UPDATING regarding debugging options.
- Remove debug.witness.trace=0 from installation media.
- Bump __FreeBSD_version.

Approved by:	re (implicit)
Sponsored by:	The FreeBSD Foundation
2018-10-19 00:37:47 +00:00
Glen Barber
1da7787f71 Merge the remainder of the projects/openssl111 branch to head.
- Update OpenSSL to version 1.1.1.
- Update Kerberos/Heimdal API for OpenSSL 1.1.1 compatibility.
- Bump __FreeBSD_version.

Approved by:	re (kib)
Sponsored by:	The FreeBSD Foundation
2018-10-09 21:28:26 +00:00
Kyle Evans
532dc17243 lualoader: Create a module blacklist, add DRM modules to it
This is a step in the process of easing migration into the new world order
of DRM drivers. Strongly encourage users towards loading DRM modules via
rc.conf(5) instead of loader.conf(5) by failing the load from loader(8).
Users so inclined may wipe out the blacklist via module_blacklist="" in
loader.conf(5), and it is expected that these modules will eventually be
removed from the blacklist. They may still be loaded as dependencies of
other modules or explicitly via the loader prompt, but this should not be a
major problem.

Approved by:	re (rgrimes)
Relnotes:	yes
Differential Revision:	https://reviews.freebsd.org/D16914
2018-10-07 01:53:43 +00:00