MFC r337983, r338044:
Add pthread_get_name_np(3).

MFV r338288: Unblock speculative prefetcher also on pool creation.

Fix at r331950 appeared to be incomplete, fixing only case of pool
import, but not pool creation, leaving prefetcher still blocked for
newly created pools.

MFC r337926:
Add partial documentation for dtrace(1)'s -x configuration options.

MFC r338183, r338183:

pfctl: Improve set skip handling for groups

Rely on the kernel to appropriately mark group members as skipped.
Once a group is skipped we can clear the update flag on all the members.

PR: 229241
Submitted by: Andreas Longwitz <longwitz AT incore.de>

MFC r332968:
Add a UMA zone flag to disable the use of buckets.

MFC r333280:
Style.

MFC r337965:
  capsicum: allow the setproctitle(3) function in capability mode

  Capsicum in past allowed to change the process title.
  This was broken with r335939.

  PR:           230584
  Submitted by: Yuichiro NAITO <naito.yuichiro@gmail.com>
  Reported by:  ian@niw.com.au
  MFC after:    1 week

MFC r337505, r337865, r337869: dd status=progress

r337505:
dd: add status=progress support

This reports the current status on a single line every second, mirroring
similar functionality in GNU dd, and carefully interacts with SIGINFO.

PR: 229615

r337865:
dd: Incorporate some changes from imp for status=progress

Notable changes from what landed in r337505:
- sigalarm handler isn't setup unless we're actually using it
- Humanized versions of the amount of data transferred in the progress
  update

r337869:
dd(1): Kill off duplicate progress definition following r337865

MFC r338142:
Set arc_kmem_cache_reap_retry_ms to 0 and make it configurable.

MFC r337736:
  Restore ability to send ICMP and ICMPv6 redirects.

  It was lost when tryforward appeared. Now ip[6]_tryforward will be enabled
  only when sending redirects for corresponding IP version is disabled via
  sysctl. Otherwise will be used default forwarding function.

  PR: 221137

MFC r337714:
Prevent some parallel swap-ins, rate-limit swapper swap-ins.

MFC r336086:

  Use the FQDN in the newsyslog log message when RFC 5424 is enabled.

  The RFC 5424 spec mentions that logging FQDNs over short hostnames is
  preferred. Alter this code, so that the hostname doesn't get truncated
  on startup. Keep track of the length of the short hostname, so that
  fprintf() can do the truncation where necessary.

MFC r338105: Remove extra M_ZERO from NG_MKRESPONSE() argument.

NG_MKRESPONSE() sets M_ZERO by itself.

Submitted by: Dmitry Luhtionov <dmitryluhtionov@gmail.com>

MFC r338201: increase heap size during "loader" on sparc64

Increase the size of the heap size available on sparc64 during
operation of "loader".  The dramatic increase in size of
SPA_MAXBLOCKSIZE in r304321 causes the heap space to be exhausted,
so malloc() fails, ultimately leading to a memcpy() with a
destination of 0x0.

MFC r338038: Extending the delay cycles to give the codec more time to pump ADC data across the AC-link.

Without this patch, some CS4614 cards will need users to reload the driver manually or
the hardware won't be initialised properly. Something like:

# kldload snd_csa
# kldunload snd_csa
# kldload snd_csa

Tested with: Terratec SiXPack 5.1+

MFC r336420,336433,336593,336621,336622,336624,337394,337401,338141

Teach the EC2 AMI upload code to:
* Mark EBS snapshots as public,
* Announce new AMIs to an SNS topic, and
* Place the SVN branch and revision into the AMI "description".

MFC 338013: bsnmpd(8): fix and optimize interface description processing

* correctly prepare a buffer to obtain interface description from a kernel
  and truncate long description instead of dropping it altogether and
  spamming logs;
* skip calling strlen() for each description and each SNMP request
  for MIB-II/ifXTable's ifAlias.
* teach bsnmpd to allocate memory dynamically for interface descriptions
  to decrease memory usage for common case and not to break
  if long description occurs;

PR: 217763
Reviewed by: harti and others
Differential Revision: https://reviews.freebsd.org/D16459

MFC: r337438
Allow newnfs_request() to retry all callback RPCs with an NFSERR_DELAY reply.

The code in newnfs_request() retries RPCs that get a reply of NFSERR_DELAY,
but exempts certain NFSv4 operations. However, for callback RPCs, there
should not be any exemptions at this time. The code would have erroneously
exempted the CBRECALL callback, since it has the same operation number as
the CLOSE operation.
This patch fixes this by checking for a callback RPC (indicated by clp != NULL)
and not checking for exempt operations for callbacks.
This would have only affected the NFSv4 server when delegations are enabled
(they are not enabled by default) and the client replies to CBRECALL with
NFSERR_DELAY. This may never actually happen.
Spotted during code inspection.

Fix the BEAGLEBONE image build on stable/11.

r336726 merges r336598, r336599, r336600, and r336721, however
there was a mismerge in the BEAGLEBONE.conf where two references
to UFSMOUNT remained.

