Mark Johnston [Tue, 18 Apr 2023 18:32:04 +0000 (14:32 -0400)]
loader.efi: Fix some arm64 PE metadata
- Mark the file as an executable in the COFF header.
- Provide separate .text and .data sections.
- Provide sane file and section alignment values. These values are the
defaults defined in the PE specification.
- Set appropriate characteristics for each of .text and .data.
This is required for the MS devkit to load our UEFI image.
John Baldwin [Tue, 18 Apr 2023 18:27:29 +0000 (11:27 -0700)]
mail: Use a C89 function pointer type for command functions.
The command function is defined to always take a void *. Functions
which accept a pointer to an array of pointers use a local temporary
'argv' assigned from the void *arg.
John Baldwin [Tue, 18 Apr 2023 18:02:50 +0000 (11:02 -0700)]
boot0: Expand the description of BOOT_BOOT0_ORG.
This really shouldn't even be an option given it is hardcoded as a
constant named ORIGIN in the assembly. mbr.S also uses 0x600 and
hardcodes it in both the assembly and the Makefile.
Marius Strobl [Wed, 12 Apr 2023 21:46:02 +0000 (23:46 +0200)]
mmc(4): Don't call bridge driver for timings not requiring tuning
The original idea behind calling into the bridge driver was to have the
logic deciding whether tuning is actually required for a particular bus
timing in a given slot as well as doing the sanity checking only on the
controller layer which also generally is better suited for these due to
say SDHCI_SDR50_NEEDS_TUNING. On another thought, not every such driver
should need to check whether tuning is required at all, though, and not
everything is SDHCI in the first place.
Adjust sdhci{,_fsl_fdt}(4) accordingly, but keep sdhci_generic_tune() a
bit cautious still.
Randall Stewart [Mon, 17 Apr 2023 21:10:26 +0000 (17:10 -0400)]
tcp: Inconsistent use of hpts_calling flag
Gleb has noticed there were some inconsistency's in the way the inp_hpts_calls flag was being used. One
such inconsistency results in a bug when we can't allocate enough sendmap entries to entertain a call to
rack_output().. basically a timer won't get started like it should. Also in cleaning this up I find that the
"no_output" side of input needs to be adjusted to make sure we don't try to re-pace too quickly outside
the hpts assurance of 250useconds.
Another thing here is we end up with duplicate calls to tcp_output() which we should not. If packets go
from hpts for processing the input side of tcp will call the output side of tcp on the last packet if it is needed.
This means that when that occurs a second call to tcp_output would be made that is not needed and if pacing
is going on may be harmful.
Lets fix all this and explicitly state the contract that hpts is making with transports that care about the
flag.
mlx5en(4): Don't wait for receive queue to fill up with mbufs during open channels.
Failure to get mbufs may be transient.
Don't permanently fail to open the channels due to lack of mbufs.
This also makes modifying channel parameters faster.
Randall Stewart [Mon, 17 Apr 2023 17:52:00 +0000 (13:52 -0400)]
tcp: Blackbox logging and tcp accounting together can cause a crash.
If you currently turn BB logging on and in combination have TCP Accounting on we can get a
crash where we have no NULL check and we run out of memory. Also lets make sure we
don't do a divide by 0 in calculating any BB ratios.
vfs_lookup(): re-check v_mountedhere on lock upgrade
The VV_CROSSLOCK handling logic may need to upgrade the covered
vnode lock depending upon the requirements of the filesystem into
which vfs_lookup() is walking. This may involve transiently
dropping the lock, which can allow the target mount to be unmounted.
The underlying VOP_MKDIR() implementation may temporarily drop the
parent directory vnode's lock. If the vnode is reclaimed during that
window, the unionfs vnode will effectively become unlocked because
the its v_vnlock field will be reset. To uphold the locking
requirements of VOP_MKDIR() and to avoid triggering various VFS
assertions, explicitly re-lock the unionfs vnode before returning
in this case.
Note that there are almost certainly other cases in which we'll
similarly need to handle vnode relocking by the underlying FS; this
is the only one that's caused problems in stress testing so far.
A more general solution, such as that employed for nullfs in
null_bypass(), will likely need to be implemented.
The implementation is racy; if the unionfs vnode is not in fact
locked, vnode private data may be concurrently altered or freed.
Instead, simply rely upon the standard implementation to query the
v_vnlock field, which is type-stable and will reflect the correct
lower/upper vnode configuration for the unionfs node.
unionfs: remove LK_UPGRADE if falling back to the standard lock
The LK_UPGRADE operation may have temporarily dropped the upper or
lower vnode's lock. If the unionfs vnode was reclaimed during that
window, its lock field will be reset to no longer point at the
upper/lower vnode lock, so the lock operation will use the standard
lock stored in v_lock. Remove LK_UPGRADE from the flags in this case
to avoid a lockmgr assertion, as this lock has not been previously
owned by the calling thread.
4aeb63826e0f got it almost correct (we can't use strcmp() here as
current argument isn't guaranteed to be NUL-terminated), but we also
need to check that current argument length is equal to that of eofstr.
Ed Maste [Mon, 17 Apr 2023 18:56:51 +0000 (14:56 -0400)]
geom: use bool for one-bit wide bit-field
A one-bit wide bit-field can take only the values 0 and -1. Clang 16
introduced a warning that "implicit truncation from 'int' to a one-bit
wide bit-field changes value from 1 to -1". Fix by using c99 bool.
Reported by: Clang, via dim
Reviewed by: dim
Sponsored by: The FreeBSD Foundation
The recent 25685b75375 came in conflict with a540cdca318. Remove the
code that cleans up the old style input queue. Note that two lines
below we assert that the new style input queue is empty. The TCP
stacks that use the queue are supposed to flush it in their
tfb_tcp_fb_fini method.
Suppress lld 16 errors about multiply defined symbols in rescue
lld >= 16 became more strict about multiply defined symbols. Since there
are many of those in crunchgen'd programs, turn off the check when
linking the rescue binary.
libarchive: make single bit bitfields unsigned to avoid clang 16 warning
Clang 16 introduced a warning about single bit bitfields in structs,
which is triggered by various declarations in libarchive:
contrib/libarchive/libarchive/archive_write_set_format_7zip.c:1541:13: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
file->dir = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:5127:15: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
isoent->dir = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:5213:14: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
isoent->dir = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:5214:18: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
isoent->virtual = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:7149:18: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
isoent->virtual = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:7435:32: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
iso9660->zisofs.detect_magic = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:7495:25: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
iso9660->zisofs.making = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:7496:26: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
iso9660->zisofs.allzero = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:7702:28: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
iso9660->zisofs.allzero = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:7871:25: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
zisofs->header_passed = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:7894:24: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
zisofs->initialized = 1;
^ ~
Signed one-bit bitfields can only have values -1 and 0, but the intent
here is to use the fields as booleans, so make them unsigned.
libsa: make single bit bitfields unsigned to avoid clang 16 warning
Clang 16 introduced a warning about single bit bitfields in structs,
which is triggered by a declaration in libsa's tftp.c:
stand/libsa/tftp.c:382:20: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
h->islastblock = 1; /* very short file */
^ ~
stand/libsa/tftp.c:432:18: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
h->islastblock = 1; /* EOF */
^ ~
Signed one-bit bitfields can only have values -1 and 0, but the intent
here is to use the field as a boolean, so make it unsigned.
bsnmp: make single bit bitfields unsigned to avoid clang 16 warning
Clang 16 introduced a warning about single bit bitfields in structs,
which is triggered by a declaration in bsnmp's snmpd.h:
contrib/bsnmp/snmpd/trans_lsock.c:271:21: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
peer->input.stream = 1;
^ ~
Signed one-bit bitfields can only have values -1 and 0, but the intent
here is to use the field as a boolean, so make it unsigned.
Suppress lld 16 errors about undefined symbols in version maps
lld >= 16 turned on --no-undefined-version by default, which results in
errors whenever symbols are mentioned in version maps, but are not
actually defined in the binary.
Since we have quite a few instances of symbols that are defined or not,
depending on various compile-time settings, suppress this lld check for
the time being.
Expect that drivers call into the network stack with the net epoch
entered. This has already been the fact since early 2020. The net
interrupts, that are marked with INTR_TYPE_NET, were entering epoch
since 511d1afb6bf. For the taskqueues there is NET_TASK_INIT() and
all drivers that were known back in 2020 we marked with it in 6c3e93cb5a4. However in e87c4940156 we took conservative approach
and preferred to opt-in rather than opt-out for the epoch.
This change not only reverts e87c4940156 but adds a safety belt to
avoid panicing with INVARIANTS if there is a missed driver. With
INVARIANTS we will run in_epoch() check, print a warning and enter
the net epoch. A driver that prints can be quickly fixed with the
IFF_NEEDSEPOCH flag, but better be augmented to properly enter the
epoch itself.
Note on TCP LRO: it is a backdoor to enter the TCP stack bypassing
some layers of net stack, ignoring either old IFF_KNOWSEPOCH or the
new IFF_NEEDSEPOCH. But the tcp_lro_flush_all() asserts the presence
of network epoch. Indeed, all NIC drivers that support LRO already
provide the epoch, either with help of INTR_TYPE_NET or just running
NET_EPOCH_ENTER() in their code.
Steve Kiernan [Sun, 2 Apr 2023 19:33:10 +0000 (12:33 -0700)]
veriexec: Additional functionality for MAC/veriexec
Ensure veriexec opens the file before doing any read operations.
When the MAC_VERIEXEC_CHECK_PATH_SYSCALL syscall is requested, veriexec
needs to open the file before calling mac_veriexec_check_vp. This is to
ensure any set up is done by the file system. Most file systems do not
explicitly need an open, but some (e.g. virtfs) require initialization
of access tokens (file identifiers, etc.) before doing any read or write
operations.
The evaluate_fingerprint() function needs to ensure it has an open file
for reading in order to evaluate the fingerprint. The ideal solution is
to have a hook after the VOP_OPEN call in vn_open. For now, we open the
file for reading, envaluate the fingerprint, and close the file. While
this leaves a potential hole that could possibly be taken advantage of
by a dedicated aversary, this code path is not typically visited often
in our use cases, as we primarily encounter verified mounts and not
individual files. This should be considered a temporary workaround until
discussions about the post-open hook have concluded and the hook becomes
available.
Add MAC_VERIEXEC_GET_PARAMS_PATH_SYSCALL and
MAC_VERIEXEC_GET_PARAMS_PID_SYSCALL to mac_veriexec_syscall so we can
fetch and check label contents in an unconstrained manner.
Add a check for PRIV_VERIEXEC_CONTROL to do ioctl on /dev/veriexec
Make it clear that trusted process cannot be debugged. Attempts to debug
a trusted process already fail, but the failure path is very obscure.
Add an explicit check for VERIEXEC_TRUSTED in
mac_veriexec_proc_check_debug.
We need mac_veriexec_priv_check to not block PRIV_KMEM_WRITE if
mac_priv_gant() says it is ok.
Reviewed by: sjg
Obtained from: Juniper Networks, Inc.
Mark Johnston [Mon, 17 Apr 2023 13:44:44 +0000 (09:44 -0400)]
riscv: save the thread pointer in both modes
The contents of frame->tf_tp are uninitialized if accessed by DTrace (in
probe context), resulting in a panic when trying to access the memory
pointed to by tp. This saves the thread pointer to the trap frame when
handling both userland and kernel exceptions.
Reviewed by: markj, mhorne
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39582
939a050ad96c virtualized lagg(4), but the corresponding sysctl of some
virtualized global variables are not marked with CTLFLAG_VNET. A try to
operate on those variables via sysctl will effectively go to the 'master'
copies and the virtualized ones are not read or set accordingly. As a
side effect, on updating the 'master' copy, the virtualized global
variables of newly created vnets will have correct values.
The zfs_log_clone_range() function is never called from the
zfs_clone_range_replay() function, so I assumed it is safe to assert
that zil_replaying() is never TRUE here. It turns out zil_replaying()
also returns TRUE when the sync property is set to disabled.
Fix the problem by just returning if zil_replaying() returns TRUE.
Reported by: Florian Smeets Signed-off-by: Pawel Jakub Dawidek pawel@dawidek.net
Approved by: oshogbo, mm
Don't overwrite blk_phys_birth, as for embedded blocks it is part of
the payload.
Reviewed-by: Richard Yao <richard.yao@alumni.stonybrook.edu> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Pawel Jakub Dawidek <pawel@dawidek.net>
Issue #13392
Closes #14739
Simon J. Gerraty [Mon, 17 Apr 2023 01:40:53 +0000 (18:40 -0700)]
Update meta mode makefiles
meta2deps - add checks to detect truncated/corrupted filemon data
(only known to happen on Linux hosts), to ensure we do not auto
update dependencies based on incomplete data.
meta.stage.mk adds STAGE_SHLIB_LINKS_FILTER and STAGE_LINK_AS_*
We also allow for hosts where egrep is deprecated for grep -E
getopt(3) returns int type not char. Using char triggers the
-Wtautological-constant-out-of-range-compare warning with clang.
Change the type of the variable used for holding the return value
of getopt(3) to int to match the prototype and eliminate the warning.
projects / FreeBSD / FreeBSD.git / log