install -> ${INSTALL}
mtree -> ${MTREE_CMD}
services_mkdb -> ${SERVICES_MKDB_CMD}
cap_mkdb -> ${CAP_MKDB_CMD}
pwd_mkdb -> ${PWD_MKDB_CMD}
kldxref -> ${KLDXREF_CMD}
If you do custom FreeBSD builds you may want to override those
in some cases.
Sponsored by: Sippy Software, Inc.
ENAv2 introduces many new features, bug fixes and improvements.
Main new features are LLQ (Low Latency Queues) and independent queues
reconfiguration using sysctl commands.
The year in copyright notice was updated to 2019.
Submitted by: Michal Krawczyk <mk@semihalf.com>
Obtained from: Semihalf
Sponsored by: Amazon, Inc.
code. The primary client of this is probably going to be ZFS encryption.
Reviewed by: jhb, cem
Sponsored by: iXsystems Inc, Kithrup Enterprises
Differential Revision: https://reviews.freebsd.org/D19298
FDT data is sometimes used to configure usb devices which are hardwired into
an embedded system. Because the devices are instantiated by the usb
enumeration process rather than by ofwbus iterating through the fdt data, it
is somewhat difficult for a usb driver to locate fdt data that belongs to
it. In the past, various ad-hoc methods have been used, which can lead to
errors such applying configuration that should apply only to a hardwired
device onto a similar device attached by the user at runtime. For example,
if the user adds an ethernet device that uses the same driver as the builtin
ethernet, both devices might end up with the same MAC address.
These changes add a new usb_fdt_get_node() helper function that a driver can
use to locate FDT data that belongs to a single unique instance of the
device. This function locates the proper FDT data using the mechanism
detailed in the standard "usb-device.txt" binding document [1].
There is also a new usb_fdt_get_mac_addr() function, used to retrieve the
mac address for a given device instance from the fdt data. It uses
usb_fdt_get_node() to locate the right node in the FDT data, and attempts to
obtain the mac-address or local-mac-address property (in that order, the
same as linux does it).
The existing if_smsc driver is modified to use the new functions, both as an
example and for testing the new functions. Rpi and rpi2 boards use this
driver and provide the mac address via the fdt data.
[1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/usb/usb-device.txt
Differential Revision: https://reviews.freebsd.org/D20262
The source file was moved to base earlier and also improved upon,
but never compiled in. This patch will:
- Make a module in sys/modules
- Make lindebugfs depend on linuxkpi (for seq_file)
- Check if read/write functions are set before calling, DRM drivers
don't always set both of them.
Reviewed by: hps
Approved by: imp (mentor), hps
MFC after: 1 week
seq_file.h and linux_seq_file.c was imported form ports earlier but
linux_seq_file.c was never compiled in with the module. With this
commit base seq_file will replace ports seq_file and it required a
few modifications to not break functionality and build.
Reviewed by: hps
Approved by: imp (mentor), hps
MFC after: 1 week
of them listed in opt_global.h which is not generated while building
modules outside of a kernel and such modules never match real cofigured
kernel.
So, we should prevent our users from building obviously defective modules.
Therefore, remove the root cause of the building of modules outside of a
kernel - the possibility of building modules with DEBUG or KTR flags.
And remove all of DEBUG printfs as it is incomplete and in threaded
programms not informative, also a half of system call does not have DEBUG
printf. For debuging Linux programms we have dtrace, ktr and ktrace ability.
PR: 222861
Reviewed by: trasz
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D20178
alter the userspace sockaddr to convert the format between linux and BSD versions.
That's the minimum 3 of copyin/copyout operations for one syscall.
Also some syscall uses linux_sa_put() and linux_getsockaddr() when load
sockaddr to userspace or from userspace accordingly.
To avoid this chaos, especially converting sockaddr in the userspace,
rewrite these 4 functions to convert sockaddr only in kernel and leave
only 2 of this functions.
Also in order to reduce duplication between MD parts of the Linuxulator put
struct sockaddr conversion functions that are MI out into linux_common module.
PR: 232920
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D20157
This add ability to automatically load ipsec kernel module, when
if_ipsec(4) virtual interface is created using ifconfig(8).
Reviewed by: gallatin
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D20169
Add support for DIM based on Linux,
with some minor adaptions specific to FreeBSD.
Linux commit
f97c3dc3c0e8d23a5c4357d182afeef4c67f5c33
MFC after: 3 days
Sponsored by: Mellanox Technologies
tun(4) and tap(4) share the same general management interface and have a lot
in common. Bugs exist in tap(4) that have been fixed in tun(4), and
vice-versa. Let's reduce the maintenance requirements by merging them
together and using flags to differentiate between the three interface types
(tun, tap, vmnet).
This fixes a couple of tap(4)/vmnet(4) issues right out of the gate:
- tap devices may no longer be destroyed while they're open [0]
- VIMAGE issues already addressed in tun by kp
[0] emaste had removed an easy-panic-button in r240938 due to devdrn
blocking. A naive glance over this leads me to believe that this isn't quite
complete -- destroy_devl will only block while executing d_* functions, but
doesn't block the device from being destroyed while a process has it open.
The latter is the intent of the condvar in tun, so this is "fixed" (for
certain definitions of the word -- it wasn't really broken in tap, it just
wasn't quite ideal).
ifconfig(8) also grew the ability to map an interface name to a kld, so
that `ifconfig {tun,tap}0` can continue to autoload the correct module, and
`ifconfig vmnet0 create` will now autoload the correct module. This is a
low overhead addition.
(MFC commentary)
This may get MFC'd if many bugs in tun(4)/tap(4) are discovered after this,
and how critical they are. Changes after this are likely easily MFC'd
without taking this merge, but the merge will be easier.
I have no plans to do this MFC as of now.
Reviewed by: bcr (manpages), tuexen (testing, syzkaller/packetdrill)
Input also from: melifaro
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D20044
The DTS for this board is already present in sys/gnu/dts/arm64/rockchip/
and just needs to be enabled.
Submitted by: alex@wied.io
Differential Revision: https://reviews.freebsd.org/D19823
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 after: 2 weeks
MFC-With: 345350, 346441
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D19993
This GRE-in-UDP encapsulation allows the UDP source port field to be
used as an entropy field for load-balancing of GRE traffic in transit
networks. Also most of multiqueue network cards are able distribute
incoming UDP datagrams to different NIC queues, while very little are
able do this for GRE packets.
When an administrator enables UDP encapsulation with command
`ifconfig gre0 udpencap`, the driver creates kernel socket, that binds
to tunnel source address and after udp_set_kernel_tunneling() starts
receiving of all UDP packets destined to 4754 port. Each kernel socket
maintains list of tunnels with different destination addresses. Thus
when several tunnels use the same source address, they all handled by
single socket. The IP[V6]_BINDANY socket option is used to be able bind
socket to source address even if it is not yet available in the system.
This may happen on system boot, when gre(4) interface is created before
source address become available. The encapsulation and sending of packets
is done directly from gre(4) into ip[6]_output() without using sockets.
Reviewed by: eugen
MFC after: 1 month
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D19921
Tested by Greg V with mlx5en on an Ampere eMAG instance at Packet.com on
c2.large.arm (with some additional uncommitted PCIe WIP).
PR: 237055
Submitted by: Greg V <greg@unrelenting.technology>
Reviewed by: hselasky
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D19983
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
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D19979
PR#223036 reported that INET6 callback addresses were not printed by
nfsdumpstate(8). This kernel patch adds INET6 addresses to the dump structure,
so that nfsdumpstate(8) can print them out, post-r346190.
The patch also includes the addition of #ifdef INET, INET6 as requested
by bz@.
PR: 223036
Reviewed by: bz, rgrimes
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D19839
TMPFS_PAGES_MINRESERVED controls how much memory is reserved for the system
and not used by tmpfs.
On very small memory systems, the default value may be too high and this
prevents these small memory systems from using reroot, which is required
for them to install firmware updates.
Submitted by: Hiroki Mori <yamori813@yahoo.co.jp>
Reviewed by: mizhka
Differential Revision: https://reviews.freebsd.org/D13583
This module provides support for the Amazon Elastic Network Adapter; it
was previously only built on x86 architectures, but Amazon EC2 now also
has ARM64 instances with this hardware.
Submitted by: Greg V
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
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D19649
Update NAT64LSN implementation:
o most of data structures and relations were modified to be able support
large number of translation states. Now each supported protocol can
use full ports range. Ports groups now are belongs to IPv4 alias
addresses, not hosts. Each ports group can keep several states chunks.
This is controlled with new `states_chunks` config option. States
chunks allow to have several translation states for single alias address
and port, but for different destination addresses.
o by default all hash tables now use jenkins hash.
o ConcurrencyKit and epoch(9) is used to make NAT64LSN lockless on fast path.
o one NAT64LSN instance now can be used to handle several IPv6 prefixes,
special prefix "::" value should be used for this purpose when instance
is created.
o due to modified internal data structures relations, the socket opcode
that does states listing was changed.
Obtained from: Yandex LLC
MFC after: 1 month
Sponsored by: Yandex LLC
o most of data structures and relations were modified to be able support
large number of translation states. Now each supported protocol can
use full ports range. Ports groups now are belongs to IPv4 alias
addresses, not hosts. Each ports group can keep several states chunks.
This is controlled with new `states_chunks` config option. States
chunks allow to have several translation states for single alias address
and port, but for different destination addresses.
o by default all hash tables now use jenkins hash.
o ConcurrencyKit and epoch(9) is used to make NAT64LSN lockless on fast path.
o one NAT64LSN instance now can be used to handle several IPv6 prefixes,
special prefix "::" value should be used for this purpose when instance
is created.
o due to modified internal data structures relations, the socket opcode
that does states listing was changed.
Obtained from: Yandex LLC
MFC after: 1 month
Sponsored by: Yandex LLC
CLAT is customer-side translator that algorithmically translates 1:1
private IPv4 addresses to global IPv6 addresses, and vice versa.
It is implemented as part of ipfw_nat64 kernel module. When module
is loaded or compiled into the kernel, it registers "nat64clat" external
action. External action named instance can be created using `create`
command and then used in ipfw rules. The create command accepts two
IPv6 prefixes `plat_prefix` and `clat_prefix`. If plat_prefix is ommitted,
IPv6 NAT64 Well-Known prefix 64:ff9b::/96 will be used.
# ipfw nat64clat CLAT create clat_prefix SRC_PFX plat_prefix DST_PFX
# ipfw add nat64clat CLAT ip4 from IPv4_PFX to any out
# ipfw add nat64clat CLAT ip6 from DST_PFX to SRC_PFX in
Obtained from: Yandex LLC
Submitted by: Boris N. Lytochkin
MFC after: 1 month
Relnotes: yes
Sponsored by: Yandex LLC
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.)
geom_flashmap depends on a slicer being available in order to do any
work. On fdt platforms this is provided by fdt_slicer, but this needs
to be available. Often it's compiled into the kernel for platforms that
boot from the relevant media, but this is not always the case. Add the
file to the geom_flashmap module so that it can be used on platforms
which don't always need this functionality available.
Embedded lzma decompression library becomes a module usable by other
consumers, in addition to geom_uzip.
Most important code changes are
- removal of XZ_DEC_SINGLE define, we need the code to work
with XZ_DEC_DYNALLOC;
- xz_crc32_init() call is removed from geom_uzip, xz module handles
initialization on its own.
xz is no longer embedded into geom_uzip, instead the depend line for
the module is provided, and corresponding kernel option is added to
each MIPS kernel config file using geom_uzip.
The commit also carries unrelated cleanup by removing excess "device geom_uzip"
in places which were missed in r344479.
Reviewed by: cem, hselasky, ray, slavash (previous versions)
Sponsored by: Mellanox Technologies
Differential revision: https://reviews.freebsd.org/D19266
MFC after: 3 weeks
Add support for simple NVDIMM v1.2 namespaces from the UEFI
version 2.7 specification. The combination of NVDIMM regions and
labels can lead to a wide variety of namespace layouts. Here we
support a simple subset of namespaces where each NVDIMM SPA range
is composed of a single region per member dimm.
Submitted by: D Scott Phillips <d.scott.phillips@intel.com>
Discussed with: kib
MFC after: 1 week
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D18736
An upcoming bug fix requires 64-bit atomics, which aren't implemented on
powerpc. The powerpc port of fasttrap is incomplete anyway and doesn't
get loaded by dtraceall.ko on powerpc because of a missing dependency;
it's presumed that it's effectively unused.
Discussed with: jhibbits
MFC after: 2 weeks
Remove support for compiling drm2 as a module. This has transitioned
to the drm-kmod or drm-legacy-kmodw ports.
Approved by: graphics team
Reviewed by: manu@, mmel@
Differential Revision: https://reviews.freebsd.org/D19196
Retire the drm modules / drivers. These are now handled by the
drm-legacy-kmod port and/or the drm-kmod port. All future
development and maintanace will be handled there.
Approved by: graphics team
Reviewed by: manu@, mmel@
Differential Revision: https://reviews.freebsd.org/D19196
This adds the CBC-MAC code to the kernel, but does not hook it up to
anything (that comes in the next commit).
https://tools.ietf.org/html/rfc3610 describes the algorithm.
Note that this is a software-only implementation, which means it is
fairly slow.
Sponsored by: iXsystems Inc
Differential Revision: https://reviews.freebsd.org/D18592
Not all child devices of the NVDIMM root device represent DIMM devices
which are present in the system. The spec says (ACPI 6.2, sec 9.20.2):
For each NVDIMM present or intended to be supported by platform,
platform firmware also exposes an NVDIMM device ... under the
NVDIMM root device.
Present NVDIMM devices are found by walking all of the NFIT table's
SPA ranges, then walking the NVDIMM regions mentioned by those SPA
ranges.
A set of NFIT walking helper functions are introduced to avoid the
need to splat the enumeration logic across several disparate
callbacks.
Submitted by: D Scott Phillips <d.scott.phillips@intel.com>
Sponsored by: Intel Corporation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D18439
iflib is already a module, but it is unconditionally compiled into the
kernel. There are drivers which do not need iflib(4), and there are
situations where somebody might not want iflib in kernel because of
using the corresponding driver as module.
Reviewed by: marius
Discussed with: erj
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D19041
- Remove CS=2 entry from spigen-rpi2 since it didn't work
- Add spigen-rpi3 overlay for Raspberry Pi 3
- Enable rpi overlay modules for GENERIC kernel on aarch64
PR: 233489
Submitted by: bobf@mrp3.com
Reviewed by: db
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D16088
Update the appropriate Makefile to build the new driver
together with the old one.
Submitted by: Kornel Duleba <mindal@semihalf.com>
Reported by: kib
Obtained from: Semihalf
Sponsored by: Stormshield
This fixes a warning seen when compiling amd64 GENERIC with clang 7.
Also remove the workaround added in r337324. clang 7 and gcc 4.2
generate the same code with or without the code change.
Reviewed by: imp (previous version)
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D18603
The code is unreachable since the entries of radeon_ioctls[] are not
associated with any device: we provide only the KMS entry points.
Moreover, r600_cp_dispatch_texture() contains an integer overflow bug
that can be triggered from userspace.[1]
Reported by: Anonymous of the Shellphish Grill Team[1]
Reviewed by: dumbbell
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D18516
I also learned that 'mips' is overly broad and covers 64bit architectures
too. However, it's not worth the fight right now, so any refinements
will have to come another day.
mpr as a module for powerpc or mips. An upcoming commit will cause these
drivers to rely on the presence of 64bit atomic operations. Discussed
with jhibbits.
Changelist:
- Replace netmap passthrough host support with a more general
mechanism to call TXSYNC/RXSYNC from an in-kernel event-loop.
No kernel threads are used to use this feature: the application
is required to spawn a thread (or a process) and issue a
SYNC_KLOOP_START (NIOCCTRL) command in the thread body. The
kernel loop is executed by the ioctl implementation, which returns
to userspace only when a different thread calls SYNC_KLOOP_STOP
or the netmap file descriptor is closed.
- Update the if_ptnet driver to cope with the new data structures,
and prune all the obsolete ptnetmap code.
- Add support for "null" netmap ports, useful to allocate netmap_if,
netmap_ring and netmap buffers to be used by specialized applications
(e.g. hypervisors). TXSYNC/RXSYNC on these ports have no effect.
- Various fixes and code refactoring.
Sponsored by: Sunny Valley Networks
Differential Revision: https://reviews.freebsd.org/D18015
Description of sensors is generated from firmware sources.
Submitted by: Martin Harvey <mharvey at solarflare.com>
Sponsored by: Solarflare Communications, Inc.
Differential Revision: https://reviews.freebsd.org/D18251
Move empty definitions for platform-specific annotations from efsys.h
to EFX headers.
Submitted by: Martin Harvey <mharvey at solarflare.com>
Submitted by: Andrew Lee <alee at solarflare.com>
Sponsored by: Solarflare Communications, Inc.
Differential Revision: https://reviews.freebsd.org/D18248
Submitted by: Andy Moreton <amoreton at solarflare.com>
Sponsored by: Solarflare Communications, Inc.
Differential Revision: https://reviews.freebsd.org/D18214
- Store the clip table in 'struct adapter' instead of in the TOM softc.
- Init the clip table during attach and teardown during detach.
- While here, add a dev.<nexus>.<unit>.misc.clip sysctl to dump the
CLIP table.
This does mean that we update the clip table even if TOE is not enabled,
but non-TOE things need the CLIP table anyway.
Reviewed by: np, Krishnamraju Eraparaju @ Chelsio
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D18010
Submitted by: Andy Moreton <amoreton at solarflare.com>
Sponsored by: Solarflare Communications, Inc.
Differential Revision: https://reviews.freebsd.org/D18142
Pick up Medford2 interfaces.
Split AOE operations out into own header.
Sponsored by: Solarflare Communications, Inc.
Differential Revision: https://reviews.freebsd.org/D18137
HW needs to know which UDP packets should be treated as tunnel
encapsulation to do inner packet recognition, classification and
offloads.
Submitted by: Ivan Malov <ivan.malov at oktetlabs.ru>
Sponsored by: Solarflare Communications, Inc.
Differential Revision: https://reviews.freebsd.org/D18134
CLANG_NO_IAS34 was introduced in r276696 to allow then-HEAD kernels to
be built with clang 3.4 in FreeBSD 10. As FreeBSD 11 and later includes
a version of Clang with a sufficiently capable integrated assembler we
do not need the workaround any longer.
Sponsored by: The FreeBSD Foundation
This driver was marked as gone in 12. We're at 13 now. Remove it.
Data from nycbug's dmesg cache shows only one potential user,
suggesting it never was used much. However, even though this device
has been obsolete for 15 years at least, sys/joystick.h is included in
a number of graphics packages still, so that remains. A full exprun
is needed before that can be removed.
RelNotes: yes
Differential Revision: https://reviews.freebsd.org/D17629
I held the mistaken belief this was completely unused. While the
driver is unused and likely not relevant for a long time,
sys/joystick.h lives on in maybe half a dozen ports, even though
hardware to use it hasn't been widely used in maybe 15 years.
This driver has been obsolete since the FreeBSD 4.x. It should have
been removed then since the sym(4) driver had subsumed it. The driver
was commented out of GENERIC in 2000.
RelNotes: Yes
scsi_low was a common set of routines to do the SCSI bus sequencing
for the ncv, nsp and stg drivers. Those have been removed, so it's no
longer needed since nothing else in the tree uses it and nothing
likely ever will (it's for super-low-end 8-bit parallel SCSI cards).
stg(4) is marked as gone in 12. Remove it. There are no sightings of
it in the nycbug dmesg database. It was for an obscure SCSI card that
sold mostly in Japan, and was especially popilar among pc98 hackers in
the 4.x time frame. It was also only enabled on i386.
Relnote: Yes
nsp(4) is marked as gone in 12. Remove it. There are no sightings of
it in the nycbug dmesg database. It was for an obscure SCSI card that
sold mostly in Japan, and was especially popilar among pc98 hackers in
the 4.x time frame. It was also only enabled on i386.
Relnote: Yes
ncv(4) is marked as gone in 12. Remove it. There are no sightings of
it in the nycbug dmesg database. It was for an obscure SCSI card that
sold mostly in Japan, and was especially popilar among pc98 hackers in
the 4.x time frame..
Relnote: Yes
aic was marked to be gone in 12 a while ago. Go ahead and remove it.
nycbug's dmesg database shows this was last seen in 6 and one more
time in 4.x. It never was popular, and what popularity it had was over
before the nycbug databse got going in 2004.
Relnotes: yes
We tagged aha as gone in 12 a while ago. Proceed with its removal.
Data from nycbug's database shows the last sighting of this driver in
6, with the prior one in 4.x show its popularity had died prior to
4.x.
Relnotes: yes
Remove mse and all support for bus and inport devices from the tree.
Data from nycbug's dmesg database shows the last sighting of this
driver was in 4.10 on only one machine.
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D17628
This driver was marked as gone in 12. We're at 13 now. Remove it.
Data from nycbug's dmesg cache shows only one potential user,
suggesting it never was used much.
RelNotes: yes
Differential Revision: https://reviews.freebsd.org/D17629
to switch the output method in run-time. Also document some sysctl
variables that can by changed for NAT64 module.
NAT64 had compile time option IPFIREWALL_NAT64_DIRECT_OUTPUT to use
if_output directly from nat64 module. By default is used netisr based
output method. Now both methods can be used, but they require different
handling by rules.
Obtained from: Yandex LLC
MFC after: 3 weeks
Sponsored by: Yandex LLC
Differential Revision: https://reviews.freebsd.org/D16647
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
Rename functions and variables from ixlv to iavf to match the
user-facing name change. There shouldn't be any functional changes
with this change, but this may help with browsing the source code
and reducing diffs in the future.
Submitted by: kbowling@
Reviewed by: erj@, sbruno@
Approved by: re (gjb@)
Differential Revision: https://reviews.freebsd.org/D17544
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: jeffrey.e.pieper@intel.com
Approved by: re (gjb@)
Relnotes: yes
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D16429
This appeared to be required to have EFI RT support and EFI RTC
enabled by default, because there are too many reports of faulting
calls on many different machines. The knob is added to leave the
exceptions unhandled to allow to debug the actual bugs.
Reviewed by: kevans
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Approved by: re (rgrimes)
Differential revision: https://reviews.freebsd.org/D16972
play the MIDI files through /dev/sequencer device with tools like
playmidi. The audio output will go through the external MIDI device
such like wavetable synthesis card.
Reviewed by: matk (a long time ago), kib
Approved by: re (kib)
Tested with: Terratec SiXPack 5.1+ + Yamaha DB50XG
MFC after: 4 weeks
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
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
- sun50i-a64-sid.dtso registers the Security ID node, needed for thermal
- sun50i-a64-ths.dtso registers the thermal node, for which we already have a
driver
- sun50i-a64-timer.dtso registers the timer node, needed as the generic timer
glitch on A64 SoC.
Approved by: re (gjb)
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)
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@
This is an amalgam of a patch by Doug Ambrisko to
generalize uart_acpi_find_device, imp moving the
ACPI table to uart_dev_ns8250.c and advice by jhb
to work around a bug in the EPYC 3151 BIOS
(the BIOS incorrectly marks the serial ports as
disabled)
Reviewed by: imp
MFC after: 8 weeks
Differential Revision: https://reviews.freebsd.org/D16432
The wrapper is a thin shim around libsodium's Poly-1305 implementation. For
now, we just use the C algorithm and do not attempt to build the
SSE-optimized variant for x86 processors.
The algorithm support has not yet been plumbed through cryptodev, or added
to cryptosoft.
To compile this driver with evdev support enabled, place
following lines into the kernel configuration file:
options EVDEV_SUPPORT
device evdev
Note: Native and evdev modes are mutually exclusive.
Reviewed by: gonzo, wblock (docs)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D11156
The links were to cope with the switch to upstream dts.
We don't need them anymore.
While here add the rest of the beaglebone family dts as u-boot is common
on all those boards and load the dtb based on the product name.
This just miss the pocketbeagle variant as it's not yet in sys/gnu/dts but
will be with the Linux 4.18 dts import.
The jedec_ts(4) driver has been marked as deprecated in stable/11, and is
now being removed from -HEAD. Add a notice in UPDATING, and update the few
remaining references (regarding jedec_dimm(4)'s compatibility and history)
to reflect the fact that jedec_ts(4) is now deleted.
Reviewed by: avg
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D16537
The last known robust version of this code base was FreeBSD 8.2. There
are no users of this on current, and all users of it have abandoned
this platform or are in legacy mode with a prior version of FreeBSD.
All known users on arm@ approved this removal, and there were no
objections.
Differential Revision: https://reviews.freebsd.org/D16312
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
Remove all the big-endian arm architectures (ixp425 and ixp435)
support in the kernel and associated drivers.
Differential Revision: https://reviews.freebsd.org/D16257
The armv8crypto module includes arm_neon.h for the compiler intrinsic
functions. This includes the userland stdint.h file that doesn't exist in
the kernel. Fix this by providing an empty stdint.h to be used when we
include arm_neon.h.
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D16254
pflog and pfsync's module Makefile fails to include opt_global.h to SRCS
leading to build error for VIMAGE case.
Reproduced with:
cd /usr/src/sys/modules/pflog && make VIMAGE=yes
PR: 229404
Submitted by: eugen@
MFC after: 1 week
The arm64 linuxulator needs different arguments for the objcopy
invocation used to build the linux VDSO. These arguments are both arch-
and OS-dependent, so I did not try to use some common setting for them.
Reviewed by: imp
Sponsored by: Turing Robotic Industries
Differential Revision: https://reviews.freebsd.org/D16011
By adding spigen-rpi{2,-b}.dtso to fdt_overlays= in loader.conf, the fdt data
will set up the correct pinmux and device nodes to create a spigen(4) device
for each available chipselect pin.
Submitted by: Bob Frazier
Differential Revision: https://reviews.freebsd.org/D15067
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
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
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@, krzysztof.galazka@intel.com
Tested by: jeffrey.e.pieper@intel.com
MFC after: 1 month
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D15577
linux_vdso.so provides the vdso for the linuxulator's amd64 target and
is mapped into a Linux binary's address space. Thus it should be a
Linux-style .so, which has the ELF OS/ABI unset.
It turns out that ELF Tool Chain elfcopy/objcopy also has a bug where
the OS/ABI field is unset, regardless of the specified --output-target,
so this change is a no-op with the default in-tree toolchain. This is a
real fix when using external binutils, and the ELF Tool Chain bug will
be fixed in the future.
PR: 228934
Sponsored by: Turing Robotic Industries
Because base gcc does not support the required intrinsics, do not
attempt to compile the aesni module with it.
Noticed by: Dan Allen <danallen46@gmail.com>
MFC after: 3 days