Summary:
Add support for building ossl(4) on powerpc64* by implementing ossl_cpuid and
other support functions for powerpc. The required assembly files for ppc were
already present in-tree.
Test Plan: The changes were tested using the in-tree tools/tools/crypto/cryptocheck.c tool on both powerpc64 and powerpc64le on a POWER9 system.
Reviewed by: #powerpc, jhibbits, jhb
Differential Revision: https://reviews.freebsd.org/D41837
This is derived from swills@ fork of the Juniper virtfs with many
changes by me including bug fixes, style improvements, clearer layering
and more consistent logging. The filesystem is renamed to p9fs to better
reflect its function and to prevent possible future confusion with
virtio-fs.
Several updates and fixes from Juniper have been integrated into this
version by Val Packett and these contributions along with the original
Juniper authors are credited below.
To use this with bhyve, add 'virtio_p9fs_load=YES' to loader.conf. The
bhyve virtio-9p device allows access from the guest to files on the host
by mapping a 'sharename' to a host path. It is possible to use p9fs as a
root filesystem by adding this to /boot/loader.conf:
vfs.root.mountfrom="p9fs:sharename"
for non-root filesystems add something like this to /etc/fstab:
sharename /mnt p9fs rw 0 0
In both examples, substitute the share name used on the bhyve command
line.
The 9P filesystem protocol relies on stateful file opens which map
protocol-level FIDs to host file descriptors. The FreeBSD vnode
interface doesn't really support this and we use heuristics to guess the
right FID to use for file operations. This can be confused by privilege
lowering and does not guarantee that the FID created for a given file
open is always used for file operations, even if the calling process is
using the file descriptor from the original open call. Improving this
would involve changes to the vnode interface which is out-of-scope for
this import.
Differential Revision: https://reviews.freebsd.org/D41844
Reviewed by: kib, emaste, dch
MFC after: 3 months
Co-authored-by: Val Packett <val@packett.cool>
Co-authored-by: Ka Ho Ng <kahon@juniper.net>
Co-authored-by: joyu <joyul@juniper.net>
Co-authored-by: Kumara Babu Narayanaswamy <bkumara@juniper.net>
The new bnxt_re driver doesn't compile on any of them (it uses writeq()
from the LinuxKPI, which isn't implemented there), and had already been
disconnected from the build on i386.
Reported by: Jenkins
Fixes: acd884dec9 ("RDMA/bnxt_re: Add bnxt_re RoCE driver")
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
Summary:
Though mostly used in x86 devices, TPM can be used on others, with a
direct SPI attachment. Refactor the TPM 2.0 driver set to use an
attachment interface, and implement a SPI bus interface.
Test Plan:
Tested on a Raspberry Pi 4, with a GeeekPi TPM2.0 module (SLB9670
TPM) using security/tpm2-tools tpm2_getcaps for very light testing against the
spibus attachment.
Reviewed by: kd
Obtained from: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D45069
nvmf_transport.ko provides routines for managing NVMeoF queue pairs
and capsules. It provides a glue layer between transports (such as
TCP or RDMA) and an NVMeoF host (initiator) and controller (target).
Unlike the synchronous API exposed to the host and controller by
libnvmf, the kernel's transport layer uses an asynchronous API built
on callbacks. Upper layers provide callbacks on queue pairs that are
invoked for transport errors (error_cb) or anytime a capsule is
received (receive_cb).
Data transfers for a command are usually associated with a callback
that is invoked once a transfer has finished either due to an error
or successful completion.
For an upper layer that is a host, command capsules are allocated and
populated with an NVMe SQE by calling nvmf_allocate_command. A data
buffer (described by a struct memdesc) can be associated with a
command capsule before it is transmitted via nvmf_capsule_append_data.
This function accepts a direction (send vs receive) as well as the
data transfer callback. The host then transmits the command via
nvmf_transmit_capsule. The host must ensure that the data buffer
described by the 'struct memdesc' remains valid until the data
transfer callback is called. The queue pair's receive_cb callback
should match received response capsules up with previously transmitted
commands.
For the controller, incoming commands are received via the queue
pair's receive_cb callback. 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. This function accepts an I/O completion callback that
is invoked once the data transfer has completed.
nvmf_send_controller_data is used to send data to a remote host in
response to a command. In this case a callback function is not used
but the status is returned synchronously. Finally, the controller can
allocate a response capsule via nvmf_allocate_response populated with
a supplied CQE and send the response via nvmf_transmit_capsule.
Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44711
This contain the hdmi code and the aperture code like in linux.
Differential Revision: https://reviews.freebsd.org/D44925
Reviewed by: bz
Obtained from: drm-kmod
Sponsored by: Beckhoff Automation GmbH & Co. KG
The driver already had the appropriate module macros, it just wasn't
hooked into the build system.
Since this device is specific to the Raspberry Pi 4, only build it for
AArch64.
Reviewed by: imp, emaste (earlier version)
Pull Request: https://github.com/freebsd/freebsd-src/pull/1139
The NVMe drivers are portable and are already included statically in
GENERIC on other architectures such as aarch64 and riscv64.
Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D44690
Move the code from the arm specific to the iicbus controller directory.
Split up between general logic and bus attachment code.
Add support for ACPI attachment in addition to FDT.
MFC after: 7 days
Tested by: bz (LS1088a FDT), Pierre-Luc Drouin (Honeycomb, ACPI)
Based on: D24917 by Val Packett (initial early version)
Differential Revision: https://reviews.freebsd.org/D44020
To support virtual machines on arm64 add the vmm code. This is based on
earlier work by Mihai Carabas and Alexandru Elisei at University
Politehnica of Bucharest, with further work by myself and Mark Johnston.
All AArch64 CPUs should work, however only the GICv3 interrupt
controller is supported. There is initial support to allow the GICv2
to be supported in the future. Only pure Armv8.0 virtualisation is
supported, the Virtualization Host Extensions are not currently used.
With a separate userspace patch and U-Boot port FreeBSD guests are able
to boot to multiuser mode, and the hypervisor can be tested with the
kvm unit tests. Linux partially boots, but hangs before entering
userspace. Other operating systems are untested.
Sponsored by: Arm Ltd
Sponsored by: Innovate UK
Sponsored by: The FreeBSD Foundation
Sponsored by: University Politehnica of Bucharest
Differential Revision: https://reviews.freebsd.org/D37428
pflow is a pseudo device to export flow accounting data over UDP.
It's compatible with netflow version 5 and IPFIX (10).
The data is extracted from the pf state table. States are exported once
they are removed.
Reviewed by: melifaro
Obtained from: OpenBSD
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D43106
Surprisingly, kldxref does not currently support arm, and unhelpfully
this means it silently does nothing rather than give an error, so the
linker.hints entry added to the METALOG for -DNO_ROOT builds (and
pkgbase ones) refers to a file that doesn't exist. Ideally it would be
supported (and ideally the METALOG handling would be less fragile, but
without integrating it into kldxref the only real option would be to
just run find(1) to get the list of linker.hints files, which feels a
little backwards), but for now just paper over this by skipping the
build step on arm.
Reported by: bapt
Fixes: ff7c12c1f1 ("Make kldxref a bootstrap tool and use unconditionally")
Now that kldxref is a generic cross tool and can be built on non-FreeBSD
we can bootstrap it during the build and thus remove the condition for
whether it exists. We also need to make sure to add it to the METALOG
for -DNO_ROOT builds.
Reviewed by: brooks, imp
Differential Revision: https://reviews.freebsd.org/D43051
OpenSSL provides implementations of several AES modes which use
bitslicing and can be accelerated on CPUs which support the NEON
extension. This patch adds arm platform support to ossl(4) and provides
an AES-CBC implementation, though bsaes_cbc_encrypt() only implements
decryption. The real goal is to provide an accelerated AES-GCM
implementation; this will be added in a subsequent patch.
Initially derived from https://reviews.freebsd.org/D37420.
Reviewed by: jhb
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
MFC after: 3 months
Differential Revision: https://reviews.freebsd.org/D41304
Armv8.5 adds an optional random number generator. This is implemented
as two special registers one to read a random number, the other to
re-seed the entropy pool before reading a random number. Both registers
will set the condition flags to tell the caller they can't produce a
random number in a reasonable amount of time.
Without a signal to reseed the entropy pool use the latter register
to provide random numbers to the kernel pool. If at a later time we
had a way to tell the provider if it needs to reseed or not we could
use the former.
On an Amazon AWS Graviton3 VM this never failed, however this may not
be the case on low end CPUs so retry reading the random number 10 times
before returning an error.
Reviewed by: imp, delphij (csprng)
Sponsored by: The FreeBSD Foundation
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D35411
This adds the (updated) rtw88 driver back to the build.
Functionality has not been tested (much) so might not currently
work but people offered to test.
Firmware is provided by the wifi-firmware-rtw88-kmod port/package.
This reverts commit 712468443d.
While the build-breaking changes were only in the window of
the two commits, 3e1f5cc9a81a..9af1bba44e1c, further updates
restored some functionality as well. Now that we are done,
add iwlwifi back to the build.
This reverts commit b75d1ce6c1.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Disconnect iwlwifi from the build for a few commits which, due to
incompatible LinuxKPI 802.11 changes would break the build for a
revision. It will be re-enabled "instantly".
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
As announced on freebsd-wireless [1] disconnect rtw88 from the build.
Add a note to the man page about the current state but leave the man
page in place for now as this is supposed to be temporary.
[1] https://lists.freebsd.org/archives/freebsd-wireless/2023-September/001377.html
MFC after: 20 days
X-MFC: will see about 14/13
This basic version of the driver obtains properties of the "sff,sfp"
compatible devices and implements a simple interface to provide an I2C
bus device for the rest of the drivers (e.g. to implement SIOCGI2C).
Both of the interface and driver are subjects for a further
generalization to be used in case of non-FDT and non-arm64 platforms.
Reviewed by: bz, manu
Approved by: bz (mentor)
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D41440
Following the removal of general MIPS support, there's no longer a need
to have the AHB bus-frontend in place, which according to Linux sources
also isn't used with any non-MIPS SoCs. For simplicity, PCI bus support
is only made conditional on the main one again, i. e. device ath_pci is
removed, and built into the main module, i. e. if_ath_pci.ko obsoleted,
respectively.
Effectively, this reverts the following commits and associated changes:
dba9c85977e849bb3ecb
Approved by: adrian
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D41354
Replace two cases of MACHINE_ARCH with MACHINE_CPUARCH and also use
`aarch64` instead of the improper `arm64` for that test.
Noticed by: Mark Millard
Sponsored by: Netflix
The mac_ipacl policy module enables fine-grained control over IP address
configuration within VNET jails from the base system.
It allows the root user to define rules governing IP addresses for
jails and their interfaces using the sysctl interface.
Requested by: multiple
Sponsored by: Google, Inc. (GSoC 2019)
MFC after: 2 months
Reviewed by: bz, dch (both earlier versions)
Differential Revision: https://reviews.freebsd.org/D20967
This is Broadcom's mpi3mr driver for FreeBSD version 8.6.0.2.0.
The mpi3mr driver supports Broadcom SAS4116-based cards in the 9600
series: 9670W-16i, 9670-24i, 9660-16i, 9620-16i, 9600-24i, 9600-16i,
9600W-16e, 9600-16e, 9600-8i8e.
Initially only available as a module and on amd64/arm64, since that's
how it has been tested to date. Future commits will add it to the kernel
build and may expand the architectures it is supported on.
Co-authored-by: Chandrakanth Patil <chandrakanth.patil@broadcom.com>
Feedback-by: ken (prior versions)
Reviewed-by: imp
RelNotes: yes
Differential-Revision: https://reviews.freebsd.org/D36771
Differential-Revision: https://reviews.freebsd.org/D36772
gVNIC is a virtual network interface designed specifically for
Google Compute Engine (GCE). It is required to support per-VM Tier_1
networking performance, and for using certain VM shapes on GCE.
The NIC supports TSO, Rx and Tx checksum offloads, and RSS.
It does not currently do hardware LRO, and thus the software-LRO
in the host is used instead. It also supports jumbo frames.
For each queue, the driver negotiates a set of pages with the NIC to
serve as a fixed bounce buffer, this precludes the use of iflib.
Reviewed-by: markj
MFC-after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D39873
Hooked to devctl_notify, this allows consumers to received events
by subscribing to a system over a generic netlink protocol
Reviewed by: imp, melifaro
Differential Revision: https://reviews.freebsd.org/D37574
Only build MAC/veriexec modules when MK_VERIEXEC is yes or we
are building all modules.
Add VERIEXEC knob to kernel __DEFAULT_NO_OPTIONS
Reviewed by: sjg
Obtained from: Juniper Networks, Inc.
This is a direct port of the Linux code as the licence allows it, so
style(9) isn't respected to allow applying directly the upstream commits.
Do not add it to linuxkpi directly but add a new linuxkpi_hdmi module
that drm modules will require later, no need to bloat linuxkpi more.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D39122
This reduces some duplication between the existing arm64 + x86 section
and the powerpc64 section. To make the diff simpler, enable mlx4 on
powerpc64 since it compiles.
Reviewed by: pkubaj, imp, emaste
Differential Revision: https://reviews.freebsd.org/D38973
Summary:
This review ports mlx5 driver, kernel's OFED stack (userland is already enabled), KTLS and krping to powerpc64 and powerpc64le.
krping requires a small change since it uses assembly for amd64 / i386.
NOTE: On powerpc64le RDMA works fine in the userspace with libmlx5, but on powerpc64 it does not. The problem is that contrib/ofed/libmlx5/doorbell.h checks for SIZEOF_LONG but this macro exists on neither powerpc64* nor amd64. Thus, the file silently goes to the fallback function written for 32-bit architectures. It works fine on little-endian architectures, but causes a hard fail on big-endian. It's possible it may also cause some runtime issues on little-endian.
Thus, on powerpc64 I verified that RDMA works with krping.
Reviewers: #powerpc, hselasky
Subscribers: bdrewery, imp, emaste, jhibbits
Differential Revision: https://reviews.freebsd.org/D38786