This is a direct commit to stable/11, as svn:mergeinfo had already
been recorded.

Sponsored by: The FreeBSD Foundation

MFC r337773, r337838, r338112, r338202:
Fixes for early EFIRT usage on amd64.

Activate vmspace0 pmap, not kernel_pmap.  Use special version of the
pmap activation code, pmap_activate_boot().  Ensure that PCID state for
the vmspace0 pmap is valid early.

MFC r337981:
Reorder alphabetically.

MFC r337906: Document KERNCONFDIR

MFC r338020: res_find: Fix fallback logic

The fallback logic was broken if hints were found in multiple environments.
If we found a hint in either the loader environment or the static
environment, fallback would be incremented excessively when we returned to
the environment-selection bits. These checks should have also been guarded
by the fbacklvl checks. As a result, fbacklvl could quickly get to a point
where we skip either the static environment and/or the static hints
depending on which environments contained valid hints.

The impact of this bug is minimal, mostly affecting mips boards that use
static hints and may have hints in either the loader environment or the
static environment.

There may be better ways to express the searchable environments and
describing their characteristics (immutable, already searched, etc.) but
this may be revisited after 12 branches.

MFC r337500:
Use the right variable when updating interface routes.

PR: 229807

MFC r337536:
  If -q flag is specified, do not complain when we are trying to delete
  nonexistent NAT instance or nonexistent rule.

  This allows execute batched `delete` commands and do not fail when
  found nonexistent rule.

MFC r337574:
  Restore the behaviour changed in r337536, when bad `ipfw delete` command
  returns error.

  Now -q option only makes it quiet. And when -f flag is specified, the
  command will ignore errors and continue executing with next batched
  command.

Obtained from: Yandex LLC
Sponsored by: Yandex LLC

MFC r338120: config(8): Allow escape-quoted empty strings

For use with things like BOOT_TAG=\"\" -- there are valid reasons to allow
empty strings, especially as these are usually being passed through as
options. The same argument could perhaps be made for the unquoted
variant in things like MODULES_OVERRIDE="", but it's not immediately clear
that this is an issue so I've left it untouched.

MFC r337615:

Pull in r338481 from upstream llvm trunk (by Chandler Carruth):

  [x86] Fix a really subtle miscompile due to a somewhat glaring bug in
  EFLAGS copy lowering.

  If you have a branch of LLVM, you may want to cherrypick this. It is
  extremely unlikely to hit this case empirically, but it will likely
  manifest as an "impossible" branch being taken somewhere, and will be
  ... very hard to debug.

  Hitting this requires complex conditions living across complex
  control flow combined with some interesting memory (non-stack)
  initialized with the results of a comparison. Also, because you have
  to arrange for an EFLAGS copy to be in *just* the right place, almost
  anything you do to the code will hide the bug. I was unable to reduce
  anything remotely resembling a "good" test case from the place where
  I hit it, and so instead I have constructed synthetic MIR testing
  that directly exercises the bug in question (as well as the good
  behavior for completeness).

  The issue is that we would mistakenly assume any SETcc with a valid
  condition and an initial operand that was a register and a virtual
  register at that to be a register *defining* SETcc...

  It isn't though....

  This would in turn cause us to test some other bizarre register,
  typically the base pointer of some memory. Now, testing this register
  and using that to branch on doesn't make any sense. It even fails the
  machine verifier (if you are running it) due to the wrong register
  class. But it will make it through LLVM, assemble, and it *looks*
  fine... But wow do you get a very unsual and surprising branch taken
  in your actual code.

  The fix is to actually check what kind of SETcc instruction we're
  dealing with. Because there are a bunch of them, I just test the
  may-store bit in the instruction. I've also added an assert for
  sanity that ensure we are, in fact, *defining* the register operand.
  =D

Noticed by: kib

MFC r338016:
Print L1D FLUSH feature.

MFC r338051:
Provide set_constraint_handler_s(3) man page.

MFC r338049:
Clarify that memset_s(3) requires __STDC_WANT_LIB_EXT1__ for visibility.
Fix typos and other nits.

MFC r338048:
Use tab for indent.

MFC r337728: (committed by jilles)
printf: Add test for width and precision in %b format

PR:  229641

MFC r337456:
msdosfs: fixes for Undefined Behavior.

These were found by the Undefined Behaviour GsoC project at NetBSD:

Do not change signedness bit with left shift.
While there avoid signed integer overflow.
Address both issues with using unsigned type.

msdosfs_fat.c:512:42, left shift of 1 by 31 places cannot be represented
in type 'int'
msdosfs_fat.c:521:44, left shift of 1 by 31 places cannot be represented
in type 'int'
msdosfs_fat.c:744:14, left shift of 1 by 31 places cannot be represented
in type 'int'
msdosfs_fat.c:744:24, signed integer overflow: -2147483648 - 1 cannot be
represented in type 'int [20]'
msdosfs_fat.c:840:13, left shift of 1 by 31 places cannot be represented
in type 'int'
msdosfs_fat.c:840:36, signed integer overflow: -2147483648 - 1 cannot be
represented in type 'int [20]'

