Summary:
Code was using the mask value without the shift.
Test Plan: Within FreeBSD/Linux guest, Identify NVMe controller to check the result.
Reviewed by: chuck, imp
MFC after: 2 weeks
Signed-off-by: Wanpeng Qian <wanpengqian@gmail.com>
Differential Revision: https://reviews.freebsd.org/D32659
Summary:
Currently Active Firmware Info is not initialized.
Fix is to initialize the Active Firmware Info to Slot 1.
Test Plan: Within FreeBSD/Linux guests, show the Firmware Logpage to confirm.
Reviewed By: chuck
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D32658
Summary:
Set Number of Power States Supported to indicate 1 power state. Keep the
Power State Descriptor data structures as zero to indicate "Not
reported".
Test Plan:
Within FreeBSD/Linux guests, list the number of power states and check
the Max Power value.
Reviewed By: markj, chuck
MFC after: 2 weeks
Signed-off-by: Wanpeng Qian <wanpengqian@gmail.com>
Differential Revision: https://reviews.freebsd.org/D32657
The debug print in nvme_opc_get_log_page() would print an uninitialized
local variable.
In nvme_opc_write_read(), a failed LBA bounds check would cause
pci_nvme_stats_write_read_update() to be called with an uninitialized
variable as a parameter. Although the parameter is unused when the
check fails (and so status != 0), LLVM 14 emits some bogus machine code
in this path, which happens to result in a segfault when it gets
executed.
PR: 265749
Reviewed by: chuck, emaste
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36119
Currently these are not reported because bhyve is compiled with WARNS=2.
Let's start taking small steps towards enabling more warnings.
No functional change intended.
Reviewed by: chuck, imp, emaste
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36118
The Dataset Management code could free an uninitialized pointer if the
device doesn't support the Dataset Management command.
PR: 264548
Reported by: Robert Morris <rtm@lcs.mit.edu>
Fuzzing of bhyve uncovered an assertion failure in the NVMe emulation.
Investigation uncovered several corner cases the code did not handle.
This change handles several Controller initialization errors, including
- bad AQ sizes
- bad AQ vm_map_gpa
- doorbell writes prior to RDY
- doorbell writes to uninitialized queue
- CSTS.RDY if CFS set
PR: 256317,256319,256320,256322
Reported by: Cheolwoo Myung <cwmyung@snu.ac.kr>
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D35453
Fuzzing of bhyve using hyfuzz discovered a way to cause a segmentation
fault in the NVMe emulation. If a guest specifies a physical address in
either the PRP1 or PRP2 field of a command that cannot be mapped from
guest to host, the function paddr_guest2host() returns a NULL pointer.
The NVMe emulation did not check for this error case, which allowed for
the segmentation fault to occur.
Fix is to check for a return value of NULL and indicate an error back to
the guest (Data Transfer error). While in the area, slightly refactor
the write/read blockif function to use a common error exit path.
PR: 256321
Reported by: Cheolwoo Myung <cwmyung@snu.ac.kr>
Reviewed by: imp, jhb
Differential Revision: https://reviews.freebsd.org/D35452
Summary:
NVMe operations indicate the memory region(s) associated with a command
via physical region pages (PRPs). Since each PRP has a fixed size,
contiguous memory regions larger than the PRP size require multiple PRP
entries.
Instead of issuing a blockif call for each PRP, the NVMe emulation
concatenates multiple contiguous PRP entries into a single blockif
request. The test for contiguous regions has a bug such that it
mistakenly treats an initial PRP address of zero as a contiguous range
and concatenates it with the previous. But because there is no previous
IOV, the concatenation code corrupts the IO request structure and leads
to a segmentation fault when the blockif request completes.
Fix is to test for the existence of a previous range before trying to
concatenate the current range with the previous one.
While in the area, rename pci_nvme_append_iov_req()'s lba parameter to
offset to match its usage.
PR: 264177
Reported by: Robert Morris <rtm@lcs.mit.edu>
Reviewed by: jhb
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D35328
This is consistent with what other uid-morphing utilities
do, i.e. jexec(1), su(1) etc.
MFC after: 2 weeks
Reviewed by: gbe
Differential Revision: https://reviews.freebsd.org/D36148
Check the canmount property before building the mountpoint string.
Reported by: Coverity
Fixes: 240afd8c1fcc ("makefs: Add ZFS support")
Sponsored by: The FreeBSD Foundation
nvstring_get() returns a copy of the string, not a pointer into the
nvlist's internal buffer.
Reported by: Coverity
Fixes: 240afd8c1fcc ("makefs: Add ZFS support")
Sponsored by: The FreeBSD Foundation
This is in preparation for including an etcupdate tree when performing a
-DNO_ROOT release image build. Although -DNO_ROOT can be passed via -M,
to be useful we need to mangle the resulting METALOG to mirror the
various cleanups to the tree that are done after the build (removing
generated files, empty files and empty directories), so etcupdate needs
its own flag.
Reviewed by: jhb, pauamma
Obtained from: CheriBSD
Differential Revision: https://reviews.freebsd.org/D35857
This is in preparation for building an etcupdate tree on non-FreeBSD
when building release images. The -d option is documented as a
BSD-specific equivalent to the POSIX -depth primary. Whilst GNU find
sort of accepts it in an attempt to be compatible, it still doesn't
permit it coming before the paths, unlike BSD find, and prints a
deprecation warning either way. Thus, use the equivalent POSIX -depth to
ensure it works correctly and without warning everywhere.
Reviewed by: jhb
Obtained from: CheriBSD
Differential Revision: https://reviews.freebsd.org/D35856
This will allow release/Makefile to forward on ${MAKE} to allow building
on non-FreeBSD systems where ${MAKE} is something other than make, as
make is typically GNU make in such situations.
Reviewed by: jhb, pauamma
Obtained from: CheriBSD
Differential Revision: https://reviews.freebsd.org/D35854
This allows one to take a staged directory tree and create a file
consisting of a ZFS pool with one or more datasets that contain the
contents of the directory tree. This is useful for creating virtual
machine images without using the kernel to create a pool; "zpool create"
requires root privileges and currently is not permitted in jails.
makefs -t zfs also provides reproducible images by using a fixed seed
for pseudo-random number generation, used for generating GUIDs and hash
salts. makefs -t zfs requires relatively little by way of machine
resources.
The "zpool_reguid" rc.conf setting can be used to ask a FreeBSD guest to
generate a unique pool GUID upon first boot.
A small number of pool and dataset properties are supported. The pool
is backed by a single disk vdev. Data is always checksummed using
Fletcher-4, no redundant copies are made, and no compression is used.
The manual page documents supported pool and filesystem properties.
The implementation uses a few pieces of ZFS support from with the boot
loader, especially definitions for various on-disk structures, but is
otherwise standalone and in particular doesn't depend on OpenZFS.
This feature should be treated as experimental for now, i.e., important
data shouldn't be trusted to a makefs-created pool, and the command-line
interface is subject to change.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35248
Rather than trying to shoehorn flags into the requested superblock
address, create a separate flags parameter to the ffs_sbget()
function in sys/ufs/ffs/ffs_subr.c. The ffs_sbget() function is
used both in the kernel and in user-level utilities through export
to the sbget() function in the libufs(3) library (see sbget(3)
for details). The kernel uses ffs_sbget() when mounting UFS
filesystems, in the glabel(8) and gjournal(8) GEOM utilities,
and in the standalone library used when booting the system
from a UFS root filesystem.
The ffs_sbget() function reads the superblock located at the byte
offset specified by its sblockloc parameter. The value UFS_STDSB
may be specified for sblockloc to request that the standard
location for the superblock be read.
The two existing options are now flags:
UFS_NOHASHFAIL will note if the check hash is wrong but will still
return the superblock. This is used by the bootstrap code to
give the system a chance to come up so that fsck can be run to
correct the problem.
UFS_NOMSG indicates that superblock inconsistency error messages
should not be printed. It is used by programs like fsck that
want to print their own error message and programs like glabel(8)
that just want to know if a UFS filesystem exists on a partition.
One additional flag is added:
UFS_NOCSUM causes only the superblock itself to be returned, but does
not read in any auxiliary data structures like the cylinder group
summary information. It is used by clients like glabel(8) that
just want to check for possible filesystem types. Using UFS_NOCSUM
skips the superblock checks for csum data which allows superblocks
that have corrupted csum data to be read and used.
The validate_sblock() function checks that the superblock has not
been corrupted in a way that can crash or hang the system. Unless
the UFS_NOMSG flag is specified, it will print out any errors that
it finds. Prior to this commit, validate_sblock() returned as soon
as it found an inconsistency so would print at most one message.
It now does all its checks so when UFS_NOMSG has not been specified
will print out everything that it finds inconsistent.
Sponsored by: The FreeBSD Foundation
They might belong to kernel modules not currently loaded, or to other
kernel versions. Ignoring them allows the configuration to be shared
between multiple hosts.
MFC after: 2 weeks
Sponsored by: Axcient
Reviewed by: rew
Differential Revision: https://reviews.freebsd.org/D35540
The last number of unbound upgrades failed to manually update the
version strings in usr.sbin/unbound/config.h. This commit fixes that.
Reported by: "Herbert J. Skuhra" <herbert@gojira.at>
Fixes: 0a92a9fca737edafbad03ee5a8efebe302851cff
a39a5a6905612447def27b66ffe73b9d11efd80c
9cf5bc93f6ba1711ae7bf96a982a2b3c8b073a18
273016e836aa378789612e0a0e08d50f28be778e
24e365220007c415f495cf8dcb228ece6002b8b7
5469a9953005a9a4d4aad7be88545d441622e9a0
MFC after: 3 days
This will be used by Makefile.inc1 to fix -DNO_ROOT distributeworld,
which needs to split out DESTDIR from DISTBASE so the METALOG file
includes the base/ prefix.
Reviewed by: kevans
Obtained from: CheriBSD
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D35808
Copy the ENVIRONMENT section from df(1) to swapinfo(8), except
that the --si option is removed for swapinfo.
PR: 235225
Reported by: 0mp
MFC after: 3 days
The original code had used a fixed-size buffer for ioctl(SIOCGIFCONF),
that might cause the target ifreq spilled from the buffer. Use the handy
getifaddrs(3) to fix the problem.
Reviewed by: glebius
Differential revision: https://reviews.freebsd.org/D35536
pmcstat has been broken for analyzing logs since D35342 / b6e28991bf3aadb.
This is because the pmc for the first CPU is not added when reading logs
because unlike its clones, its event id is not invalid. That causes us
to fail the assertion at lib/libpmcstat/libpmcstat_logging.c:293
when encountering samples from cpu0.
Fix this by removing the check that the PMC is invalid
Reviewed by: tsoome
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D35709
As of hostap 2.10, WEP is disabled by default. This of course is not a
bad thing but requires some planning and an announcment to remove WEP
support by default. A possible src.conf knob or letting users know they
should use the port instead might different options.
MFC after: 3 days
Surrently virtio-net uses the prefix of the backing interface to
choose the backend. This patch adds an additional option "type" to
choose the backend type explicitly. This allows greater flexibility
for end users to manage bhyve specific resources (such as by naming
the tap interfaces to more descriptive names). The option "type" is
optional. When it is not presented, the backend is derived from the
name of the backend interface.
For example, the line `-s 3,virtio-net,bsdvm0,type=tap` will create a
virtio-net device for the guest using the tap interface "bsdvm0".
Adding a new "type" option preserves the current legacy format in which
the first value after virtio-net names an instance of a backend.
Note that tap interfaces not following the pattern "tap*" will not be
created on demand via devfs cloning but must be created explicitly.
Reviewed by: vmaffione, jhb
Differential Revision: https://reviews.freebsd.org/D35143
Describe explicitly the handling of TCP endpoints in the TIME-WAIT and
SYN-RCVD state.
Reported by: glebius@
Reviewed by: glebius@
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D35651
