Geom utilities (geli(8), glabel(8), gmirror(8), gpart(8), gmirror(8),
gmountver(8), etc) all use the geom(8) utility as their back end
to process their commands and pass them into the kernel. Creating
a new utility requires no more than filling out a template describing
the commands and arguments that the utility supports. Consider the
specification for the very simple gmountver(8) utility:
struct g_command class_commands[] = {
{ "create", G_FLAG_VERBOSE | G_FLAG_LOADKLD, NULL,
{
G_OPT_SENTINEL
},
"[-v] prov ..."
},
{ "destroy", G_FLAG_VERBOSE, NULL,
{
{ 'f', "force", NULL, G_TYPE_BOOL },
G_OPT_SENTINEL
},
"[-fv] name"
},
G_CMD_SENTINEL
};
It has just two commands of its own: "create" and "destroy" along
with the four standard commands "list", "status", "load", and
"unload" provided by the base geom(8) utility. The base geom(8)
utility allows each command to use the G_FLAG_VERBOSE flag to specify
that a command should accept the -v flag and when the -v flag is
given the utility prints "Done." if the command completes successfully.
In the above example, both of the commands set the G_FLAG_VERBOSE,
so have the -v option available. In addition the "destroy" command
accepts the -f boolean flag to force the destruction.
If the "destroy" command wanted to also print out verbose information,
it would need to explicitly declare its intent by adding a line:
{ 'v', "verbose", NULL, G_TYPE_BOOL },
Before this change, the geom utility would silently ignore the above
line in the configuration file, so it was impossible for the utility
to know that the -v flag had been set on the command. With this
change a geom command can explicitly specify a -v option with a
line as given above and handle it as it would any other option. If
both a -v option and G_FLAG_VERBOSE are specified for a command
then both types of verbose information will be output when that
command is run with -v.
MFC after: 1 week
Sponsored by: Netflix
PASN requires CRYPT and when built WITHOUT_CRYPT buildworld
fails. Only enable PASN when MK_CRYPT is enabled (default).
PR: 259517
Reported by: emaste
Fixes: c1d255d3ff
MFC after: 1 week
The patch fixes the omission of '#include <float.h>', which is needed for
the weak reference on systems with LDBL_MANT_DIG == DBL_MANT_DIG.
PR: 218514
MFC after: 1 week
This change is a slight performance optimization for systems with a slow
64-bit division.
The th->th_scale and th->th_large_delta values only depend on the
timecounter frequency and the th->th_adjustment. The timecounter
frequency of a timehand only changes when a new timecounter is activated
for the timehand. The th->th_adjustment is only changed by the NTP
second update. The NTP second update is not done for every call of
tc_windup().
Move the code block to recalculate the scaling factor and
the large delta of a timehand to the new helper function
recalculate_scaling_factor_and_large_delta().
Call recalculate_scaling_factor_and_large_delta() when a new timecounter
is activated and a NTP second update occurred.
MFC after: 1 week
int alen is used only with SSL.
Reported by: Michael Dexter, Build Option Survey
MFC after: 3 days
Fixes: 8d5c781306 ("libradius: Fix input validation bugs")
Sponsored by: The FreeBSD Foundation
This allows the pmap_remove(min, max) call to see empty pmap and exploit
empty pmap optimization.
Reviewed by: markj
Tested by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D32569
to match the added accounting of the top-level page table pages.
Reviewed by: markj
Tested by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D32569
both for kernel and user page tables, the later exist in the PTI case.
Reviewed by: markj
Tested by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D32569
The limit of 384 maxusers for auto configuration was only imposed on
32-bit systems. Document that maxusers scales above 384 based on memory
for 64-bit systems.
PR: 204938
MFC after: 3 days
Reported by: David Höppner <0xffea@gmail.com>
While doing it, also move all the code to resolve pathnames and obtain
text vp and dvp, into single place. Besides simplifying the code, it
avoids spurious vnode relocks and validates the explanation why
a transient text reference on the script vnode is not harmful.
Reviewed by: markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D32611
For this, use vn_fullpath_hardlink() to resolve executable name for
execve(2).
This should provide the right hardlink name, used for execution, instead
of random hardlink pointing to this binary. Also this should make the
AT_EXECNAME reliable for execve(2), since kernel only needs to resolve
parent directory path, which should always succeed (except pathological
cases like unlinking a directory).
PR: 248184
Reviewed by: markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D32611
Also re-align comments, and group booleans and char members together.
Reviewed by: markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D32611
This change makes ident only dependant on libc functions
This makes our ident(1) more portable, also the fact that we only
depend on libc which is maintained with excellent backward compatibility
means that if one day ident is removed from base, someone using FreeBSD
22 will be able to fetch ident from FreeBSD 14 to run ident against
FreeBSD 1.0 binary
MFC After: 1 week
Ensure that NAT still works as expected when combined with dummynet.
MFC after: 3 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D32666
Dummynet differs from ALTQ in that ALTQ schedules packets after they
leave pf. Dummynet schedules them after they leave pf, but then
re-injects them.
We currently deal with this by ensuring we don't re-schedule a packet we
get from dummynet, but this produces unexpected results when combined
with NAT, as dummynet processing is done after the NAT transformation.
In other words, the second time the packet is handed to pf it may have a
different source and destination address.
Simplify this by moving dummynet processing to after all other pf
processing, and not re-processing (but always passing) packets from
dummynet.
This fixes NAT of dummynet delayed packets, and also reduces processing
overhead (because we only do state/rule lookup for each dummynet packet
once, rather than twice).
MFC after: 3 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D32665
We should clear firewall tags on loopback, icmp reflection, or if_epair
transmission. Left over tags can produce unexpected behaviour,
especially on if_epair where a and b interfaces can be in different
vnets, and have different firewall policies set.
MFC after: 3 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D32664
Remove all (non-persistent) tags when we transmit a packet. Real network
interfaces do not carry any tags either, and leaving tags attached can
produce unexpected results.
Reviewed by: bz, glebius
MFC after: 3 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D32663
instead of do {} while (0).
This makes them real void expressions, and they can be used anywhere
where a void function call can be used, for example in a conditional
operator.
Reviewed by: kib, mjg
Differential revision: https://reviews.freebsd.org/D32696
I dropped the + 1 from the other two instances in each file but failed
to do so for this one, resulting in a more egregious buffer overread
than the one I was fixing (since the read character ended up in the
output if there was space).
Reported by: Jenkins
Fixes: 34fb1c133c ("Fix intra-object buffer overread for labeled msdosfs volumes")
The starting sequence number used to verify that TLS 1.0 CBC records
are encrypted in-order in the OCF layer was always set to 0 and not to
the initial sequence number from the struct tls_enable.
In practice, OpenSSL always starts TLS transmit offload with a
sequence number of zero, so this only matters for tests that use a
random starting sequence number.
Reviewed by: markj
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D32676
After an unescaped newline, there may be a here-document. Some places in
case and for did not check for one.
Reviewed by: bdrewery
Differential Revision: https://reviews.freebsd.org/D32628
Volume labels, like directory entries, are padded with spaces and so
have no NUL terminator. Whilst the MIN for the dsize argument to strlcpy
ensures that the copy does not overflow the destination, strlcpy is
defined to return the number of characters in the source string,
regardless of the provided dsize, and so keeps reading until it finds a
NUL, which likely exists somewhere within the following fields, but On
CHERI with the subobject bounds enabled in the compiler this buffer
overread will be detected and trap with a bounds violation.
Found by: CHERI
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D32579
In the ATA/ATAPI spec these are space-padded fixed-length strings with
no NUL-terminator (and byte swapped). When performing the identify we
call ata_param_fixup to swap the bytes back to be in order, strip any
leading/trailing spaces and coalesce consecutive spaces, padding with
NULs. However, if the input has no padding spaces, the fixed-up strings
are still not NUL-terminated. This causes two issues. The first is that
strlcpy will truncate the string by replacing the final byte with a NUL.
The second is that strlcpy will keep reading src until it finds a NUL in
order to calculate the return value, which is defined as the length of
src (so that callers can then compare it with the dsize input to see if
the input string was truncated), thereby reading past the end of the
buffer and into whatever adjacent fields are in the structure. In
practice there's a NUL byte somewhere in the structure, but on CHERI
with subobject bounds enabled in the compiler this overread will be
detected and trap as a bounds violation.
Note this matches ata_xpt's aprobedone, which does a bcopy to a
malloc'ed buffer and manually NUL-terminates it for the CAM path's
device's serial_num.
Found by: CHERI
Reviewed by: imp, scottl
Differential Revision: https://reviews.freebsd.org/D32567
Currently, to support 64-byte contexts, xhci_ctx_[gs]et_le(32|64) take a
pointer to the field within a 32-byte context and, if 64-byte contexts
are in use, compute where the 64-byte context field is and use that
instead by deriving a pointer from the 32-byte field pointer. This is
done by exploiting a combination of 64-byte contexts being the same
layout as their 32-byte counterparts, just with 32 bytes of padding at
the end, and that all individual contexts are either in a device
context or an input context which itself is page-aligned. By masking out
the low 4 bits (which is the offset of the field within the 32-byte
contxt) of the offset within the page, the offset of the invididual
context within the containing device/input context can be determined,
which is itself 32 times the number of preceding contexts. Thus, adding
this value to the pointer again gets 64 times the number of preceding
contexts plus the field offset, which gives the offset of the 64-byte
context plus the field offset, which is the address of the field in the
64-byte context.
However, this involves a fair amount of lying to the compiler when
constructing these intermediate pointers, and is rather difficult to
reason about. In particular, this is problematic for CHERI, where we
compile the kernel with subobject bounds enabled; that is, unless
annotated to opt out (e.g. for C struct inheritance reasons where you
need to be able to downcast, or containerof idioms), a pointer to a
member of a struct is a capability whose bounds only cover that field,
and any attempt to dereference outside those bounds will fault,
protecting against intra-object buffer overflows. Thus the pointer given
to xhci_ctx_[gs]et_le(32|64) is a capability whose bounds only cover the
field in the 32-byte context, and computing the pointer to the 64-byte
context field takes the address out of bounds, resulting in a fault when
later dereferenced.
This can be cleaned up by using a different abstraction. Instead of
doing the 32-byte to 64-byte conversion on access to the field, we can
do the conversion when getting a pointer to the context itself, and
define proper 64-byte versions of contexts in order to let the compiler
do all the necessary arithmetic rather than do it manually ourselves.
This provides a cleaner implementation, works for CHERI and may even be
slightly more performant as it avoids the need to mess with masking
pointers (which cannot in the general case be optimised by compilers to
be reused across accesses to different fields within the same context,
since it does not know that the contexts are over-aligned compared with
the C ABI requirements).
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D32554
The upgrade to libdialog 1.3 included changes to the ABI.
Bump libdpv to 3 since it links against libdialog.
Reported by: Mark Millard <marklmi@yahoo.com>
Reviewed by: bapt
Fixes: a96ef45019 dialog: import dialog 1.3-20210117
Differential Revision: https://reviews.freebsd.org/D32675
Rack caches TCP/IP header for fast send, so it doesn't call
tcpip_fillheaders(). After certain socket option changes,
namely IPV6_TCLASS, IP_TOS and IP_TTL it needs to update
its fast block to be in sync with the inpcb.
Reviewed by: rrs
Differential Revision: https://reviews.freebsd.org/D32655
Pass control for IP/IP6 level options from generic tcp_ctloutput_set()
down to per-stack ctloutput.
Call tcp6_use_min_mtu() from tcp stack tcp_default_ctloutput().
Reviewed by: rrs
Differential Revision: https://reviews.freebsd.org/D32655
After handling them in IP level ctloutput, pass them down to TCP
ctloutput.
We already have a hack to handle IPV6_USE_MIN_MTU. Leave it in place
for now, but comment out how it should be handled.
For IPv4 we are interested in IP_TOS and IP_TTL.
Reviewed by: rrs
Differential Revision: https://reviews.freebsd.org/D32655
TCP stack sysctl nodes are currently inserted using the stack
name alias. Allow the user to get the current stack's alias to
allow for programatic sysctl access.
Obtained from: Netflix
r366466 (9c7bd4f198) fixed a subtle bug by stripping the trailing
'\n' appended to the output of popen("cd %s && pwd -P", p->srcdir).
Replace this cumbersome implementation with a single realpath(3) call
which avoids spawning a shell, reading from the stream with fgets(3),
and final strdup(3).
Reviewed by: arichardson, kevans
Approved by: imp
Differential Revision: https://reviews.freebsd.org/D26734
This brings it inline with what's in openbsd. I tested it locally
with 2G and 5G association; it seems to work.
Tested: Intel 7260 AC, hw 0x140, STA mode, 2G/5G
Differential Revision: https://reviews.freebsd.org/D32627
Subscribers: imp
Obtainde from: OpenBSD
Summary:
This updates the if_iwmreg.h definitions to;
OpenBSD: if_iwmreg.h,v 1.65 2021/10/11 09:03:22 stsp Exp
A few things haven't been fully converted, namely:
* I left a couple things as enums for now just to reduce the
other diffs needed; but they're the same values
* The IWM_SCD_QUEUE_* macros have different offsets which I
didn't update in case they broke things / changed based on later
firmware. But they also may be real bugfixes which are needed
for later chips. It'll need more testing before flipping this on.
The c file updates are:
* Use the newer names for things if the name changed but the semantics
didn't
* Explicitly use the earlier firmware structs which maintain compat
with the current firmware and code. The newer ones are in here and
they'll get converted when more openbsd code is merged into this tree.
* Use the older iwm rate table for now, which has entries for legacy
rates, HT and VHT. Our code works with that right now, updating it
to openbsd's err, "different" version can be done at a later date
when HT/VHT support is added.
Notably, a bunch of definitions were deleted that weren't used.
They're not used either in the openbsd/dfbsd drivers so I think it's
safe to delete them in the long run.
Test Plan: 7260 hw 0x140
Subscribers: imp
Differential Revision: https://reviews.freebsd.org/D32627
Reviewed by: md5
Obtained From: OpenBSD
This key is Declarative and should always be sent even if the
initiator did not send it's own limit. This is similar to the fix in
fc79cf4fea but for the target side. However, unlike that fix,
failure to send the key simply results in reduced performance.
PR: 259439
Reviewed by: mav, emaste
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D32651
