Merge from stable/12 r352735 and r352741

Merge all the stability fixes for the mpr and mps drivers. This fixes a
number of different panics. Unfortunately, mps now requires atomic_swap_64
to work pr

Merge from stable/12 r352735 and r352741

Merge all the stability fixes for the mpr and mps drivers. This fixes a
number of different panics. Unfortunately, mps now requires atomic_swap_64
to work properly, so it has been disabled on 32-bit powerpc and mips. The
impact should be negligible, however, since this device is difficult to
attach to those platforms.

Approved by: re@ (glen)
Relnotes: YES (for ppc32 removal)

show more ...

MFC r345350, r346441, r346765

r345350:
Rename fuse(4) to fusefs(4)

This makes it more consistent with other filesystems, which all end in "fs",
and more consistent with its mount helper, which is a

MFC r345350, r346441, r346765

r345350:
Rename fuse(4) to fusefs(4)

This makes it more consistent with other filesystems, which all end in "fs",
and more consistent with its mount helper, which is already named
"mount_fusefs".

Reviewed by: cem, rgrimes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D19649

r346441:
Use symlinks for kernel modules rather than hardlinks

When aliasing a kernel module to a different name (ie if_igb for if_em),
it's better to use symlinks than hard links. kldxref will omit entries for
the links, ensuring that the loaded module has the correct name.

Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D19979

r346765:
Don't symlink fusefs.ko to fuse.ko on PPC

Some PPC systems (PowerNV) use msdosfs for /boot, which can't handle either
symlinks or hardlinks. So on PPC, copy the module instead. This change fixes
installkernel on such systems after r345350.

Reported by: Brandon Bergren <git_bdragon.rtk0.net>
Reviewed by: jhibbits, rgrimes
MFC-With: 345350, 346441
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D19993

show more ...

MFC r343826, r346698, r349057-r349060, r349073-r349077, r349080-r349086, r349088,
r349091-r349097, r349115, r349119, r349130-r349132, r349143-r349145,
r349164-r349168, r349174, r349269-r34927

MFC r343826, r346698, r349057-r349060, r349073-r349077, r349080-r349086, r349088,
r349091-r349097, r349115, r349119, r349130-r349132, r349143-r349145,
r349164-r349168, r349174, r349269-r349273

r343826 by yuripv:
pwm.8: fix markup in synopsis, add -f description

r346698 by manu:
arm: allwinner: aw_pwm: compile it as module too

r349057:
Allow pwm(9) components to be selected individually, while 'device pwm'
still includes it all.

r349058:
In detach(), check for failure of bus_generic_detach(), only release
resources if they got allocated (because detach() gets called from attach()
to handle various failures), and delete the pwmbus child if it got created.

r349059:
Don't call pwmbus_attach_bus(), because it may not be present if this
driver is compiled into the kernel but pwmbus will be loaded as a module
when needed (and because of that, pwmbus_attach_bus() is going away in
the near future). Instead, just directly do what that function did:
register the fdt xfef handle, and attach the pwmbus.

r349060:
Handle failure to enable the clock or obtain its frequency.

r349073:
Do not include pwm.h here, it is purely a userland interface file containing
ioctl defintions for the pwmc driver. It is not part of the pwmbus interface.

r349074:
Move/rename the sys/pwm.h header file to dev/pwm/pwmc.h. The file contains
ioctl definitions and related datatypes that allow userland control of pwm
hardware via the pwmc device. The new name and location better reflects its
assocation with a single device driver.

r349075:
Remove pwmbus_attach_bus(), it no longer has any callers. Also remove a
couple prototypes for functions that never existed (and never will).

r349076:
Use device_delete_children() instead of a locally-rolled copy of it that
leaks the device-list memory.

r349077:
Add a missing #include. I suspect this used to get included via some header
pollution that was cleaned up recently, and this file got missed in the
cleanup because it's not attached to the build unless you specifically
request this device in a custom kernel config.

r349080:
Make pwmbus driver and devclass vars static; they're not mentioned in any
header file, so they can't be used outside this file anyway.

r349081:
Unwrap prototype lines so that return type and function name are on the
same line. No functional changes.

r349082:
Spell unsigned int as u_int and channel as chan; eliminates the need to wrap
some long lines.

r349083:
Give the aw_pwm driver a module version.