Detected with micro-UBSan in the user mode.

Hinted from: NetBSD (CVS 1.33)

MFC r338047:

The bucket index is subtracted by one at lines 2304 and 2314.  When 0 it
becomes -1, except these are unsigned integers, so they become very large
numbers. Thus are always larger than the maximum bucket; the hash table
insertion fails causing NAT to fail.

This commit ensures that if the index is already zero it is not reduced
prior to insertion into the hash table.

PR: 208566

MFC r338046:

Add handy DTrace probes useful in diagnosing NAT issues. DTrace probes
are situated next to error counters and/or in one instance prior to the
-1 return from various functions. This was useful in diagnosis of
PR/208566 and will be handy in the future diagnosing NAT failures.

PR: 208566

MFC r338045:

Expose np (nat_t - an entry in the nat table structure) in the DTrace
probe when nat fails (label badnat). This is useful in diagnosing
failed NAT issues and was used in PR/208566.

PR: 208566

MFC: r336839
Modify the NFSv4.1 server so that it allows ReclaimComplete as done by ESXi 6.7.

I believe that a ReclaimComplete with rca_one_fs == TRUE is only
to be used after a file system has been transferred to a different
file server.  However, RFC5661 is somewhat vague w.r.t. this and
the ESXi 6.7 client does both a ReclaimComplete with rca_one_fs == TRUE
and one with ReclaimComplete with rca_one_fs == FALSE.
Therefore, just ignore the rca_one_fs == TRUE operation and return
NFS_OK without doing anything instead of replying NFS4ERR_NOTSUPP.
This allows the ESXi 6.7 NFSv4.1 client to do a mount.
After discussion on the NFSv4 IETF working group mailing list, doing this
along with setting a flag to note that a ReclaimComplete with rca_one_fs TRUE
was an appropriate way to handle this.
The flag that indicates that a ReclaimComplete with rca_one_fs == TRUE was
done may be used to disable replies of NFS4ERR_GRACE for non-reclaim
state operations in a future commit.

This patch along with r332790, r334492 and r336357 allow ESXi 6.7 NFSv4.1 mounts
work ok. ESX 6.5 NFSv4.1 mounts do not work well, due to what I believe are
violations of RFC-5661 and should not be used.

MFC r337422:
libc: fix cases of undefined behavior.

These were found by the Undefined Behavior GsoC project at NetBSD:

Avoid undefined behavior in ftok(3)

Do not change the signedness bit with a left shift operation.
Cast to unsigned integer to prevent this.

ftok.c:56:10, left shift of 123456789 by 24 places cannot be represented
in type 'int'
ftok.c:56:10, left shift of 4160 by 24 places cannot be represented in
type 'int'

Avoid undefined behavior in an inet_addr.c

Do not change the signedness bit with a left shift operation.
Cast to unsigned integer to prevent this.

inet_addr.c:218:20, left shift of 131 by 24 places cannot be represented
in type 'int'

Detected with micro-UBSan in the user mode.

Obtained from: NetBSD

MFC r337410:

Remove redundant and incorrect default definition of AF_INET6. AF_INET6
is defined in sys/socket.h where it's defined as 28.

A bit of trivia: On NetBSD AF_INET6 is defined as 24. On Solaris it is
defined as 26. This is probably why Darren defaulted to 26, because
ipfilter was originally written for SunOS 4 and Solaris many moons ago.

MFC boot tagging support:  r337518, r337544-r337546, r337548,
r337579-r337580, r337952

This is equivalent to what's in head, except the default is an empty boot
tag string so that nothing gets output by default.

r337518:
kern: Add a BOOT_TAG marker at the beginning of boot dmesg

