FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F12.0 2020-01-28T18:55:25Z 2020-01-28T18:55:25Z Gordon Tetlow gordon@FreeBSD.org 2020-01-28T18:55:25Z urn:sha1:8540c2ad8572b163d3a4cafee9f19933bf81a46a Reported by: Duncan Overbruck Approved by: so Security: FreeBSD-SA-20:01.libfetch Security: CVE-2020-7450 2020-01-28T18:53:14Z Gordon Tetlow gordon@FreeBSD.org 2020-01-28T18:53:14Z urn:sha1:792e2e88f57e5243c24c6df77d49b4efcd95ee43 Submitted by: Kyle Evans Approved by: so Security: FreeBSD-EN-20:01.ssp 2019-07-03T00:00:39Z Gordon Tetlow gordon@FreeBSD.org 2019-07-03T00:00:39Z urn:sha1:3f0c9ee125f29b7735cef23eaea90a06366b96a6 Approved by: so Approved by: re (implicit) Security: FreeBSD-SA-19:09.iconv 2018-12-07T00:00:12Z Glen Barber gjb@FreeBSD.org 2018-12-07T00:00:12Z urn:sha1:4ba619efbdd2476fb4ac075c6728e17ee02d6bcd - 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 2018-11-22T04:39:06Z Kyle Evans kevans@FreeBSD.org 2018-11-22T04:39:06Z urn:sha1:803e875cdcba34f0debc6d9ddd9512279f1836d6 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. bectl -r tank/ROOT create -e default upgrade bectl -r tank/ROOT mount upgrade /mnt 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. Differential Revision: https://reviews.freebsd.org/D18029 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. Approved by: re (gjb) 2018-11-21T03:22:37Z Mateusz Guzik mjg@FreeBSD.org 2018-11-21T03:22:37Z urn:sha1:dbea3640aa91390f1a2010e6261c4ec1289696fa hwpmc: limit wait for user callchain collection to 1 tick Add aditional counter descriptions to AMD 0x17 Approved by: re (rgrimes) 2018-11-20T18:14:30Z Mateusz Guzik mjg@FreeBSD.org 2018-11-20T18:14:30Z urn:sha1:e6d818ee28bed32a9a0fdbd315622410437d71f7 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 Approved by: re (gjb) 2018-11-15T19:06:07Z Alan Somers asomers@FreeBSD.org 2018-11-15T19:06:07Z urn:sha1:5c1fe7584062c4d9fba6f4ef9236b73a0e99287b 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 2018-11-15T16:03:52Z Kyle Evans kevans@FreeBSD.org 2018-11-15T16:03:52Z urn:sha1:2210ae49651495adfc09ae404412ba843a9d939f The previously activated BE should have canmount=noauto set on it upon activation of the new BE, but we previously did not touch canmount on either old or new BE. PR: 233113 Approved by: re (gjb) 2018-11-08T03:24:24Z Kyle Evans kevans@FreeBSD.org 2018-11-08T03:24:24Z urn:sha1:12da6be5ad9a8bd1e6e19ddbb4b74810503535fb Approved by: re (rgrimes)