r349084:
Rename the channel_max method to channel_count, because that's what it's
returning. (If the channel count is 2, then the max channel number is 1.)

r349085:
Destroy the cdev on device detach. Also, make the driver and devclass
static, because nothing outside this file needs them.

r349086:
Restructure the pwm device hirearchy and interfaces.

The pwm and pwmbus interfaces were nearly identical, this merges them into a
single pwmbus interface. The pwmbus driver now implements the pwmbus
interface by simply passing all calls through to its parent (the hardware
driver). The channel_count method moves from pwm to pwmbus, and the
get_bus method is deleted (just no longer needed).

The net effect is that the interface for doing pwm stuff is now the same
regardless of whether you're a child of pwmbus, or some random driver
elsewhere in the hierarchy that is bypassing the pwmbus layer and is talking
directly to the hardware driver via cross-hierarchy connections established
using fdt data.

The pwmc driver is now a child of pwmbus, instead of being its sibling
(that's why the get_bus method is no longer needed; pwmc now gets the
device_t of the bus using device_get_parent()).

r349088:
Make pwm channel numbers unsigned.

r349091:
The pwm interface was replaced with pwmbus, include the right header file.

r349092:
Make channel number unsigned, and spell unsigned int u_int. This should
have been part of r349088.

r349093:
This code no longer uses fdt/ofw stuff, no need to include ofw headers.

r349094:
Add module makefiles for pwm.

r349095:
Split the dtb MODULES_EXTRA line to a series of += lines, making it easier
to maintain and keep in alphabetical order, and paving the way for adding
some other modules that aren't dtb-related.

r349096:
Add module makefiles for Texas Instruments ARM SoCs.

The natural place to look for them based on how other SoCs are organized
would be sys/modules/ti, but that's already taken. Drop a clue into
modules/ti/Makefile directing people to modules/arm_ti if they're looking
for ARM modules.

r349097:
Build SoC-specific modules with GENERIC for the SoCs that have them.

r349115:
Rename pwmbus.h to ofw_pwm.h, because after all the recent changes, there
is nothing left in the file that related to pwmbus at all. It just contains
prototypes for the functions implemented in dev/pwm.ofw_pwm.c, so name it
accordingly and fix the include protect wrappers to match.

A new pwmbus.h will be coming along in a future commit.

r349119:
Rework pwmbus and pwmc so that each child will handle a single PWM channel.

Previously, there was a pwmc instance for each instance of pwm hardware
regardless of how many pwm channels that hardware supported. Now there
will be a pwmc instance for each channel when the hardware supports
multiple channels. With a separate instance for each channel, we can have
"named channels" in userland by making devfs alias entries in /dev/pwm.

These changes add support for ivars to pwmbus, and use an ivar to track the
channel number for each child. It also adds support for hinted children.

In pwmc, the driver checks for a label hint, and if present, it's used to
create an alias for the cdev in /dev/pwm. It's not anticipated that hints
will be heavily used, but it's easy to do and allows quick ad-hoc creation
of named channels from userland by using kenv to create hint.pwmc.N.label=
hints. Upcoming changes will add FDT support, and most labels will
probably be specified that way.

r349130:
Add ofw_pwmbus to enumerate pwmbus devices on systems configured with fdt
data. Also, add fdt support to pwmc.

r349131:
Implement the ofw_bus_get_node method in aw_pwm(4) so that ofw_pwmbus can
find its metadata for instantiating children.

r349132:
Add back a const qualifier I somehow fumbled away between test-building
and committing recent changes.

r349143:
Put the pwmc cdev filenames under the pwm directory along with any label
names. I.e., everything related to pwm now goes in /dev/pwm. This will
make it easier for userland tools to turn an unqualified name into a fully
qualified pathname, whether it's the base pwmcX.Y name or a label name.

r349144:
Follow changes in the pwmc(4) driver in relation to device filenames.

The driver now names its cdev nodes pwmcX.Y where X is unit number and
Y is the channel within that unit. Change the default device name from
pwmc0 to pwmc0.0. The driver now puts cdev files and label aliases in
the /dev/pwm directory, so allow the user to provide unqualified names
with -f and automatically prepend the /dev/pwm part for them.

Update the examples in the manpage to show the new device name format
and location within /dev/pwm.

r349145:
Put periods at the ends of argument descriptions. Explain the relationship
between the period and duty arguments.