From the "newly licensed to drive" PR department, add a BOOT_TAG marker (by
default, --<<BOOT>>--, to the beginning of each boot's dmesg. This makes it
easier to do textproc magic to locate the start of each boot and, of
particular interest to some, the dmesg of the current boot.

The PR has a dmesg(8) component as well that I've opted not to include for
the moment- it was the more contentious part of this PR.

bde@ also made the statement that this boot tag should be written with an
ordinary printf, which I've- for the moment- declined to change about this
patch to keep it more transparent to observer of the boot process.

PR: 43434
Submitted by: dak <aurelien.nephtali@wanadoo.fr> (basically rewritten)

r337544:
msgbuf: Light detailing (const'ify and bool'itize)

r337545:
BOOT_TAG: Make a config(5) option, expose as sysctl and loader tunable

BOOT_TAG lived shortly in sys/msgbuf.h, but this wasn't necessarily great
for changing it or removing it. Move it into subr_prf.c and add options for
it to opt_printf.h.

One can specify both the BOOT_TAG and BOOT_TAG_SZ (really, size of the
buffer that holds the BOOT_TAG). We expose it as kern.boot_tag and also add
a loader tunable by the same name that we'll fetch upon initialization of
the msgbuf.

This allows for flexibility and also ensures that there's a consistent way
to figure out the boot tag of the running kernel, rather than relying on
headers to be in-sync.

Prodded super-super-lightly by: imp

r337546:
subr_prf: Use "sizeof current_boot_tag" instead

r337548:
subr_prf: style(9) the sizeof

Reported by: jkim, ian

r337579:
boot tagging: minor fixes

msgbufinit may be called multiple times as we initialize the msgbuf into a
progressively larger buffer. This doesn't happen as of now on head, but it
may happen in the future and we generally support this. As such, only print
the boot tag if we've just initialized the buffer for the first time.

The boot tag also now has a newline appended to it for better visibility,
and has been switched to a normal printf, by requesto f bde, after we've
denoted that the msgbuf is mapped.

r337580:
subr_prf: remove think-o that had returned to local patch

Reported by: cognet

r337952:
subr_prf: Don't write kern.boot_tag if it's empty

This change allows one to set kern.boot_tag="" and not get a blank line
preceding other boot messages. While this isn't super critical- blank lines
are easy to filter out both mentally and in processing dmesg later- it
allows for a mode of operation that matches previous behavior.

I intend to MFC this whole series to stable/11 by the end of the month with
boot_tag empty by default to make this effectively a nop in the stable
branch.

MFC r337969:

pf: Limit the maximum number of fragments per packet

Similar to the network stack issue fixed in r337782 pf did not limit the number
of fragments per packet, which could be exploited to generate high CPU loads
with a crafted series of packets.

Limit each packet to no more than 64 fragments. This should be sufficient on
typical networks to allow maximum-sized IP frames.

This addresses the issue for both IPv4 and IPv6.

Security: CVE-2018-5391
Sponsored by: Klara Systems

MFC r337867:

  Don't let clobber jailparam values when checking for modification of
  init-only parameters.

PR: 230487
Submitted by: Jason Mader

MFC r321316, r337860:

Fix a few typos in comments.

MFC r312770 and r337854:

After the in_control() changes in r257692, an existing address is
(intentionally) deleted first and then completely added again (so all the
events, announces and hooks are given a chance to run).

This cause an issue with CARP where the existing CARP data structure is
removed together with the last address for a given VHID, which will cause
a subsequent fail when the address is later re-added.

This change fixes this issue by adding a new flag to keep the CARP data
structure when an address is not being removed.

There was an additional issue with IPv6 CARP addresses, where the CARP data
structure would never be removed after a change and lead to VHIDs which
cannot be destroyed.

PR: 229384
Sponsored by: Rubicon Communications, LLC (Netgate)

MFC r337696: Use INCS for non-sys/ libnvpair and libzfs_core includes

While nothing was wrong with libnvpair.h, libzfs_core.h was only guarded by
MK_CDDL rather than MK_CDDL && MK_ZFS. Rather than ugl'if'ying
include/Makefile to impose the extra restriction, just move the non-sys/
includes into INCS with the respect lib builds.

This has the added bonus of allowing third party packagers to try and split
these libs out of the FreeBSD-runtime package, if they are so inclined.

The sys/ include was left alone- generally userland libraries shouldn't
install kernel headers.

MFC r337666: getopt_long(3): Document behavior, optstring leading characters

Leading '+', '-', and ':' in optstring have special meaning. We briefly
mention that the first two have special meaning in that we say
POSIXLY_CORRECT turns them off, but we don't actually document their
meaning. Add a paragraph to RETURN VALUES explaining how they control
the treatment of non-option arguments.

A leading ':' has no mention; add a note that it suppresses warnings about
missing arguments.

MFC r337524: libi386: Fix typo in pxe.h

PR: 207337

MFC r337523: libsa: exit on EOF in ngets

It was possible in some rare circumstances for ngets to behave terribly with
bhyveload and some form of redirecting user input over a pipe.

PR: 198706

MFC r337665: krb5-config build: Remove gratuitous escaping

MFC r337643:

pf: Fix 'set skip on' for groups

The pfi_skip_if() function sometimes caused skipping of groups to work,
if the members of the group used the groupname as a name prefix.
This is often the case, e.g. group lo usually contains lo0, lo1, ...,
but not always.

Rather than relying on the name explicitly check for group memberships.

Obtained from: OpenBSD (pf_if.c,v 1.62, pf_if.c,v 1.63)

MFH r337745:
Sync libarchive with vendor..

Vendor changes:
  PR #1042: validate iso9660 directory record length

MFC after: 3 days
Security: CVE-2017-14501

MFC r336570:
Enable OFED build (without extras) by default.
For stable/11, this is only done on amd64.

Relnotes: yes
Sponsored by: Mellanox Technologies

MFC r337330:
Swap in WKILLED processes.

MFC r336461: bge(4): disable MSI for BGE_ASICREV_BCM5784/BGE_CHIPREV_5784_AX
found in some MacBook Pro.

PR: 229727
Reported by: Stephan Neuhaus <sten@artdecode.de> and others
Tested by: Stephan Neuhaus <sten@artdecode.de>
Approved by: mav (mentor)

MFC: r337791

Merge OpenSSL 1.0.2p.

MFC r337230:
Verify that each frame pointer lies within the thread's kstack.

MFC r337328:
Don't check rcv sockbuf limits when sending on a unix stream socket.

PR: 181741, 212812

MFC r337569: readelf: display NT_GNU_PROPERTY_TYPE_0 note name

NT_GNU_PROPERTY_TYPE_0 in a .note.gnu.property section "contains a
program property note which describes special handling requirements
for linker and run-time loader." (from the System V Application Binary
Interface - Linux Extensions")

Intel CET uses two processor-specific program properties in
NT_GNU_PROPERTY_TYPE_0: GNU_PROPERTY_X86_FEATURE_1_IBT to indicate that
all executable sections are compatible with Indirect Branch Tracking,
and GNU_PROPERTY_X86_FEATURE_1_SHSTK to indicate that sections are
compatible with shadow stack.

A later change should add decoding of the individual properties.

MFC r337322:

Fix build of hyperv with base gcc on i386

Summary:
Base gcc fails to compile `sys/dev/hyperv/pcib/vmbus_pcib.c` for i386,
with the following -Werror warnings:

cc1: warnings being treated as errors
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c: In function 'new_pcichild_device':
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c:567: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c: In function 'vmbus_pcib_on_channel_callback':
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c:940: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c: In function 'hv_pci_protocol_negotiation':
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c:1012: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c: In function 'hv_pci_enter_d0':
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c:1073: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c: In function 'hv_send_resources_allocated':
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c:1125: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c: In function 'vmbus_pcib_map_msi':
/usr/src/sys/dev/hyperv/pcib/vmbus_pcib.c:1730: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]

