emaste [Wed, 24 Jan 2018 21:11:35 +0000 (21:11 +0000)]
uefi.8: update HISTORY and remove incomplete AUTHORS
- EFI support appeared in 5.0 for ia64
- arm64 UEFI support added in 11.0
The AUTHORS section included the folks responsible for the bulk of the
work to bring UEFI support to amd64, but missed those who did the
original work on ia64, the initial port to i386, the ports to arm64 and
arm, and have generally maintained and improved general UEFI support
since then. It's unwieldly to include everyone and would quickly become
outdated again anyhow, so just remove the AUTHORS section.
Reviewed by: manu
Discussed with: jhb
Differential Revision: https://reviews.freebsd.org/D14033
jhb [Wed, 24 Jan 2018 20:14:57 +0000 (20:14 +0000)]
Expand the software fallback for GCM to cover more cases.
- Extend ccr_gcm_soft() to handle requests with a non-empty payload.
While here, switch to allocating the GMAC context instead of placing
it on the stack since it is over 1KB in size.
- Allow ccr_gcm() to return a special error value (EMSGSIZE) which
triggers a fallback to ccr_gcm_soft(). Move the existing empty
payload check into ccr_gcm() and change a few other cases
(e.g. large AAD) to fallback to software via EMSGSIZE as well.
- Add a new 'sw_fallback' stat to count the number of requests
processed via the software fallback.
jhb [Wed, 24 Jan 2018 20:13:07 +0000 (20:13 +0000)]
Clamp DSGL entries to a length of 2KB.
This works around an issue in the T6 that can result in DMA engine
stalls if an error occurs while processing a DSGL entry with a length
larger than 2KB.
jhb [Wed, 24 Jan 2018 20:12:00 +0000 (20:12 +0000)]
Fail crypto requests when the resulting work request is too large.
Most crypto requests will not trigger this condition, but a request
with a highly-fragmented data buffer (and a resulting "large" S/G
list) could trigger it.
jhb [Wed, 24 Jan 2018 20:11:00 +0000 (20:11 +0000)]
Don't discard AAD and IV output data for AEAD requests.
The T6 can hang when processing certain AEAD requests if the request
sets a flag asking the crypto engine to discard the input IV and AAD
rather than copying them into the output buffer. The existing driver
always discards the IV and AAD as we do not need it. As a workaround,
allocate a single "dummy" buffer when the ccr driver attaches and
change all AEAD requests to write the IV and AAD to this scratch
buffer. The contents of the scratch buffer are never used (similar to
"bogus_page"), and it is ok for multiple in-flight requests to share
this dummy buffer.
jhb [Wed, 24 Jan 2018 20:08:10 +0000 (20:08 +0000)]
Reject requests with AAD and IV larger than 511 bytes.
The T6 crypto engine's control messages only support a total AAD
length (including the prefixed IV) of 511 bytes. Reject requests with
large AAD rather than returning incorrect results.
jhb [Wed, 24 Jan 2018 20:04:08 +0000 (20:04 +0000)]
Always store the IV in the immediate portion of a work request.
Combined authentication-encryption and GCM requests already stored the
IV in the immediate explicitly. This extends this behavior to block
cipher requests to work around a firmware bug. While here, simplify
the AEAD and GCM handlers to not include always-true conditions.
ae [Wed, 24 Jan 2018 19:48:25 +0000 (19:48 +0000)]
Adopt revision 1.76 and 1.77 from NetBSD:
Fix a vulnerability in IPsec-IPv6-AH, that allows an attacker to remotely
crash the kernel with a single packet.
In this loop we need to increment 'ad' by two, because the length field
of the option header does not count the size of the option header itself.
If the length is zero, then 'count' is incremented by zero, and there's
an infinite loop. Beyond that, this code was written with the assumption
that since the IPv6 packet already went through the generic IPv6 option
parser, several fields are guaranteed to be valid; but this assumption
does not hold because of the missing '+2', and there's as a result a
triggerable buffer overflow (write zeros after the end of the mbuf,
potentially to the next mbuf in memory since it's a pool).
Add the missing '+2', this place will be reinforced in separate commits.
Reported by: Maxime Villard <maxv at NetBSD.org>
MFC after: 1 week
pfg [Wed, 24 Jan 2018 17:58:48 +0000 (17:58 +0000)]
ext2fs|ufs:Unsign some values related to allocation.
When allocating memory through malloc(9), we always expect the amount of
memory requested to be unsigned as a negative value would either stand for
an error or an overflow.
Unsign some values, found when considering the use of mallocarray(9), to
avoid unnecessary casting. Also consider that indexes should be of
at least the same size/type as the upper limit they pretend to index.
hselasky [Wed, 24 Jan 2018 13:37:07 +0000 (13:37 +0000)]
Properly implement the "id" callback argument in the "idr_for_each" function
in the LinuxKPI. The old implementation assumed only one IDR layer was present.
Take additional IDR layers into account when computing the "id" value.
wma [Wed, 24 Jan 2018 07:54:05 +0000 (07:54 +0000)]
ULE: provide defaults to ts_cpu
Fix a bug when the system has no CPU 0. When created, threads were implicitly assigned to CPU 0.
This had no practical effect since a real CPU was chosen immediately by the scheduler. However,
on systems without a CPU 0, sched_ule attempted to access the scheduler queue of the "old" CPU
when assigned the initial choice of the old one. This caused an attempt to use illegal memory
and a crash (or, more usually, a deadlock). Fix this by assigned new threads to the BSP
explicitly and add some asserts to see that this problem does not recur.
np [Wed, 24 Jan 2018 05:09:21 +0000 (05:09 +0000)]
Do not generate illegal mbuf chains during IP fragment reassembly. Only
the first mbuf of the reassembled datagram should have a pkthdr.
This was discovered with cxgbe(4) + IPSEC + ping with payload more than
interface MTU. cxgbe can generate !M_WRITEABLE mbufs and this results
in m_unshare being called on the reassembled datagram, and it complains:
panic: m_unshare: m0 0xfffff80020f82600, m 0xfffff8005d054100 has M_PKTHDR
kp [Wed, 24 Jan 2018 04:29:16 +0000 (04:29 +0000)]
pf: States have at least two references
pf_unlink_state() releases a reference to the state without checking if
this is the last reference. It can't be, because pf_state_insert()
initialises it to two. KASSERT() that this is always the case.
ian [Wed, 24 Jan 2018 03:09:56 +0000 (03:09 +0000)]
Follow changes in r328307 by using new IIC_RECURSIVE flag.
The driver now ensures only one thread at a time is running in the API
functions (clock_gettime() and clock_settime()) by specifically requesting
ownership of the i2c bus without using IIC_RECURSIVE, then it does all IO
using IIC_RECURSIVE so that each individual IO operation doesn't try to
re-acquire the bus.
The other IO done by the driver happens at attach or intr_config_hooks time,
when there can't be multiple threads running with the same device instance.
So, the IIC_RECURSIVE flag can be safely ORed into the wait flags for all IO
done by the driver, because it's all either done in a single-threaded
environment, or protected within a block bounded by explict
iicbus_acquire_bus() and iicbus_release_bus() calls.
ian [Wed, 24 Jan 2018 03:09:41 +0000 (03:09 +0000)]
Follow changes in r328307 by using new IIC_RECURSIVE flag.
The driver now ensures only one thread at a time is running in the API
functions (clock_gettime() and clock_settime()) by specifically requesting
ownership of the i2c bus without using IIC_RECURSIVE, then it does all IO
using IIC_RECURSIVE so that each individual IO operation doesn't try to
re-acquire the bus.
The other IO done by the driver happens at attach or intr_config_hooks time,
when there can't be multiple threads running with the same device instance.
So, the IIC_RECURSIVE flag can be safely ORed into the wait flags for all IO
done by the driver, because it's all either done in a single-threaded
environment, or protected within a block bounded by explict
iicbus_acquire_bus() and iicbus_release_bus() calls.
ian [Tue, 23 Jan 2018 23:30:19 +0000 (23:30 +0000)]
Fix a bug introduced with recursive bus ownership support in r321584.
The recursive ownership support added in r321584 was unconditionally in
effect all the time -- whenever a given i2c slave device instance tried to
lock the i2c bus for exclusive use when it already owned the bus, the call
returned immediately without waiting. However, many i2c slave drivers use
bus ownership to enforce that only a single thread at a time can be using
the slave device. The recursive locking changes broke this use case.
Now there is a new flag, IIC_RECURSIVE, which can be mixed in with the
other flags passed to iicbus_acquire_bus() to allow drivers to indicate
when recursive locking is desired. Using the flag implies that the driver
is managing concurrent access to the device by different threads in some way.
This immediately fixes all existing i2c slave drivers except for the two
i2c RTC drivers which use the recursive locking feature; those will be
fixed in a followup commit.
jhb [Tue, 23 Jan 2018 22:48:06 +0000 (22:48 +0000)]
Remove some KSE references from ps(1).
- Simplify the description of -H to assume 1:1 threading.
- Drop 'process' from description of 'lwp' field and the corresponding
XO field name.
- Do add an expansion of LWP in the description of 'lwp' and 'nlwps'.
- Add 'tid' as an alias for the 'lwp' field.
emaste [Tue, 23 Jan 2018 22:41:13 +0000 (22:41 +0000)]
libcxxrt: Move mangled symbols out of extern "C++" in Version.map
r260553 added a number of mangled C++ symbols to Version.map inside of
an existing `extern "C++"` block.
ld.bfd 2.17.50 treats `extern "C++"` permissively and will match both
mangled and demangled symbols against the strings in the version map
block. ld.lld interprets `extern "C++"` strictly, and matches only
demangled symbols.
I believe lld's behaviour is correct. Contemporary versions of ld.bfd
also behave as lld does, so move the mangled symbols out of the
`extern "C++"` block.
PR: 225128, 185663
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
mckusick [Tue, 23 Jan 2018 22:18:45 +0000 (22:18 +0000)]
In the C library, the setting up of the group array by various
utilities is done by calling gr_addgid() for each group to be
added (usually found by traversing /etc/group) then calling the
setgroups() system call after the group set has been created.
The gr_addgid() function (helpfully?) deduplicates the addition
of group members. So, if you call it to add a group member that
already exists, it is just dropped. Because group[0] is the
effective group-ID and is over-written when a setgid program
is run, The value in group[0] is usually duplicated so that
group value is not lost when a setgid program is run.
Historically this happened because the group value indicated
in the password file also appears in /etc/group (e.g., if you
are group staff in the password file, you will also appear in
the staff line in /etc/group). But, with the addition of the
deduplication, the attempt to add group staff was lost because
it already appeared in group[0]. So, the fix is to deduplicate
starting from group[1] which allows a duplicate of the entry in
group[0], but not in later entries.
There is some confusion about the setgroups system call because in
BSD it has (always) set the entire group including the egid group
(in group[0]). However, in Linux, it skips over group[0] and starts
setting from group[1]. See this comment from linux_setgroups:
/*
* cr_groups[0] holds egid. Setting the whole set from
* the supplied set will cause egid to be changed too.
* Keep cr_groups[0] unchanged to prevent that.
*/
To make it clear what the BSD setgroups system call does, I
added the following paragraph to the setgroups(2) manual page:
The first entry of the group array (gidset[0]) is used as the effective
group-ID for the process. This entry is over-written when a setgid
program is run. To avoid losing access to the privileges of the
gidset[0] entry, it should be duplicated later in the group array.
By convention, this happens because the group value indicated in the
password file also appears in /etc/group. The group value in the
password file is placed in gidset[0] and that value then gets added a
second time when the /etc/group file is scanned to create the group set.
Reported by: Paul McMath paulm at tetrardus.net
Reviewed by: kib
MFC after: 2 weeks
kevans [Tue, 23 Jan 2018 18:03:13 +0000 (18:03 +0000)]
stand/fdt: Fallback to `name` + ".dtbo" if we fail to load `name`
This behavior also matches a Linux-ism by allowing fdt_overlays to specify
names of overlays without an extension, e.g. fdt-overlays="sunxi-h3-h5-emac"
If we fail to load the file given by a name in fdt_overlays, try again with
".dtbo" appended to it. This still allows overlays to lack .dtbo extension
if user prefers it and just adds a fallback cushion.
Future work could move this from a hard-coded ".dtbo" to a loader.conf(5)
configuration option.
imp [Tue, 23 Jan 2018 18:01:27 +0000 (18:01 +0000)]
Don't leak memory when displaying help.
Right now, we'll leak memory when we display a help topic because we
don't free t, s, d that we've just used when breaking out of the loop.
NB: coverity just reported t, but s and d also leak.
imp [Tue, 23 Jan 2018 18:01:17 +0000 (18:01 +0000)]
Fix some resource leaks.
Always free dev and fstyp before strduping new values to assign to
them. Free them at the end of the loop. This keeps them from leaking
for mal-formed /etc/fstab lines.
kevans [Tue, 23 Jan 2018 17:59:06 +0000 (17:59 +0000)]
Add /boot/overlays to runtime pkg, fix distrib-dirs METALOG generation
/boot/overlays was recently added without belonging to a package. It's only
used by bootloaders at the moment, so add it to the 'runtime' package to get
added with ubldr and friends.
Fix distrib-dirs METALOG generation while we're here. History elsewhere
seems to indicate that bapt@ fixed this to pull in all attributes from
mtrees while generating the METALOG. This fix got clobbered somewhere later,
so restore it.
gjb [Tue, 23 Jan 2018 16:41:31 +0000 (16:41 +0000)]
When CHROOTBUILD_SKIP is set, evaluate the existence of /bin/sh
within the CHROOTDIR. If it does not exist, unset CHROOTBUILD_SKIP
to prevent build failures.
Requested by: swills
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
wma [Tue, 23 Jan 2018 08:07:00 +0000 (08:07 +0000)]
PowerNV: send MSI_EOI always after MSI unmask
MSI/MSI-x interrupts are edge-triggered. If an interrupt
arrives when IRQ line is masked, it will be lost and will
never recover. Perform MSI_EOI always after unmask to give
a chance for PHB/XICS to send an interrupt again if MSI/MSI-x
pending bit is set in MSI/MSI-x BAR space.
rstone [Tue, 23 Jan 2018 03:15:44 +0000 (03:15 +0000)]
Increment the route table gen count after a modify
Increment the route table generation count after modifying a
route. This signals back to TCP connections that they need to
update their L2 caches as the gateway for their route may have
changed. This is a heavier hammer than is needed, strictly
speaking, but route changes will be unlikely enough that the
performance effects of invalidating all connection route caches
should be negligible.
rstone [Tue, 23 Jan 2018 03:15:39 +0000 (03:15 +0000)]
Reduce code duplication for inpcb route caching
Add a new macro to clear both the L3 and L2 route caches, to
hopefully prevent future instances where only the L3 cache was
cleared when both should have been.
rstone [Tue, 23 Jan 2018 03:15:39 +0000 (03:15 +0000)]
Invalidate inpcb LLE cache if cached route is invalidated
When the inpcb route cache is invalidated after a change to the
routing tables, we need to invalidate the LLE cache as well.
Previous to this change packets for the connection would continue
to use the old L2 information from the old L3 gateway, and the
packets for the connection would likely be blackholed.
jhibbits [Tue, 23 Jan 2018 02:52:12 +0000 (02:52 +0000)]
Fix 64-bit booke kernel builds after the ldscript changes
Commits r326203 and r326978 broke 64-bit booke kernels by introducing a 1MB
zero-pad between the ELF header and the start of the kernel. This didn't
cause a build failure, but caused kernels to need to be loaded into memory
1MB lower, which could easily break scripts expecting previous behavior.
This change matches the similar change made to AIM in r327358.
asomers [Mon, 22 Jan 2018 21:45:54 +0000 (21:45 +0000)]
mlock(2): correct documentation for error conditions.
The man page is years out of date regarding errors. Our implementation _does_
allow unaligned addresses, and it _does_not_ check for negative lengths,
because the length is unsigned. It checks for overflow instead.
erj [Mon, 22 Jan 2018 20:56:21 +0000 (20:56 +0000)]
ixv(4): Stop setting editing ifnet flags in ixv_if_init()
In iflib, the device-specific init() function isn't supposed to edit
the struct ifnet driver flags. If it does, it'll cause an MPASS() assert
in iflib to fail.
kevans [Mon, 22 Jan 2018 18:40:19 +0000 (18:40 +0000)]
libregex: Add a symbol map
kib points out that trying to re-use symbol versioning from libc is dirty
and wrong. The implementation in libregex is incompatible by design with the
implementation in libc. Using the symbol versions from libc can and likely
will cause confusions for linkers and bring unexpected behavior for
consumers that unwillingly (transitively) link against libregex.
pfg [Mon, 22 Jan 2018 15:55:51 +0000 (15:55 +0000)]
drm2: Basic use of mallocarray(9).
These functions deal the same type of overflows we do with mallocarray(9).
Using our mallocarray will panic, which different from the previous
behavior (returning NULL), but neither behavior is more correct.
As a sidenote, drm_calloc_large() is not currently used at all.
phk [Mon, 22 Jan 2018 07:10:30 +0000 (07:10 +0000)]
Add a skeleton Clock Manager for RPi2/3, and use that from pwm
instead of frobbing the registers directly.
As a hack the bcm2835_pwm kmod presently ignores the 'status="disabled"'
in the RPI3 DTB, assuming that if you load the kld you probably
want the PWM to work.
https://www.illumos.org/issues/8972:
'zfs holds -H' does not properly output content in scripted mode. It uses a
tab instead of two spaces, but it still pads column widths with spaces when
it should not.
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Approved by: Dan McDonald <danmcd@joyent.com>
Author: Allan Jude <allanjude@freebsd.org>
https://www.illumos.org/issues/8835:
Sequential reads not aligned to block size are not detected by ZFS
prefetcher as sequential, killing prefetch and severely hurting
performance. It is caused by dmu_zfetch() in case of misaligned
sequential accesses being called with overlap of one block.
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Allan Jude <allanjude@freebsd.org>
Approved by: Gordon Ross <gwr@nexenta.com>
Author: Alexander Motin <mav@FreeBSD.org>
https://www.illumos.org/issues/8652:
Clang and GCC prefer to use unsigned ints to store enums. With Clang, that
causes tautological comparison warnings when comparing a zfs_prop_t or
zpool_prop_t variable to the macro ZPROP_INVAL. It's likely that error
handling code is being silently removed as a result.
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Igor Kozhukhov <igor@dilos.org>
Approved by: Gordon Ross <gwr@nexenta.com>
Author: Alan Somers <asomers@gmail.com>
https://www.illumos.org/issues/8641:
"zpool clear" and "zinject -d" can both operate on specific vdevs, either
leaf or interior. However, due to an oversight, neither works on a "spare"
or "replacing" vdev. For example:
sudo zpool create foo raidz1 c1t5000CCA000081D61d0 c1t5000CCA000186235d0 spare c
1t5000CCA000094115d0
sudo zpool replace foo c1t5000CCA000186235d0 c1t5000CCA000094115d0
$ zpool status foo pool: foo
state: ONLINE
scan: resilvered 81.5K in 0h0m with 0 errors on Fri Sep 8 10:53:03 2017
config:
NAME STATE READ WRITE CKSUM
foo ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
c1t5000CCA000081D61d0 ONLINE 0 0 0
spare-1 ONLINE 0 0 0
c1t5000CCA000186235d0 ONLINE 0 0 0
c1t5000CCA000094115d0 ONLINE 0 0 0
spares
c1t5000CCA000094115d0 INUSE currently in use
$ sudo zinject -d spare-1 -A degrade foo
cannot find device 'spare-1' in pool 'foo'
$ sudo zpool clear foo spare-1
cannot clear errors for spare-1: no such device in pool
Even though there was nothing to clear, those commands shouldn't have
reported an error. by contrast, trying to clear "raidz1-0" works just fine:
$ sudo zpool clear foo raidz1-0
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Approved by: Gordon Ross <gwr@nexenta.com>
Author: Alan Somers <asomers@gmail.com>
Reviewed by: Alek Pinchuk <pinchuk.alek@gmail.com>
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Approved by: Gordon Ross <gwr@nexenta.com>
Author: Sean Eric Fagan <sef@ixsystems.com>
https://www.illumos.org/issues/8856:
arc_cksum_is_equal() calls zio_push_transform() that requires abd_t*
(second arg), but a void* is passed.
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: George Wilson <george.wilson@delphix.com>
Approved by: Gordon Ross <gwr@nexenta.com>
Author: Roman Strashkin <roman.strashkin@nexenta.com>
kevans [Mon, 22 Jan 2018 03:38:10 +0000 (03:38 +0000)]
usr.sbin/service: Fix -j to not be order dependant
The introduced -j option is highly dependant on the ordering of arguments,
and it exhibited broken behavior in some other circumstances. Fix these
issues, and simplify the feature by removing the unneessary double parsing
of options.
kevans [Mon, 22 Jan 2018 03:12:26 +0000 (03:12 +0000)]
libregex: Drop WARNS to 2 to match libc
It's become clear that my armv7 builds didn't catch all of the warnings that
other builds are picking up, drop WARNS to 2 to match libc until they're all
caught.
kevans [Mon, 22 Jan 2018 02:58:33 +0000 (02:58 +0000)]
Add missing patch from r328240
regcomp uses some libc internal collation bits that are not available in the
libregex context. It's easy enough to bring in the needed parts that can
work in a libregex world, so do so.
kevans [Mon, 22 Jan 2018 02:44:41 +0000 (02:44 +0000)]
Add libregex, connect it to the build
libregex is a regex(3) implementation intended to feature GNU extensions and
any other non-POSIX compliant extensions that are deemed worthy.
These extensions are separated out into a separate library for the sake of
not cluttering up libc further with them as well as not deteriorating the
speed (or lack thereof) of the libc implementation.
libregex is implemented as a build of the libc implementation with LIBREGEX
defined to distinguish this from a libc build. The reasons for
implementation like this are two-fold:
1.) Maintenance- This reduces the overhead induced by adding yet another
regex implementation to base.
2.) Ease of use- Flipping on GNU extensions will be as simple as linking
against libregex, and POSIX-compliant compilations can be guaranteed with a
REG_POSIX cflag that should be ignored by libc/regex and disables extensions
in libregex. It is also easier to keep REG_POSIX sane and POSIX pure when
implemented in this fashion.
Tests are added for future functionality, but left disconnected for the time
being while other testing is done.
Reviewed by: cem (previous version)
Differential Revision: https://reviews.freebsd.org/D12934
pfg [Mon, 22 Jan 2018 02:08:10 +0000 (02:08 +0000)]
Unsign some values related to allocation.
When allocating memory through malloc(9), we always expect the amount of
memory requested to be unsigned as a negative value would either stand for
an error or an overflow.
Unsign some values, found when considering the use of mallocarray(9), to
avoid unnecessary casting. Also consider that indexes should be of
at least the same size/type as the upper limit they pretend to index.
projects / FreeBSD / FreeBSD.git / log