emaste [Wed, 9 Jan 2019 18:42:40 +0000 (18:42 +0000)]
MFS12 r342378: Fix a regression in the TCP handling of received segments.
When receiving TCP segments the stack protects itself by limiting
the resources allocated for a TCP connections. This patch adds
an exception to these limitations for the TCP segement which is the next
expected in-sequence segment. Without this patch, TCP connections
may stall and finally fail in some cases of packet loss.
emaste [Wed, 19 Dec 2018 18:21:07 +0000 (18:21 +0000)]
MFS12 r342228: bootpd: validate hardware type
Due to insufficient validation of network-provided data it may have been
possible for a malicious actor to craft a bootp packet which could cause
a stack buffer overflow.
admbugs: 850
Reported by: Reno Robert
Reviewed by: markj
Approved by: so
Security: FreeBSD-SA-18:15.bootpd
Sponsored by: The FreeBSD Foundation
gjb [Fri, 7 Dec 2018 00:00:12 +0000 (00:00 +0000)]
- Switch releng/12.0 from RC3 to RELEASE.
- Add the anticipated 12.0-RELEASE date to UPDATING.
- Set a static __FreeBSD_version.
- This one goes to 12.
Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation
marius [Thu, 29 Nov 2018 22:00:20 +0000 (22:00 +0000)]
MFV: r341039, MFC: r341041, MF12: r341264
Import CK as of 21d3e319407d19dece16ee317c757ffc54a452bc, which makes its
sparcv9 atomics compatible with the FreeBSD kernel by using instructions
which access the appropriate address space.
Atomic operations within the kernel must access the nucleus address space
instead of the default primary one. Without this change but the increased
use of CK in the kernel, machines started to panic after some minutes of
uptime due to an unresolvable fault in ck_pr_cas_64_value().
marius [Thu, 29 Nov 2018 21:59:09 +0000 (21:59 +0000)]
MFC: r341016, MF12: r341261
- 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.
vangyzen [Wed, 28 Nov 2018 16:58:35 +0000 (16:58 +0000)]
MFS r341147
MFC r340995
Prevent kernel stack disclosure in signal delivery
On arm64 and riscv platforms, sendsig() failed to zero the signal
frame before copying it out to userspace. Zero it.
On arm, I believe all the contents of the frame were initialized,
so there was no disclosure. However, explicitly zero the whole frame
because that fact could inadvertently change in the future,
it's more clear to the reader, and I could be wrong in the first place.
Approved by: re (gjb)
Security: similar to FreeBSD-EN-18:12.mem and CVE-2018-17155
Sponsored by: Dell EMC Isilon
emaste [Fri, 23 Nov 2018 21:08:11 +0000 (21:08 +0000)]
MFS12 r340849, r340850, r340851:
MFC r340661 (rmacklem):
r304026 added code that started statistics gathering for an operation
before the operation number (the variable called "op") was sanity checked.
This patch moves the code down to below the range sanity check for "op".
MFC r340662 (rmacklem):
nfsm_advance() would panic() when the offs argument was negative.
The code assumed that this would indicate a corrupted mbuf chain, but
it could simply be caused by bogus RPC message data.
This patch replaces the panic() with a printf() plus error return.
MFC r340663 (rmacklem):
Improve sanity checking for the dircount hint argument to
NFSv3's ReaddirPlus and NFSv4's Readdir operations. The code
checked for a zero argument, but did not check for a very large value.
This patch clips dircount at the server's maximum data size.
gjb [Fri, 23 Nov 2018 16:32:27 +0000 (16:32 +0000)]
- Update releng/12.0 from RC1 to RC2 as part of the 12.0-RELEASE
cycle.
- Update the dvd1.iso pkg(8) configuration to use the release_0
package set to populate the dvd.
Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation
emaste [Thu, 22 Nov 2018 18:59:05 +0000 (18:59 +0000)]
MF12 r340697: Introduce src.conf knob to build userland with retpoline
MFC r339511: Introduce src.conf knob to build userland with retpoline
WITH_RETPOLINE enables -mretpoline vulnerability mitigation in userland
for CVE-2017-5715.
MFC r340099: libcompat: disable retpoline when building build tools
These are built with the host toolchain which may not support retpoline.
While here, move the MK_ overrides to a separate line and sort them
alphabetically to support future changes.
MFC r340650: Avoid retpolineplt with static linking
Statically linked binaries linked with -zretpolineplt crash at startup
as lld produces a broken PLT.
MFC r340652: rescue: set NO_SHARED in Makefile
The rescue binary is built statically via the Makefile generated by
crunchgen, but that does not trigger other shared/static logic in
bsd.prog.mk - in particular
PR: 233336
Reported by: Peter Malcom (r339511), Charlie Li (r340652)
Approved by: re (kib)
Sponsored by: The FreeBSD Foundation
marius [Thu, 22 Nov 2018 16:27:30 +0000 (16:27 +0000)]
MFC: r340656, MF12: r340759
Given that the idea of D15374 was to "make memmove a first class citizen",
provide a _MEMMOVE extension of _MEMCPY that deals with overlap based on
the previous bcopy(9) implementation and use the former for bcopy(9) and
memmove(9). This addresses my D15374 review comment, avoiding extra MOVs
in case of memmove(9) and trashing the stack pointer.
tijl [Thu, 22 Nov 2018 13:12:17 +0000 (13:12 +0000)]
MFS r340757:
Fix another user address dereference in linux_sendmsg syscall.
This was hidden behind the LINUX_CMSG_NXTHDR macro which dereferences its
second argument. Stop using the macro as well as LINUX_CMSG_FIRSTHDR. Use
the size field of the kernel copy of the control message header to obtain
the next control message.
tijl [Thu, 22 Nov 2018 13:09:42 +0000 (13:09 +0000)]
MFS r340755:
Do proper copyin of control message data in the Linux sendmsg syscall.
Instead of calling m_append with a user address, allocate an mbuf cluster
and copy data into it using copyin. For the SCM_CREDS case, instead of
zeroing a stack variable and appending that to the mbuf, zero part of the
mbuf cluster directly. One mbuf cluster is also the size limit used by
the FreeBSD sendmsg syscall (uipc_syscalls.c:sockargs()).
PR: 217901
Reviewed by: kib
Approved by: re (marius)
r340507:
libbe(3): rewrite init to support chroot usage
libbe(3) currently uses zfs_be_root and locates which of its children is
currently mounted at "/". This is reasonable, but not correct in the case of
a chroot, for two reasons:
- chroot root may be of a different zpool than zfs_be_root
- chroot root will not show up as mounted at "/"
Fix both of these by rewriting libbe_init to work from the rootfs down.
zfs_path_to_zhandle on / will resolve to the dataset mounted at the new
root, rather than the real root. From there, we can derive the BE root/pool
and grab the bootfs off of the new pool. This does no harm in the average
case, and opens up bectl to operating on different pools for scenarios where
one may be, for instance, updating a pool that generally gets re-rooted into
from a separate UFS root or zfs bootpool.
While here, I've also:
- Eliminated the check for /boot and / to be on the same partition. This
leaves one open to a setup where /boot (and consequently, kernel/modules)
are not included in the boot environment. This may very well be an
intentional setup done by someone that knows what they're doing, we should
not kill BE usage because of it.
- Eliminated the validation bits of BEs and snapshots that enforced
'mountpoint' to be "/" -- this broke when trying to operate on an imported
pool with an altroot, but we need not be this picky.
Reported by: philip
Reviewed by: philip, allanjude (previous version)
Tested by: philip
Differential Revision: https://reviews.freebsd.org/D18012
r340508:
libbe(3): Rewrite be_unmount to stop mucking with getmntinfo(2)
Go through the ZFS layer instead; given a BE, we can derive the dataset,
zfs_open it, then zfs_unmount. ZFS takes care of the dirty details and
likely gets it more correct than we did for more interesting setups.
r340592:
bectl(3)/libbe(3): Allow BE root to be specified
Add an undocumented -r option preceding the bectl subcommand to specify a BE
root to operate out of. This will remain undocumented for now, as some
caveats apply:
- BEs cannot be activated in the pool that doesn't contain the rootfs
- bectl create cannot work out of the box without the -e option right now,
since it defaults to the rootfs and cross-pool cloning doesn't work like
that (IIRC)
Plumb the BE root through to libbe(3) so that some things -can- be done to
it, e.g.
this aides in some upgrade setups where rootfs is not necessarily ZFS, and
also makes it easier/possible to regression-test bectl when combined with a
file-backed zpool.
r340593:
libbe(3): Properly account for altroot when creating new BEs
Previously we would blindly copy the 'mountpoint' property, which includes
the altroot. The altroot needs to be snipped off prior to setting it on the
new BE, though, or you'll end up with a new BE and a mountpoint of /mnt with
altroot=/mnt
r340594:
bectl(8): Add some regression tests
These tests operate on a file-backed zpool that gets created in the kyua
temp dir. root and ZFS support are both required for these tests. Current
tests cover create, destroy, export/import, jail, list (kind of), mount,
rename, and jail.
List tests should later be extended to cover formatting and the different
list flags, but for now only covers basic "are create/destroy actually
reflected properly"
r340635:
libbe(3): Handle non-ZFS rootfs better
If rootfs isn't ZFS, current version will emit an error claiming so and fail
to initialize libbe. As a consumer, bectl -r (undocumented) can be specified
to operate on a BE independently of whether on a UFS or ZFS root.
Unbreak this for the UFS case by only erroring out the init if we can't
determine a ZFS dataset for rootfs and no BE root was specified. Consumers
of libbe should take care to ensure that rootfs is non-empty if they're
trying to use it, because this could certainly be the case.
Some check is needed before zfs_path_to_zhandle because it will
unconditionally emit to stderr if the path isn't a ZFS filesystem, which is
unhelpful for our purposes.
This should also unbreak the bectl(8) tests on a UFS root, as is the case in
Jenkins' -test runs.
r340636:
bectl(8) tests: attempt to load the ZFS module
Observed in a CI test image, bectl_create test will run and be marked as
skipped because the module is not loaded. The first zpool invocation will
automagically load the module, but bectl_create is still skipped. Subsequent
tests all pass as expected because the module is now loaded and everything
is OK.
marius [Wed, 21 Nov 2018 19:49:21 +0000 (19:49 +0000)]
MFC: r340495, MF12: r340739
- Restore setting the clock for devices which support the default/legacy
transfer mode only (lost with r321385). [1]
- Similarly, don't try to set the power class on MMC devices that comply
to version 4.0 of the system specification but are operated in default/
legacy transfer or 1-bit bus mode as no power class is specified for
these cases. Trying to set a power class nevertheless resulted in an -
albeit harmless - error message.
amd64: tidy up memset to have rax set earlier for small sizes
amd64: finish the tail in memset with an overlapping store
amd64: align memset buffers to 16 bytes before using rep stos
amd64: convert libc bzero to a C func to avoid future bloat
amd64: sync up libc memset with the kernel version
amd64: handle small memset buffers with overlapping stores
Fix -DNO_CLEAN amd64 build after r340463
gjb [Mon, 19 Nov 2018 15:49:39 +0000 (15:49 +0000)]
MFS12 r340630:
Remove debugging options from amd64 MINIMAL [1] and riscv GENERIC
kernel configuration files. This should have been turned off when
stable/12 branched.
Submitted by: Harry Schmalzbauer [1]
Approved by: re (kib)
Sponsored by: The FreeBSD Foundation
asomers [Thu, 15 Nov 2018 19:06:07 +0000 (19:06 +0000)]
MFC r340314:
libjail: fix handling of allow.mount.fusefs in jailparam_init
fusefs is inconsistently named. The kernel module is named "fuse", but the
mount helper is named "mount_fusefs" and the jail(8) parameter is named
"allow.mount.fusefs". Special case it in libjail.
Reviewed by: jamie
Approved by: re (gjb)
Differential Revision: https://reviews.freebsd.org/D17929
vmaffione [Thu, 15 Nov 2018 18:51:37 +0000 (18:51 +0000)]
MFC :r340436
vtnet: fix netmap support
netmap(4) support for vtnet(4) was incomplete and had multiple bugs.
This commit fixes those bugs to bring netmap on vtnet in a functional state.
Changelist:
- handle errors returned by virtqueue_enqueue() properly (they were
previously ignored)
- make sure netmap XOR rest of the kernel access each virtqueue.
- compute the number of netmap slots for TX and RX separately, according to
whether indirect descriptors are used or not for a given virtqueue.
- make sure sglist are freed according to their type (mbufs or netmap
buffers)
- add support for mulitiqueue and netmap host (aka sw) rings.
- intercept VQ interrupts directly instead of intercepting them in txq_eof
and rxq_eof. This simplifies the code and makes it easier to make sure
taskqueues are not running for a VQ while it is in netmap mode.
- implement vntet_netmap_config() to cope with changes in the number of queues.
Sponsored by: Sunny Valley Networks
Differential Revision: https://reviews.freebsd.org/D17916
Approved by: re (gjb)
projects / FreeBSD / FreeBSD.git / log