Not the connection is dropped, but the incoming SYN segment.
Reviewed by: concussious.bugzilla_runbox.com
MFC after: 3 days
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D45296
Add the WITH/WITHOUT_BRANCH_PROTECTION build flags. This can be used
to enable the use of pointer authentication (FEAT_PAuth) and branch
target identification (FEAT_BTI) in userspace.
The kernel already handles both of these is userspace, we just need
to enable it.
Leave disabled for a short period for this to settle before enabling.
Reviewed by: emaste
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D42596
This takes a rc.d-service and starts it in a jail which shares the same
root-path as the host (or parent jail) and may inherit the network from
the host (or parent jail). Per service there is the possibility to
specify some arguments which give more permissions (e.g. netv4, netv6,
sysvipc...).
Reviewed by: bcr (man page)
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D40370
This policy enables a user to become another user without having to be
root (hence no setuid binary). it is configured via rules using sysctl
security.mac.do.rules
For example:
security.mac.do.rules=uid=1001:80,gid=0:any
The above rule means the user identifier by the uid 1001 is able to
become user 80
Any user of the group 0 are allowed to become any user on the system.
The mdo(1) utility expects the MAC/do policy to be installed and its
rules defined.
Reviewed by: des
Differential Revision: https://reviews.freebsd.org/D45145
Not once has rman_reserve_resource_bound() ever been used. There are
though several uses of RF_ALIGNMENT. In light of this remove this
extra and leave the actually used portion in place.
This partially reverts commit 13fb665772.
Reviewed by: imp,jhb
Pull Request: https://github.com/freebsd/freebsd-src/pull/1224
Link with --no-undefined-version by default. Will detect and prevent
the accidental removal of symbols from versioned libraries.
(cherry picked from commit 4510f2ca91)
This reverts commit b25ceb97ed.
Reviewed by: arichardson, kib, dim, emaste
Differential Revision: https://reviews.freebsd.org/D44216
Loading modules via kld_list is no longer substantially faster than via
loader.conf.
[skip ci]
MFC after: 2 weeks
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D45242
gcc doesn't have -m32 support on aarch64 so mark LIB32 broken there.
We have to check both COMPILER_TYPE and X_COMPILER_TYPE becuase
X_COMPILER_TYPE is only conditionally set and COMPILER_TYPE is the host
compiler in Makefile.inc1.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D45089
Filesystem manual pages describe drivers, not formats;
except for fs, which describes the structures of ffs/ufs,
not how to use it in the system.
Reported by: emaste
Reviewed by: des, imp, meena (previous version)
Pull Request: https://github.com/freebsd/freebsd-src/pull/1077
In the future, we will Default to _FORTIFY_SOURCE=2 if SSP is enabled,
otherwise default to _FORTIFY_SOURCE=0. For now we default it to 0
unconditionally to ease bisect across older versions without the new
symbols, and we'll put out a call for testing.
include/*.h include their ssp/*.h equivalents as needed based on the
knob. Programs and users are allowed to override FORTIFY_SOURCE in their
Makefiles or src.conf/make.conf to force it off.
Reviewed by: des, markj
Relnotes: yes
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D32308
<sysexits.h> was deprecated in the base system in a1432b4 for FreeBSD
8.0 and is retained only for backwards compatibility. Make that clear,
since sysexits(3) suggested using it since it was in style(9) prior
to this.
MFC after: 1 week
Co-authored-by: imp
Fixes: a1432b4
Reviewed by: imp, pauamma (previous version)
Pull Request https://github.com/freebsd/freebsd-src/pull/1195
When this driver was written it made sense to make this default to off,
but these days almost all BIOSses will do the right thing. Furthermore
non-mmio communication only works on Intel architectures.
So lets default to allowing mmio, but not change the semantics of the
AHC_ALLOW_MEMIO flag to not break existing installs. Also document the
already existing hint.ahc.<unit>.allow_memio.
Signed-off-by: HP van Braam <hp@tmm.cx>
Reviewed by: imp (small style tweak)
Pull Request: https://github.com/freebsd/freebsd-src/pull/1219
Add a sound(4) bridge device driver for the RME HDSP 9632 and HDSP 9652
sound cards. These cards require a nowadays rare PCI 32bit (not PCIe)
slot, but still see use due to their value and wealth of features.
The HDSP 9632 is mostly comparable to the newer HDSPe AIO, while the
HDSP 9652 is similar to the HDSPe RayDAT. These HDSPe PCIe cards are
supported by the snd_hdspe(4) driver which was taken as a starting point
for development of snd_hdsp(4).
Implementation is kept separately due to substantial differences in
hardware configuration and to allow easy removal in case PCI 32bit
support would be phased out in the future.
The snd_hdsp(4) kernel module is not enabled by default, and can be
loaded at runtime with kldload(8) or during boot via loader.conf(5).
Basic operation was tested with both cards, not including all optional
cable connectors and expansion boards. Features should be roughly on par
with the snd_hdspe(4) supported cards.
Reviewed by: christos, br
Differential Revision: https://reviews.freebsd.org/D45112
This dates way, way back with the original net80211 support w/ atheros chips.
The earliest chip (AR5210) had limitations supporting software encryption.
It only had the four WEP slots, and not any keycache entries. So when
trying to do CCMP/TKIP encryption would be enabled and the key slots
would have nothing useful in them, resulting in garbage encryption/decryption.
I changed this back in 2012 to disable supporting hardware WEP for AR5210
so if_ath(4) / net80211 crypto is all done in software and yes,
I could do CCMP/TKIP on AR5210 in software.
Fast-forward to newer-ish hardware - the Qualcomm 11ac hardware.
Those also don't support pass-through keycache slots! Well, the hardware
does at that layer, but then there's a whole offload data path encap/decap
layer that's turning the frames from raw wifi into ethernet frames (for
"dumb" AP behaviours) or "wifi direct" frames (ie, "windows".)
This hides a bunch of header frame contents required for doing the software
encryption / decryption path.
But then if you enable the raw transmit/receive frame format it ALSO
bypasses the hardware encryption/decryption engine!
So for those NICs:
* If you want to do encryption, you can only use the firmware supported
ciphers w/ wifi direct or ethernet;
* If you want to use software encrypt/decrypt, you MUST disable all encryption
and instead use 100% software encryption.
The wpa_supplicant bsd driver code has a specific comment about this and
flips on supporting WEP/TKIP/CCMP, which is understandable but it doesn't
fix the ACTUAL intention of all of this stuff.
So:
* create a new field, ic_sw_cryptocaps
* populate it with the default supported set of ciphers for net80211
(right now wep, tkip, ccmp)
* Communicate the combination of both ic_sw_cryptocaps and ic_cryptocaps
to wpa_supplicant via the relevant devcap ioctl.
* Update manpage.
I'll follow this up with a driver_bsd.c change in wpa_supplicant to
trust this again, and then start adding the other cipher support there.
Differential Revision: https://reviews.freebsd.org/D44820
Microchip Technology acquired SMSC in 2012, and all current products
and datasheets refer to the devices supported by this driver as
Microchip parts. Mention SMSC in a parenthetical comment to explain
the driver's name.
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D45115
Add minimal sg(4) manual page. This implements a subset of the Linux
IOCTL interface for either native FreeBSD programs, or for Linux
binaries in the linuxulator.
Noticed by: Lexi Winter
Sponsored by: Netflix
It's not 1996 anymore, and we use CIDR nowadays. Update the various
ifconfig_ examples to use CIDR notation instead of netmasks, and also
add an example of a basic ifconfig_ entry that most users will be
interested in.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1217
Previously it was only possible to enable target mode for these drivers
by rebuilding the kernel with AHC_TMODE_ENABLE or AHD_TMODE_ENABLE and a
bitmask of which units to statically enable for target mode.
There is no space-savings in the driver by not having AHC_TMODE_ENABLE
set, so in addition to the compile time option lets also introduce some
tunables:
hint.ahc.<unit>.tmode_enable=0/1
hint.ahd.<unit>.tmode_enable=0/1
For compatibility the old behavior is retained, but it can be overridden
with tunables
Signed-off-by: HP van Braam <hp@tmm.cx>
Reviewed by: imp, mav
Pull Request: https://github.com/freebsd/freebsd-src/pull/1208
This is the server (target in SCSI terms) for NVMe over Fabrics.
Userland is responsible for accepting a new queue pair and receiving
the initial Connect command before handing the queue pair off via an
ioctl to this CTL frontend.
This frontend exposes CTL LUNs as NVMe namespaces to remote hosts.
Users can ask LUNS to CTL that can be shared via either iSCSI or
NVMeoF.
Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44726
This is the client (initiator in SCSI terms) for NVMe over Fabrics.
Userland is responsible for creating a set of queue pairs and then
handing them off via an ioctl to this driver, e.g. via the 'connect'
command from nvmecontrol(8). An nvmeX new-bus device is created
at the top-level to represent the remote controller similar to PCI
nvmeX devices for PCI-express controllers.
As with nvme(4), namespace devices named /dev/nvmeXnsY are created and
pass through commands can be submitted to either the namespace devices
or the controller device. For example, 'nvmecontrol identify nvmeX'
works for a remote Fabrics controller the same as for a PCI-express
controller.
nvmf exports remote namespaces via nda(4) devices using the new NVMF
CAM transport. nvmf does not support nvd(4), only nda(4).
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44714
Structurally this is very similar to the TCP transport for iSCSI
(icl_soft.c). One key difference is that NVMeoF transports use a more
abstract interface working with NVMe commands rather than transport
PDUs. Thus, the data transfer for a given command is managed entirely
in the transport backend.
Similar to icl_soft.c, separate kthreads are used to handle transmit
and receive for each queue pair. On the transmit side, when a capsule
is transmitted by an upper layer, it is placed on a queue for
processing by the transmit thread. The transmit thread converts
command response capsules into suitable TCP PDUs where each PDU is
described by an mbuf chain that is then queued to the backing socket's
send buffer. Command capsules can embed data along with the NVMe
command.
On the receive side, a socket upcall notifies the receive kthread when
more data arrives. Once enough data has arrived for a PDU, the PDU is
handled synchronously in the kthread. PDUs such as R2T or data
related PDUs are handled internally, with callbacks invoked if a data
transfer encounters an error, or once the data transfer has completed.
Received capsule PDUs invoke the upper layer's capsule_received
callback.
struct nvmf_tcp_command_buffer manages a TCP command buffer for data
transfers that do not use in-capsule-data as described in the NVMeoF
spec. Data related PDUs such as R2T, C2H, and H2C are associated with
a command buffer except in the case of the send_controller_data
transport method which simply constructs one or more C2H PDUs from the
caller's mbuf chain.
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44712
libnvmf provides APIs for transmitting and receiving Command and
Response capsules along with data associated with NVMe commands.
Capsules are represented by 'struct nvmf_capsule' objects.
Capsules are transmitted and received on queue pairs represented by
'struct nvmf_qpair' objects.
Queue pairs belong to an association represented by a 'struct
nvmf_association' object.
libnvmf provides additional helper APIs to assist with constructing
command capsules for a host, response capsules for a controller,
connecting queue pairs to a remote controller and optionally
offloading connected queues to an in-kernel host, accepting queue pair
connections from remote hosts and optionally offloading connected
queues to an in-kernel controller, constructing controller data
structures for local controllers, etc.
libnvmf also includes an internal transport abstraction as well as an
implementation of a userspace TCP transport.
libnvmf is primarily intended for ease of use and low-traffic use cases
such as establishing connections that are handed off to the kernel.
As such, it uses a simple API built on blocking I/O.
For a host, a consumer first populates an 'struct
nvmf_association_params' with a set of parameters shared by all queue
pairs for a single association such as whether or not to use SQ flow
control and header and data digests and creates a 'struct
nvmf_association' object. The consumer is responsible for
establishing a TCP socket for each queue pair. This socket is
included in the 'struct nvmf_qpair_params' passed to 'nvmf_connect' to
complete transport-specific negotiation, send a Fabrics Connect
command, and wait for the Connect reply. Upon success, a new 'struct
nvmf_qpair' object is returned. This queue pair can then be used to
send and receive capsules. A command capsule is allocated, populated
with an SQE and optional data buffer, and transmitted via
nvmf_host_transmit_command. The consumer can then wait for a reply
via nvmf_host_wait_for_response. The library also provides some
wrapper functions such as nvmf_read_property and nvmf_write_property
which send a command and wait for a response synchronously.
For a controller, a consumer uses a single association for a set of
incoming connections. A consumer can choose to use multiple
associations (e.g. a separate association for connections to a
discovery controller listening on a different port than I/O
controllers). The consumer is responsible for accepting TCP sockets
directly, but once a socket has been accepted it is passed to
nvmf_accept to perform transport-specific negotiation and wait for the
Connect command. Similar to nvmf_connect, nvmf_accept returns a newly
construct nvmf_qpair. However, in contrast to nvmf_connect,
nvmf_accept does not complete the Fabrics negotiation. The consumer
must explicitly send a response capsule before waiting for additional
command capsules to arrive. In particular, in the kernel offload
case, the Connect command and data are provided to the kernel
controller and the Connect response capsule is sent by the kernel once
it is ready to handle the new queue pair.
For userspace controller command handling, the consumer uses
nvmf_controller_receive_capsule to wait for a command capsule.
nvmf_receive_controller_data is used to retrieve any data from a
command (e.g. the data for a WRITE command). It can be called
multiple times to split the data transfer into smaller sizes.
nvmf_send_controller_data is used to send data to a remote host in
response to a command. It also sends a response capsule indicating
success, or an error if an internal error occurs. nvmf_send_response
is used to send a response without associated data. There are also
several convenience wrappers such as nvmf_send_success and
nvmf_send_generic_error.
Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44710
Link with --no-undefined-version by default. Will detect and prevent
the accidental removal of symbols from versioned libraries.
Reviewed by: arichardson, kib, dim, emaste
Differential Revision: https://reviews.freebsd.org/D44216
Mergemaster has been deprecated for some time, and will be retired.
Reviewed by: kevans
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41799
For now, we enumerate disk devices before network devices. This is to
work around a problem wherein u-boot remaps BARs during boot in a way
that bhyve does not handle. Some discussion and experiments suggest
that this can be handled by having bhyve not map BARs during boot on
arm64; until a solution is implemented, however, this workaround is
sufficient for simple usage and doesn't have any real downsides.
The console and bootrom are specified slightly differently versus amd64,
and a few of vmrun.sh's command-line options are amd64-only.
Reviewed by: corvink, jhb
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D44933