r349164:
Remove everything related to channels from the pwmc public interface, now
that there is a pwmc(4) instance per channel and the channel number is
maintained as a driver ivar rather than being passed in from userland.

r349165:
Explain the relationship between PWM hardware channels being controlled and
pwmc(4) device filenames. Also, use uppercase PWM when the term is being
used as an acronym, and expand the acronym where it's first used.

r349166:
Rearrange the argument checking and processing so that enable and disable
can be combined with configuring the period and duty cycle (the same ioctl
sets all 3 values at once, so there's no reason to require the user to run
the program twice to get all 3 things set).

r349167:
Oops, it seems I left out the word 'cycle', fix it.

r349168:
Add a pwmc(4) manpage.

r349174:
Handle labels specified with hints even on FDT systems. Hints are the
easiest thing for a user to control (via loader.conf or kenv+kldload), so
handle them in addition to any label specified via the FDT data.

r349269:
Some mundane tweaks and cleanups to help de-clutter the diffs of some
upcoming functional changes.

Add an ofw_compat_data table for probing compat strings, and use it to add
PNP data. Remove some stray semicolons at the end of macro definitions,
and add a PWM_LOCK_ASSERT macro to round out the usual suite. Move the
device_t and driver_methods structs to the end of the file. Tweak comments.

r349270:
Add support for the PWM(9) API. This allows configuring the pwm output using
pwm(9), but also maintains the historical sysctl config interface for
compatiblity with existing apps. The two config systems are not compatible
with each other; if you use both interfaces to change configurations you're
likely to end up with incorrect output or none at all.

r349271:
Catch up with recent changes in pwmbus(9). The pwm(9) and pwmbus(9)
interfaces were unified into pwmbus(9), and the PWMBUS_CHANNEL_MAX method
was renamed PWMBUS_CHANNEL_COUNT. The pwmbus_attach_bus() function just
went away completely. Also, fix a few typos such as s/is/if/.

r349272:
Do some general cleanup and light wordsmithing.

Sort methods alphabetically. Wrap long lines. Start sentences on a new
line. Remove contractions (not because it's a good idea, just to silence
igor). Add some explanation of the units for the period and duty arguments
and the convention for channel numbers.

r349273:
Add pwm to the armv7 GENERIC kernel, it's now used by TI and Allwinner.

show more ...

MFC r346598: Enable Mellanox drivers (modules) on AArch64

PR: 237055
Submitted by: Greg V <[email protected]>

MFC r347285 and r347327:
Initial version of Mellanox in-kernel firmware upgrade support.

Submitted by: slavash@
Sponsored by: Mellanox Technologies

MFC r345407,r345408: Add nvme to arm64 GENERIC, and build if_ena on arm64.

These allow stable/12 to boot on Amazon EC2 "A1" family (arm64) instances.

Sponsored by: https://www.patreon.com/cperciva

MFC r344505-r344507, r344523, r344525-r344526, r344529, r344606-r344612,
r344614-r344616, r344681, r344684-r344686, r344728, r344733-r344734, r344981

A large set of changes that collectively moderni

MFC r344505-r344507, r344523, r344525-r344526, r344529, r344606-r344612,
r344614-r344616, r344681, r344684-r344686, r344728, r344733-r344734, r344981

A large set of changes that collectively modernize the at45d and mx25l
(DataFlash and SpiFlash) drivers, add FDT support, and add geom_flashmap and
geom_label support to them.

r344505:
Add a functional detach() implementation to make module unloading possible.

r344506:
Add support for probing/attaching on FDT-based systems.

r344507:
Switch to using config_intrhook_oneshot(). That allows the error handling
in the delayed attach to use early returns, which allows reducing the level
of indentation. So all in all, what looks like a lot of changes is really
no change in behavior, mostly just moving whitespace around.

r344523:
Include the jedec "extended device information string" in the criteria used
to match a chip to our table of metadata describing the chips. At least one
new DataFlash chip has a 3-byte jedec ID identical to its predecessors and
differs only in the extended info, and it has different metadata requiring a
unique entry in the table. This paves the way for supporting such chips.

The metadata table now includes two new fields, extmask and extid. The two
bytes of extended info obtained from the chip are ANDed with extmask then
compared to extid, so it's possible to use only a subset of the extended
info in the matching.

