kernel - Add per-process capability-based restrictions * This new system allows userland to set capability restrictions which turns off numerous kernel features and root accesses. These restrictions are inherited by sub-processes recursively. Once set, restrictions cannot be removed. Basic restrictions that mimic an unadorned jail can be enabled without creating a jail, but generally speaking real security also requires creating a chrooted filesystem topology, and a jail is still needed to really segregate processes from each other. If you do so, however, you can (for example) disable mount/umount and most global root-only features. * Add new system calls and a manual page for syscap_get(2) and syscap_set(2) * Add sys/caps.h * Add the "setcaps" userland utility and manual page. * Remove priv.9 and the priv_check infrastructure, replacing it with a newly designed caps infrastructure. * The intention is to add path restriction lists and similar features to improve jailess security in the near future, and to optimize the priv_check code.
<sys/types.h>: Get rid of udev_t. In a time long long ago, dev_t was a pointer, which later became cdev_t during the great cleanups, until it ended up being a uint32_t, just like udev_t. See for example the definitions of __dev_t in <sys/stat.h>. This commit cleans up further by removing the udev_t type, leaving just the POSIX dev_t type for both kernel and userland. Put it inside a _DEV_T_DECLARED to prepare for further cleanups in <sys/stat.h>.
kernel: Cleanup <sys/uio.h> issues. The iovec_free() inline very complicates this header inclusion. The NULL check is not always seen from <sys/_null.h>. Luckily only three kernel sources needs it: kern_subr.c, sys_generic.c and uipc_syscalls.c. Also just a single dev/drm source makes use of 'struct uio'. * Include <sys/uio.h> explicitly first in drm_fops.c to avoid kfree() macro override in drm compat layer. * Use <sys/_uio.h> where only enums and struct uio is needed, but ensure that userland will not include it for possible later <sys/user.h> use. * Stop using <sys/vnode.h> as shortcut for uiomove*() prototypes. The uiomove*() family functions possibly transfer data across kernel/user space boundary. This header presence explicitly mark sources as such. * Prefer to add <sys/uio.h> after <sys/systm.h>, but before <sys/proc.h> and definitely before <sys/malloc.h> (except for 3 mentioned sources). This will allow to remove <sys/malloc.h> from <sys/uio.h> later on. * Adjust <sys/user.h> to use component headers instead of <sys/uio.h>. While there, use opportunity for a minimal whitespace cleanup. No functional differences observed in compiler intermediates.
hammer - HAMMER Version 7 * Add support for version 7 which changes the CRC mechanic from the old slow CRC code to the faster ISCSI CRC code. We don't use the CRC instruction yet but ths base ISCSI CRC from FreeBSD is 6x faster than the CRC code we were using before. * Change newfs_hammer default to version 7 (for master).
hammer - Remove global VOP counters * Remove global VOP counters. These were only used for debugging. Removing these globals significantly improves concurrent VOP operations on multi-core systems, particularly multi-socket systems, by removing a cache ping-pong bottleneck. Discussed-with: Mateusz Guzik (mjg_)
build - Rewire secure, remove conflicts from libmd, libcrypt * Remove /usr/src/secure, folding all of its subsystems into /usr/src. There's no point having a /usr/src/secure any more, the system won't run without the secure stuff, the idea that some foreign actor could segregate it in order to legally download code without crypto is absurd on the modern internet, and the U.S. government stopped caring decades ago. * Remove conflicts from libmd and libcrypt. Essentially this removes the SHA*_*() and MD5_*() APIs from libmd because these APIs already exist in lib[re]ssl. The older SHA*() and MD5*() APIs are partially retained for legacy base code, but will be removed in a later stage (moved to direct-linking the needed support source). Conflicting routines in libcrypt have been renamed and internalized to be libcrypt-only. * Major rewiring of the Makefile's to support the changes.
sys/vfs/hammer: Rename HAMMER_STRUCTURE_XXX to HAMMER_IOTYPE_XXX enum hammer_io_type has existed since 2007, but the name of each element HAMMER_STRUCTURE_XXX doesn't clearly show the purpose of this enum. It should be HAMMER_IOTYPE_XXX. This isn't for ondisk structures, so it doesn't affect userspace.
sys/vfs/hammer: Add sys/vfs/hammer/hammer_crc.h HAMMER's CRC functions currently defined in sys/vfs/hammer/hammer.h could be exposed to userspace, since CRCs in various ondisk data structures are a part of HAMMER's ondisk format. In fact, userspace has a copy-pasted function from kernel code. This commit adds a new file sys/vfs/hammer/hammer_crc.h for both kernel and userspace. CRC functions are moved to this file. The reason for adding a new file instead of adding these inlined functions to hammer_{disk,btree,ioctl}.h is because crc32() requires explicit function prototype in userspace. (i.e. causes include order issues by userspace headers) Having function prototypes in hammer_{disk,btree}.h should also be avoided, because that brings in unnecessary dependencies that could be avoided for headers for ondisk format.