Kirk McKusick [Fri, 26 Jan 2018 00:58:32 +0000 (00:58 +0000)]
Refactoring of reading and writing of the UFS/FFS superblock.
Specifically reading is done if ffs_sbget() and writing is done
in ffs_sbput(). These functions are exported to libufs via the
sbget() and sbput() functions which then used in the various
filesystem utilities. This work is in preparation for adding
subperblock check hashes.
Justin Hibbits [Fri, 26 Jan 2018 00:58:02 +0000 (00:58 +0000)]
Minimum changes for ctl to build on architectures with non-matching physical and
virtual address sizes
Summary:
Some architectures use physical addresses larger than virtual. This is the
minimal changeset needed to get CAM/CTL to build on these targets. No
functional changes. More changes would likely be needed for this to be fully
functional on said platforms, but they can be made when needed.
Justin Hibbits [Fri, 26 Jan 2018 00:56:09 +0000 (00:56 +0000)]
Minimal change to build linuxkpi on architectures with physical addresses larger
than virtual
Summary:
Some architectures have physical/bus addresses that are much larger
than virtual addresses. This change just quiets a warning, as DMAP is not used
on those architectures, and on 64-bit platforms uintptr_t is the same size as
vm_paddr_t and void *.
Jung-uk Kim [Thu, 25 Jan 2018 23:38:05 +0000 (23:38 +0000)]
Add declaration of SSL_get_selected_srtp_profile() for OpenSSL.
Because there was an extra declaration in the vendor version, we locally
removed the second one in r238405 with 1.0.1c. Later, upstream fixed it in
1.0.2d but they removed the first one. Therefore, both were removed in our
version unfortunately. Now we revert to the vendor one to re-add it.
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D10525
Warner Losh [Thu, 25 Jan 2018 21:38:30 +0000 (21:38 +0000)]
Track Ref / DeRef and Hold / Unhold that da is doing to track down
leaks. We assume each source can be taken / dropped only once and
don't recurse. These are only enabled via DA_TRACK_REFS or
INVARIANTS. There appreas to be a reference leak under extreme load,
and these should help us colaberatively work it out. It also documents
better the reference / holding protocol better.
Warner Losh [Thu, 25 Jan 2018 21:38:09 +0000 (21:38 +0000)]
When devices are invalidated, there's some cases where ccbs for that
device still wind up in xpt_done after the path has been
invalidated. Since we don't always need sim or devq, add some guard
rails to only fail if we have to use them.
Nathan Whitehorn [Thu, 25 Jan 2018 18:09:26 +0000 (18:09 +0000)]
Treat DSE exceptions like DSI exceptions when generating signinfo.
Both can generate SIGSEGV, but DSEs would have put the wrong address
into the siginfo structure when the signal was delivered.
Ian Lepore [Thu, 25 Jan 2018 17:53:33 +0000 (17:53 +0000)]
Minor cleanups... Move DRIVER_MODULE() and other boilerplate stuff to the
bottom of the file, where it is in most imx5/6 drivers. Switch from an RD2
macro using bus_space_read_2() to an inline function using bus_read_2();
likewise for WR2. Use RESOURCE_SPEC_END to end the resource_spec list.
Mark Johnston [Thu, 25 Jan 2018 15:35:34 +0000 (15:35 +0000)]
Use tcpinfoh_t for TCP headers in the tcp:::debug-{drop,input} probes.
The header passed to these probes has some fields converted to host
order by tcp_fields_to_host(), so the tcpinfo_t translator doesn't do
what we want.
Kirk McKusick [Wed, 24 Jan 2018 23:57:40 +0000 (23:57 +0000)]
More throughly integrate libufs into fsck_ffs by using its cgput()
routine to write out the cylinder groups rather than recreating the
calculation of the cylinder-group check hash in fsck_ffs.
Ed Maste [Wed, 24 Jan 2018 21:39:40 +0000 (21:39 +0000)]
Add efi.8 as a man page link to uefi.8
FreeBSD and industry has been inconsistent in the use of UEFI and EFI.
They are essentially just different versions of the same specification
and are often used interchangeably. Make it easier for users to find
information by making efi(8) an alias for uefi(8).
Ed Maste [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
John Baldwin [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.
John Baldwin [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.
John Baldwin [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.
John Baldwin [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.
John Baldwin [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.
John Baldwin [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.
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
Pedro F. Giffuni [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.
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.
Wojciech Macek [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.
Navdeep Parhar [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
Kristof Provost [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 Lepore [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 Lepore [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 Lepore [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.