We now always read 6 bytes of jedec ID info. Most chips don't return any
extended info, and the values read back for those two bytes may be
indeterminate, but such chips have extmask and extid values of 0x0000 in the
table, so the extid effectively doesn't participate in the matching on those
chips and it doesn't matter what they return in the extended info bytes.

r344525:
Add a metadata entry for the AT45DB641E chip. This chip has the same 3-byte
jedec ID as its older cousin the AT45DB642D, but uses a different page size.
The only way to distinguish between the two chips is that the 2D chip has
0 bytes of extended ID info and the new 1E has 1 byte of extended ID. The
actual value of the extended ID byte is all zeroes. In other words, it's
the presence of the extended info that identifies this chip. (Presumably
a future upgrade might define non-zero values for the extended ID byte.)

r344526:
Resolve a name conflict when both SpiFlash and DataFlash devices are present.

Both SpiFlash (mx25l) and DataFlash (at45d) drivers create a disk device
with a name of /dev/flash/spiN where N is the driver's unit number. If
both types of devices are present in the same system, this creates a fatal
conflict that prevents attachment of whichever device attaches second
(because mx25l0 and at45d0 both try to create a spi0).

This gives each type of device a unique name (mx25lN or at45dN respectively)
and also adds an alias of spiN for compatibility. When both device types
appear in the same system, only the first to attach gets the spiN alias.
When the second device attaches there is a non-fatal warning that the alias
can't be created, but both devices are still accessible via their primary
names (and there is no need for the spiN name to work for backwards
compatibility on such a system, because it has never been possible to use
the spiN names when both devices exist).

r344529:
Fix a paste-o that broke the build on all arches.

r344606:
Add support for geom_flashmap by providing a getattr() for "SPI:device".

r344607:
Compile fdt_slicer and geom_flashmap when the at45d device is included.

r344608:
Update a comment to reflect reality; no functional changes.

r344609:
Make it possible to load fdt_slicer as a module (unloading works too fwiw).

r344610:
Add manpages for at45d(4) and mx25l(4).

r344611:
Add a module dependency on fdt_slicer.

r344612:
Add a module dependency on fdt_slicer. Also, move the PNP_INFO to its more
usual location, down near the DRIVER_MODULE() stuff.

r344614:
Rename some functions and variables to have shorter names, which allows
unwrapping multiple lines of code. Also, convert some short multiline
comments into single-line comments. Change old-school FALSE to false.

All in all, no functional changes, it's just more compact and readable.

r344615:
Child nodes with a compatible property are not slices, according to the
devicetree/bindings/mtd/partitions.txt document, so just ignore them.

r344616:
Add support to fdt_slicer for the new style partition data documented in
devicetree/bindings/mtd/partition.txt.

In the old style, all the children of the device node which did not have a
compatible property were the partitions. In the new style, there is a child
node of the device which has a compatible string of "fixed-partitions", and
its children are the individual partitions.

Also, support the read-only property by setting the corresponding slice flag.

r344681:
Build fdt support modules on systems that use fdt data.

kern.opts.mk sets make var OPT_FDT to a non-empty value if platform.h
contains OPT_FDT.

r344684:
Undo accidental part of r344681.

I think I must have accidentally mouse-click pasted while scrolling and
didn't notice it.

Reported by: jhibbits@

r344685:
Add required header file to SRCS.

r344686:
Add another required header file.

For some reason this seems to be required on aarch64, but I can build armv7
from clean without needing this in the list. (The file does get included,
so the mystery is why armv7 works.)

r344728:
Bugfix: use a dummy buffer for the inactive side of a transfer.