This is because on i386, several casts from `uint64_t` to a pointer
reduce the value from 64 bit to 32 bit.

For gcc, this can be fixed by an intermediate cast to uintptr_t. Note
that I am assuming the incoming values will always fit into 32 bit!

Differential Revision: https://reviews.freebsd.org/D15753

MFC r337570-r337573

r337570:
bwi(4): Set ic->ic_softc before bwi_getradiocaps to avoid bad deref

r337571:
net80211: Drain ageq before cleaning it up.

The comment above ieee80211_ageq_cleanup specifically notes that the queue
is assumed to be empty, and in order to make it so, ieee80211_ageq_drain
must be used.

r337572:
ieee8021_node: fix whitespace issues

r337573:
ath: Minor style cleanups

device_printf => DPRINTF and two whitespace adjustments

MFC r336184: net80211: Fix ifdetach w/o ifattach, small whitespace cleanup

As the comment says, ifdetach might be called during the course of driver
detach if initialization failed. This shouldn't be a total failure, though,
we just have nothing to do there.

This has been modified slightly from Augustin's original commit to move the
bail-out slightly earlier since the ic wouldn't have been added to the
ic list in the first place, and a comment has been added describing when
this might be an issue.

MFC r335785, r335812

r335785 by eadler:
iwn: Correct Centrino Advanced-N 6235 constants