This is especially important for writes. SPI is inherently a bidirectional
bus; you receive data (even if it's garbage) while writing. We should not
receive that data into the same buffer we're writing to the device.

When reading it doesn't matter what we send to the device, but using the
dummy buffer for that as well is pleasingly symmetrical.

r344733:
Add some comments. Give #define'd names to some scattered numbers. Change
some #define'd names to be more descriptive. When reporting a post-write
compare failure, report the page number, not the byte address of the page.
The latter is the only functional change, it makes the number match the
words of the error message.

r344734:
Allow the sector size of the disk device to be configured using hints or
FDT data. The sector size must be a multiple of the device's page size.
If not configured, use the historical default of the device page size.

Setting the disk sector size to 512 or 4096 allows a variety of standard
filesystems to be used on the device. Of course you wouldn't want to be
writing frequently to a SPI flash chip like it was a disk drive, but for
data that gets written once (or rarely) and read often, using a standard
filesystem is a nice convenient thing.

r344981:
Give the mx25l device sole ownership of the name /dev/flash/spi* instead of
trying to use disk_add_alias() to make spi* an alias for mx25l*. It turns
out disk_add_alias() works for partitions, but not slices, and that's hard
to fix.

This change is, in effect, a partial revert of r344526.

The mips world relies on the existence of flashmap names formatted as
/dev/flash/spi0s.name, whereas pretty much nothing relies on at45d devices
using the /dev/spi* names (because until recently the at45d driver didn't
even work reliably). So this change makes mx25l devices the sole owner of
the /dev/flash/spi* namespace, which actually makes some sense because it is
a SpiFlash(tm) device, so flash/spi isn't a horrible name.

show more ...

MFC r344479 (by sobomax), r344605:
Modularize xz.

MFC r343617, r343618:
Make iflib a loadable module.

MFC r339523:

Add amdgpio, driver for GPIO controller on AMD-based x86_64 platforms

Submitted by: Rajesh Kumar <[email protected]>
Differential Revision: https://reviews.freebsd.org/D16865

Add initial driver for ACPI NFIT-enumerated NVDIMMs.

Driver enumerates NVDIMMs. Besides, for each found System Physical
Address (SPA) range, spaN geom provider is created, which allows
formatting a

Add initial driver for ACPI NFIT-enumerated NVDIMMs.

Driver enumerates NVDIMMs. Besides, for each found System Physical
Address (SPA) range, spaN geom provider is created, which allows
formatting and mounting the region as the normal volume. Also,
/dev/nvdimm_spaN node is created, which can be read/written/mapped by
userspace, the mapping is zero-copy.

No support for block access methods implemented, labels are not
parsed. No management interfaces are provided.

Tested by: Intel, NetApp
Sponsored by: The FreeBSD Foundation
Approved by: re (gjb)
MFC after: 2 weeks

show more ...

ixl/iavf(4): Change ixlv to iavf and update it to use iflib(9)

Finishes the conversion of the 40Gb Intel Ethernet drivers to iflib(9) for
FreeBSD 12.0, and fixes numerous bugs in both ixl(4) and iav

ixl/iavf(4): Change ixlv to iavf and update it to use iflib(9)

Finishes the conversion of the 40Gb Intel Ethernet drivers to iflib(9) for
FreeBSD 12.0, and fixes numerous bugs in both ixl(4) and iavf(4).

This commit also re-adds the VF driver to GENERIC since it now compiles and
functions.

The VF driver name was changed from ixlv(4) to iavf(4) because the VF driver is
now intended to be used with future products, not just with Fortville/Fort Park
VFs.

A man page update that documents these drivers is forthcoming in a separate
commit.

Reviewed by: sbruno@, kbowling@
Tested by: [email protected]
Approved by: re (gjb@)
Relnotes: yes
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D16429

show more ...

Put building of drm and drm2 modules behind options.

Make the building of drm dependent on MK_MODULE_DRM and the building
of module drm2 on MK_MODULE_DRM2. The defaults are unchanged.

Approved by:

Put building of drm and drm2 modules behind options.

Make the building of drm dependent on MK_MODULE_DRM and the building
of module drm2 on MK_MODULE_DRM2. The defaults are unchanged.

Approved by: re@ (gjb)
Differential Review: https://reviews.freebsd.org/D16894

show more ...

Remove the Yarrow PRNG algorithm option in accordance with due notice
given in random(4).

This includes updating of the relevant man pages, and no-longer-used
harvesting parameters.

Ensure that the

Remove the Yarrow PRNG algorithm option in accordance with due notice
given in random(4).

This includes updating of the relevant man pages, and no-longer-used
harvesting parameters.

Ensure that the pseudo-unit-test still does something useful, now also
with the "other" algorithm instead of Yarrow.

PR: 230870
Reviewed by: cem
Approved by: so(delphij,gtetlow)
Approved by: re(marius)
Differential Revision: https://reviews.freebsd.org/D16898

show more ...

Revert drm2 removal.

Revert r338177, r338176, r338175, r338174, r338172

After long consultations with re@, core members and mmacy, revert
these changes. Followup changes will be made to mark them a

Revert drm2 removal.

Revert r338177, r338176, r338175, r338174, r338172

After long consultations with re@, core members and mmacy, revert
these changes. Followup changes will be made to mark them as
deprecated and prent a message about where to find the up-to-date
driver. Followup commits will be made to make this clear in the
installer. Followup commits to reduce POLA in ways we're still
exploring.

It's anticipated that after the freeze, this will be removed in
13-current (with the residual of the drm2 code copied to
sys/arm/dev/drm2 for the TEGRA port's use w/o the intel or
radeon drivers).

Due to the impending freeze, there was no formal core vote for
this. I've been talking to different core members all day, as well as
Matt Macey and Glen Barber. Nobody is completely happy, all are
grudgingly going along with this. Work is in progress to mitigate
the negative effects as much as possible.

Requested by: re@ (gjb, rgrimes)

show more ...

Remove legacy drm and drm2 from tree

As discussed on the MLs drm2 conflicts with the ports' version and there
is no upstream for most if not all of drm. Both have been merged in to
a single port.

U

Remove legacy drm and drm2 from tree

As discussed on the MLs drm2 conflicts with the ports' version and there
is no upstream for most if not all of drm. Both have been merged in to
a single port.

Users on powerpc, 32-bit hardware, or with GPUs predating Radeon
and i915 will need to install the graphics/drm-legacy-kmod. All
other users should be able to use one of the LinuxKPI-based ports:
graphics/drm-stable-kmod, graphics/drm-next-kmod, graphics/drm-devel-kmod.

MFC: never
Approved by: core@

show more ...

Support building IPMI as a module on powerpc64

This still only supports IPMI via OPAL on powerpc64, but now it can be tested
with a GENERIC kernel.

Make it possible to run ntpd as a non-root user, add ntpd uid and gid.

Code analysis and runtime analysis using truss(8) indicate that the only
privileged operations performed by ntpd are adjusting

Make it possible to run ntpd as a non-root user, add ntpd uid and gid.

Code analysis and runtime analysis using truss(8) indicate that the only
privileged operations performed by ntpd are adjusting system time, and
(re-)binding to privileged UDP port 123. These changes add a new mac(4)
policy module, mac_ntpd(4), which grants just those privileges to any
process running with uid 123.

This also adds a new user and group, ntpd:ntpd, (uid:gid 123:123), and makes
them the owner of the /var/db/ntp directory, so that it can be used as a
location where the non-privileged daemon can write files such as the
driftfile, and any optional logfile or stats files.

Because there are so many ways to configure ntpd, the question of how to
configure it to run without root privs can be a bit complex, so that will be
addressed in a separate commit. These changes are just what's required to
grant the limited subset of privs to ntpd, and the small change to ntpd to
prevent it from exiting with an error if running as non-root.

Differential Revision: https://reviews.freebsd.org/D16281

show more ...

Partial revert of r335399 and r335400:
Unhook the MAC/veriexec, fingerprint handlers, and veriexec modules from
the kernel modules Makefile.

Reviewed by: sjg

Correct linprocfs/linsysfs arch check in r335672

Pointy hat to: emaste

Build linprocfs and linsysfs also on arm64

Sponsored by: Turing Robotic Industries

Device for user space to interface with MAC/veriexec.

The veriexec device features the following ioctl commands:

VERIEXEC_ACTIVE
Activate veriexec functionality
VERIEXEC_DEBUG_ON
Enable debuggi

Device for user space to interface with MAC/veriexec.

The veriexec device features the following ioctl commands:

VERIEXEC_ACTIVE
Activate veriexec functionality
VERIEXEC_DEBUG_ON
Enable debugging mode and increment or set the debug level
VERIEXEC_DEBUG_OFF
Disable debugging mode
VERIEXEC_ENFORCE
Enforce veriexec fingerprinting (and acitvate if not already)
VERIEXEC_GETSTATE
Get current veriexec state
VERIEXEC_LOCK
Lock changes to veriexec meta-data store
VERIEXEC_LOAD
Load veriexec fingerprint if secure level is not raised (and passes the
checks for VERIEXEC_SIGNED_LOAD)
VERIEXEC_SIGNED_LOAD
Load veriexec fingerprints from loader that supports signed manifest
(and thus we can be more lenient about secure level being raised.)
Fingerprints can be loaded if the meta-data store is not locked. Also
securelevel must not have been raised or some fingerprints must have
already been loaded, otherwise it would be dangerous to allow loading.
(Note: this assumes that the fingerprints in the meta-data store at
least cover the fingerprint loader.)

Reviewed by: jtl
Obtained from: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D8561

show more ...

MAC/veriexec implements a verified execution environment using the MAC
framework.

The code is organized into a few distinct pieces:

* The meta-data store (in veriexec_metadata.c) which maps a file

MAC/veriexec implements a verified execution environment using the MAC
framework.

The code is organized into a few distinct pieces:

* The meta-data store (in veriexec_metadata.c) which maps a file system
identifier, file identifier, and generation key tuple to veriexec
meta-data record.

* Fingerprint management (in veriexec_fingerprint.c) which deals with
calculating the cryptographic hash for a file and verifying it. It also
manages the loadable fingerprint modules.

* MAC policy implementation (in mac_veriexec.c) which implements the
following MAC methods:

mpo_init
Initializes the veriexec state, meta-data store, fingerprint modules,
and registers mount and unmount EVENTHANDLERs

mpo_syscall
Implements the following per-policy system calls:
MAC_VERIEXEC_CHECK_FD_SYSCALL
Check a file descriptor to see if the referenced file has a valid
fingerprint.
MAC_VERIEXEC_CHECK_PATH_SYSCALL
Check a path to see if the referenced file has a valid fingerprint.

mpo_kld_check_load
Check if loading a kld is allowed. This checks if the referenced vnode
has a valid fingerprint.

mpo_mount_destroy_label
Clears the veriexec slot data in a mount point label.

mpo_mount_init_label
Initializes the veriexec slot data in a mount point label.
The file system identifier is saved in the veriexec slot data.

mpo_priv_check
Check if a process is allowed to write to /dev/kmem and /dev/mem
devices.
If a process is flagged as trusted, it is allowed to write.

mpo_proc_check_debug
Check if a process is allowed to be debugged. If a process is not
flagged with VERIEXEC_NOTRACE, then debugging is allowed.

mpo_vnode_check_exec
Check is an exectuable is allowed to run. If veriexec is not enforcing
or the executable has a valid fingerprint, then it is allowed to run.
NOTE: veriexec will complain about mismatched fingerprints if it is
active, regardless of the state of the enforcement.

mpo_vnode_check_open
Check is a file is allowed to be opened. If verification was not
requested, veriexec is not enforcing, or the file has a valid
fingerprint, then veriexec will allow the file to be opened.

mpo_vnode_copy_label
Copies the veriexec slot data from one label to another.

mpo_vnode_destroy_label
Clears the veriexec slot data in a vnode label.

mpo_vnode_init_label
Initializes the veriexec slot data in a vnode label.
The fingerprint status for the file is stored in the veriexec slot data.

* Some sysctls, under security.mac.veriexec, for setting debug level,
fetching the current state in a human-readable form, and dumping the
fingerprint database are implemented.

* The MAC policy implementation source file also contains some utility
functions.

* A set of fingerprint modules for the following cryptographic hash
algorithms:
RIPEMD-160, SHA1, SHA2-256, SHA2-384, SHA2-512

* Loadable module builds for MAC/veriexec and fingerprint modules.

WARNING: Using veriexec with NFS (or other network-based) file systems is
not recommended as one cannot guarantee the integrity of the files
served, nor the uniqueness of file system identifiers which are
used as key in the meta-data store.

Reviewed by: ian, jtl
Obtained from: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D8554

show more ...

remove epoch_test from default build

ixl(4): Update to use iflib

Update the driver to use iflib in order to bring performance,
maintainability, and (hopefully) stability benefits to the driver.

The driver currently isn't completely po

ixl(4): Update to use iflib

Update the driver to use iflib in order to bring performance,
maintainability, and (hopefully) stability benefits to the driver.

The driver currently isn't completely ported; features that are missing:

- VF driver (ixlv)
- SR-IOV host support
- RDMA support

The plan is to have these re-added to the driver before the next FreeBSD release.

Reviewed by: gallatin@
Contributions by: gallatin@, mmacy@, [email protected]
Tested by: [email protected]
MFC after: 1 month
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D15577

show more ...