The iwn 6235 is a 2x2 device (see
https://ark.intel.com/products/66890/Intel-Centrino-Advanced-N-6235-Dual-Band)

r335812 by eadler:
iwn: Add the missing IWN_SDID_6035_5 subdevice

MFC r337558, r337560

r337558:
Identify the return value (rval) that led to the IPv4 NAT failure
in ipf_nat_checkout() and report it in the frb_natv4out and frb_natv4in
dtrace probes.

This is currently being used to diagnose NAT failures in PR/208566. It's
rather handy so this commit makes it available for future diagnosis and
debugging efforts.

PR: 208566

r337560:
Correct a comment. Should have been detected by ipf_nat_in() not
ipf_nat_out().

MFC r337559: Makefile.inc1: Add libl to -legacy as well

libl is needed for config(8), which is a bootstrap-tool. It is possible to
build a system WITHOUT_TOOLCHAIN to exclude lex and thus, libl. We still
need to support building from this kind of host, though.

While here, group the config(8) dependencies together and add a small
explanation. These can likely both be scoped more clearly, but this will
need some further investigation.

MFC r337770:
Fix typo.

Document SA-18:09 through SA-18:11.

Sponsored by: The FreeBSD Foundation

MFC r337727:

Copy out from kernel to data, not the other way around.

Sponsored by: DARPA, AFRL

MFC r337717, r337718:

 r337717:
  Add lang/python2, lang/python3, and lang/python to GCE images
  to help avoid hard-coding 'python<MAJOR>.<MINOR>' in several
  scripts in the client-side scripts. [1]

 r337718:
  Add a space between a variable and escaped new line.

PR: 230248 [1]
Sponsored by: The FreeBSD Foundation

MFC r337469:
  Use host byte order when comparing mss values.

  This fixes tcp-setmss action on little endian machines.

  PR: 225536
  Submitted by: John Zielinski

MFC r337527:
Use atomic_fcmpset_XXX() instead of atomic_cmpset_XXX() when possible
in the LinuxKPI.

Suggested by: mjg @
Sponsored by: Mellanox Technologies

MFC r337376:
Implement current_work() function in the LinuxKPI.

Tested by: Johannes Lundberg <johalun0@gmail.com>
Sponsored by: Mellanox Technologies

MFC r337374:
Implement atomic_long_cmpxchg() function in the LinuxKPI.

Submitted by: Johannes Lundberg <johalun0@gmail.com>
Sponsored by: Mellanox Technologies

MFC r337373:
Define __poll_t type in the LinuxKPI.

Submitted by: Johannes Lundberg <johalun0@gmail.com>
Sponsored by: Mellanox Technologies

MFC r337232:
Implement ktime_add_ms() and ktime_before() in the LinuxKPI.

Submitted by: Johannes Lundberg <johalun0@gmail.com>
Sponsored by: Mellanox Technologies

MFC r337529:
Implement missing atomic_fcmpset_XXX() support for i386.

Sponsored by: Mellanox Technologies

Revert r337826: MFC of ls(1) COLORTERM honoring

It was not ready, and was much-objected-to.

Load filesystem modules associated with allow.mount permissions.

PR: 192092

MFC r331332:

  If a jail parameter isn't found, try loading a related kernel module.

PR: 192092

MFC r321649:

Remove the unused mutex since r273220.

Sponsored by: Rubicon Communications, LLC (Netgate)

MFC r317800:

Add support for the no-1-8-v and wp-inverted properties in generic SDHCI
FDT glue.

Sponsored by: Rubicon Communications, LLC (Netgate)

MFC r313911:

Spell VMXNET3_LEGACY_TX correctly.

MFC r312953:

The stf(4) interface name does not conform with the default naming
convention for interfaces, because only one stf(4) interface can exist
in the system.

This disallow the use of unit numbers different than 0, however, it is
possible to create the clone without specify the unit number (wildcard).

In the wildcard case we must update the interface name before return.

This fix an infinite recursion in pf code that keeps track of network
interfaces and groups:

1 - a group for the cloned type of the interface is added (stf in this
    case);
2 - the system will now try to add an interface named stf (instead of
    stf0) to stf group;
3 - when pfi_kif_attach() tries to search for an already existing 'stf'
    interface, the 'stf' group is returned and thus the group is added
    as an interface of itself;

This will now cause a crash at the first attempt to traverse the groups
which the stf interface belongs (which loops over itself).

Obtained from: pfSense
Sponsored by: Rubicon Communications, LLC (Netgate)

MFC r337819 (cy@): MFV r337818: WPA: Ignore unauthenticated encrypted EAPOL-Key
data

Approved by: so
Security: CVE-2018-14526
Security: FreeBSD-SA-18:11.hostapd

MFC r333919, r333922, r333944, r337442:

Update file to file 5.34 (through 5.33)

MFC r337506: ls(1): Enable colors with COLORTERM is set in the environment

COLORTERM is the de facto standard, while CLICOLOR is generally specific to
FreeBSD and ls(1).

PR: 230101

MFC r337504: apply(1): Fix magic number substitution with a magic space

Using a space as the magic character would result in problems if the command
started with a number:

- For a 'valid' number n, n < size of argv, it would erroneously get
  replaced with that argument; e.g. `apply -a ' ' -d 1rm x => `execxrm x`

- For an 'invalid' number n, n >= size of argv, it would segfault.
  e.g. `apply -a ' ' 2to3 test.py` would try to access argv[2]

This problem occurred because apply(1) would prepend "exec " to the command
string before doing the actual magic number replacements, so it would come
across "exec 2to3 1" and assume that the " 2" is also a magic number to be
replaced.

Re-work this to instead just append "exec " to the command sbuf and
workaround the ugliness. This also simplifies stuff in the process.

PR: 226948

MFC r337458, r337618:
Fix printf(1) ignores width and precision in %b format.

The precision with the conversion specifier b is specified by POSIX: see
point 7 in the reference documentation.

Include fix from jilles@ to avoid breaking the testsuite.

Reference: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html

PR: 229641
Reported by: Rudolf Cejka
Submitted by: Garrett D'Amore (illumos)

MFC r336203, r336499, r336501-r336502, r336506, r336510, r336512-r336513, r336515, r336528-r336531

r336203:
MFV r324714:

Update wpa 2.5 --> 2.6.

r336499:
MFV: r336485

Address: hostapd: Avoid key reinstallation in FT handshake

Obtained from: https://w1.fi/security/2017-1/\
rebased-v2.6-0001-hostapd-Avoid-key-\
reinstallation-in-FT-handshake.patch

r336501:
MFV: r336486

Prevent reinstallation of an already in-use group key.
Upline git commit cb5132bb35698cc0c743e34fe0e845dfc4c3e410.

Obtained from: https://w1.fi/security/2017-1/\
rebased-v2.6-0002-Prevent-reinstallation-\
of-an-already-in-use-group-ke.patch

r336502:
MFV r336487:

Import upline security patch: Extend protection of GTK/IGTK
reinstallation of WNM-Sleep Mode cases.  This git commit
87e2db16bafcbc60b8d0016175814a73c1e8ed45.

This commit is is simply a pops change as r324696 already plugged
this vulnerability. To maintain consistency with the vendor branch
props will be changed.

Obtained from: https://w1.fi/security/2017-1/\
rebased-v2.6-0003-Extend-protection-of-GTK-IGTK-\
reinstallation-of-WNM-.patch

r336506:
MFV r336490:

Prevent installation of an all-zero TK.
This is also upline git commit 53bb18cc8b7a4da72e47e4b3752d0d2135cffb23.

Obtained from: https://w1.fi/security/2017-1/\
rebased-v2.6-0004-Prevent-installation-\
of-an-all-zero-TK.patch

r336510:
MFV r336493:

Fix PTK rekeying to generate a new ANonce.
This is also upline git commit 0adc9b28b39d414d5febfff752f6a1576f785c85.

This commit is a NOP, just changing props as the heavy lifting was
done by r324696. This just brings us into line with the vendor branch.

Obtained from: https://w1.fi/security/2017-1/\
rebased-v2.6-0005-Fix-PTK-rekeying-to-\
generate-a-new-ANonce.patch

r336512:
MFV r336494:

TDLS: Reject TPK-TK reconfiguration.
This is also upline git commmit ff89af96e5a35c86f50330d2b86c18323318a60c.

Once again this is a NOP as this is a props change to sync up with
the vendor branch. The real commit is in r324696.

Obtained from: https://w1.fi/security/2017-1/\
rebased-v2.6-0006-TDLS-Reject-TPK-TK-\
reconfiguration.patch

r336513:
MFV r336495:

Another props change. The real work was done by r324696. We're simply
syncing up with the vendor branch again.

mport upline security patch:  WNM: Ignore WNM-Sleep Mode Request in
wnm_sleep_mode=0 case. This is also upline git commit
114f2830d2c2aee6db23d48240e93415a256a37c.

Obtained from: https://w1.fi/security/2017-1/\
rebased-v2.6-0007-WNM-Ignore-WNM-Sleep-Mode-\
Response-without-pending-r.patch

r336515:
MFV r336496:

A props change to sync up with the vendor branch. The real work was
done by r324696.

FILS: Do not allow multiple (Re)Association Response frames.
This is also upline git commit e760851176c77ae6de19821bb1d5bf3ae2cb5187.

Obtained from: https://w1.fi/security/2017-1/\
rebased-v2.6-0008-FT-Do-not-allow-multiple-\
Reassociation-Response-fram.patch

r336528:
Revert r336501. It was a of the wrong rev from the vendor branch.

r336529:
MFV: r336486

Prevent reinstallation of an already in-use group key.
Upline git commit cb5132bb35698cc0c743e34fe0e845dfc4c3e410.

Obtained from: https://w1.fi/security/2017-1/\
rebased-v2.6-0002-Prevent-reinstallation-\
of-an-already-in-use-group-ke.patch

r336530:
To reduce our diff between our sources and our upline, sync up
with upline. Also making it easier to read.

Obtained from: diffing base with ports

r336531:
Remove a redundant declaration.

While at it add a blank line, conforming with the convention
used in this file.

MFC r337520: Fix WITHOUT_LOADER_GELI (gptboot) and isoboot in general

gptboot was broken when r316078 added the LOADER_GELI_SUPPORT #ifdef to
not pass geliargs via __exec.  KARGS_FLAGS_EXTARG must not be used if we're
not going to pass an additional argument to __exec.

PR: 228151

ubldr: Bump heap size, 1MB -> 2MB

1MB was leaving very little margin in some of the worse-case scenarios with
lualoader. 2MB is still low enough that we shouldn't have any problems with
UBoot-supported boards.

MFC r337788:
  Update the inet(4) and inet6(4) man pages to reflect the changes made
  to the reassembly code in r337778, r337780, r337781, r337782, and
  r337783.

Approved by: so
Security: FreeBSD-SA-18:10.ip
Security: CVE-2018-6923

MFC r337787:
  Lower the default limits on the IPv6 reassembly queue.

  Currently, the limits are quite high. On machines with millions of
  mbuf clusters, the reassembly queue limits can also run into
  the millions. Lower these values.

  Also, try to ensure that no bucket will have a reassembly
  queue larger than approximately 100 items. This limits the cost to
  find the correct reassembly queue when processing an incoming
  fragment.

  Due to the low limits on each bucket's length, increase the size of
  the hash table from 64 to 1024.

Approved by: so
Security: FreeBSD-SA-18:10.ip
Security: CVE-2018-6923

MFC r337786:
  Lower the default limits on the IPv4 reassembly queue.

  In particular, try to ensure that no bucket will have a reassembly
  queue larger than approximately 100 items. This limits the cost to
  find the correct reassembly queue when processing an incoming
  fragment.

  Due to the low limits on each bucket's length, increase the size of
  the hash table from 64 to 1024.

Approved by: so
Security: FreeBSD-SA-18:10.ip
Security: CVE-2018-6923

MFC r337784:
  Drop 0-byte IPv6 fragments.

  Currently, we process IPv6 fragments with 0 bytes of payload, add them
  to the reassembly queue, and do not recognize them as duplicating or
  overlapping with adjacent 0-byte fragments. An attacker can exploit this
  to create long fragment queues.

  There is no legitimate reason for a fragment with no payload. However,
  because IPv6 packets with an empty payload are acceptable, allow an
  "atomic" fragment with no payload.

Approved by: so
Security: FreeBSD-SA-18:10.ip
Security: CVE-2018-6923

MFC r337783:
  Implement a limit on on the number of IPv6 reassembly queues per bucket.

  There is a hashing algorithm which should distribute IPv6 reassembly
  queues across the available buckets in a relatively even way. However,
  if there is a flaw in the hashing algorithm which allows a large number
  of IPv6 fragment reassembly queues to end up in a single bucket, a per-
  bucket limit could help mitigate the performance impact of this flaw.

  Implement such a limit, with a default of twice the maximum number of
  reassembly queues divided by the number of buckets. Recalculate the
  limit any time the maximum number of reassembly queues changes.
  However, allow the user to override the value using a sysctl
  (net.inet6.ip6.maxfragbucketsize).

Approved by: so
Security: FreeBSD-SA-18:10.ip
Security: CVE-2018-6923

MFC r337782:
  Add a limit of the number of fragments per IPv6 packet.

  The IPv4 fragment reassembly code supports a limit on the number of
  fragments per packet. The default limit is currently 17 fragments.
  Among other things, this limit serves to limit the number of fragments
  the code must parse when trying to reassembly a packet.

  Add a limit to the IPv6 reassembly code. By default, limit a packet
  to 65 fragments (64 on the queue, plus one final fragment to complete
  the packet). This allows an average fragment size of 1,008 bytes, which
  should be sufficient to hold a fragment. (Recall that the IPv6 minimum
  MTU is 1280 bytes. Therefore, this configuration allows a full-size
  IPv6 packet to be fragmented on a link with the minimum MTU and still
  carry approximately 272 bytes of headers before the fragmented portion
  of the packet.)

  Users can adjust this limit using the net.inet6.ip6.maxfragsperpacket
  sysctl.

Approved by: so
Security: FreeBSD-SA-18:10.ip
Security: CVE-2018-6923

MFC r337781:
 Make the IPv6 fragment limits be global, rather than per-VNET, limits.

 The IPv6 reassembly fragment limit is based on the number of mbuf clusters,
 which are a global resource. However, the limit is currently applied
 on a per-VNET basis. Given enough VNETs (or given sufficient customization
 on enough VNETs), it is possible that the sum of all the VNET fragment
 limits will exceed the number of mbuf clusters available in the system.

 Given the fact that the fragment limits are intended (at least in part) to
 regulate access to a global resource, the IPv6 fragment limit should
 be applied on a global basis.

 Note that it is still possible to disable fragmentation for a particular
 VNET by setting the net.inet6.ip6.maxfragpackets sysctl to 0 for that
 VNET. In addition, it is now possible to disable fragmentation globally
 by setting the net.inet6.ip6.maxfrags sysctl to 0.

Approved by: so
Security: FreeBSD-SA-18:10.ip
Security: CVE-2018-6923

MFC r337780:
  Implement a limit on on the number of IPv4 reassembly queues per bucket.

  There is a hashing algorithm which should distribute IPv4 reassembly
  queues across the available buckets in a relatively even way. However,
  if there is a flaw in the hashing algorithm which allows a large number
  of IPv4 fragment reassembly queues to end up in a single bucket, a per-
  bucket limit could help mitigate the performance impact of this flaw.

  Implement such a limit, with a default of twice the maximum number of
  reassembly queues divided by the number of buckets. Recalculate the
  limit any time the maximum number of reassembly queues changes.
  However, allow the user to override the value using a sysctl
  (net.inet.ip.maxfragbucketsize).

Approved by: so
Security: FreeBSD-SA-18:10.ip
Security: CVE-2018-6923

MFC r337778:
  Add a global limit on the number of IPv4 fragments.

  The IP reassembly fragment limit is based on the number of mbuf clusters,
  which are a global resource. However, the limit is currently applied
  on a per-VNET basis. Given enough VNETs (or given sufficient customization
  of enough VNETs), it is possible that the sum of all the VNET limits
  will exceed the number of mbuf clusters available in the system.

  Given the fact that the fragment limit is intended (at least in part) to
  regulate access to a global resource, the fragment limit should
  be applied on a global basis.

  VNET-specific limits can be adjusted by modifying the
  net.inet.ip.maxfragpackets and net.inet.ip.maxfragsperpacket
  sysctls.

  To disable fragment reassembly globally, set net.inet.ip.maxfrags to 0.
  To disable fragment reassembly for a particular VNET, set
  net.inet.ip.maxfragpackets to 0.

Approved by: so
Security: FreeBSD-SA-18:10.ip
Security: CVE-2018-6923

MFC r337785:
Provide part of the mitigation for L1TF-VMM.

Security: CVE-2018-3646
Approved by: so (insta-MFC)