Generally, access to the kernel debugger is considered to be unsafe from
a security perspective since it presents an unrestricted interface to
inspect or modify the system state, including sensitive data such as
signing keys.
However, having some access to debugger functionality on production
systems may be useful in determining the cause of a panic or hang.
Therefore, it is desirable to have an optional policy which allows
limited use of ddb(4) while disabling the functionality which could
reveal system secrets.
This loadable MAC module allows for the use of some ddb(4) commands
while preventing the execution of others. The commands have been broadly
grouped into three categories:
- Those which are 'safe' and will not emit sensitive data (e.g. trace).
Generally, these commands are deterministic and don't accept
arguments.
- Those which are definitively unsafe (e.g. examine <addr>, search
<addr> <value>)
- Commands which may be safe to execute depending on the arguments
provided (e.g. show thread <addr>).
Safe commands have been flagged as such with the DB_CMD_MEMSAFE flag.
Commands requiring extra validation can provide a function to do so.
For example, 'show thread <addr>' can be used as long as addr can be
checked against the system's list of process structures.
The policy also prevents debugger backends other than ddb(4) from
executing, for example gdb(4).
Reviewed by: markj, pauamma_gundo.com (manpages)
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D35371
Add three simple hooks to the debugger allowing for a loaded MAC policy
to intervene if desired:
1. Before invoking the kdb backend
2. Before ddb command registration
3. Before ddb command execution
We extend struct db_command with a private pointer and two flag bits
reserved for policy use.
Reviewed by: markj
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D35370
Those which are statically defined in db_command.c.
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D35584
This is not completely exhaustive, but covers a large majority of
commands in the tree.
Reviewed by: markj
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D35583
This flag value can be used to indicate if a command has the property of
being "memory safe". In this instance, memory safe means that the
command does not allow/enable reads or writes of arbitrary memory,
regardless of the arguments passed to it. For example, 'backtrace' is
considered a memory-safe command since its output is deterministic,
while 'show vnode' is not, since it requires a memory address as an
argument and will print the contents beginning at that location.
Apply the flag to the "show all" command macros. It is expected that
commands added to this table will always exhibit this property.
Reviewed by: markj
Sponsored by: Juniper Networks, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D35581
debugnet provides the network stack for netgdb and netdump. Since it
must operate under panic/debugger conditions and can't rely on dynamic
memory allocation, it preallocates mbufs during boot or network
configuration. At that time, it does not yet know which interface
will be used for debugging, so it does not know the required size and
quantity of mbufs to allocate. It takes the worst-case approach by
calculating its requirements from the largest MTU and largest number
of receive queues across all interfaces that support debugnet.
Unfortunately, the bge NIC driver told debugnet that it supports 1,024
receive queues. It actually supports only 2 queues (with 1,024 slots,
thus the error). This greatly exaggerated debugnet's preallocation,
so with an MTU of 9000 on any interface, it allocated 600 MB of memory.
A tiny fraction of this memory would be used if netgdb or netdump were
invoked; the rest is completely wasted.
Reviewed by: markj, rlibby
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D35845
The load balancer may force a running thread to reschedule and pick a
new CPU. To do this it sets some flags in the thread running on a
loaded CPU. But the code assumed that a running thread's lock is the
same as that of the corresponding runqueue, and there are small windows
where this is not true. In this case, we can end up with non-atomic
modifications to td_flags.
Since this load balancing is best-effort, simply give up if the thread's
lock doesn't match; in this case the thread is about to enter the
scheduler anyway.
Reviewed by: kib
Reported by: glebius
Fixes: e745d729be60 ("sched_ule(4): Improve long-term load balancer.")
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35821
Commit e7fd9688ea97 changed vtfontcvt's command line parsing, but did
not correctly update the usage (it omitted the new -o flag).
Fixes: e7fd9688ea97 ("Move font related data structured to...")
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
It used to be mapped at the top of the UVA.
If the randomization is enabled any address above .data section will be
randomly chosen and a guard page will be inserted in the shared page
default location.
The shared page is now mapped in exec_map_stack, instead of
exec_new_vmspace. The latter function is called before image activator
has a chance to parse ASLR related flags.
The KERN_PROC_VM_LAYOUT sysctl was extended to provide shared page
address.
The feature is enabled by default for 64 bit applications on all
architectures.
It can be toggled kern.elf64.aslr.shared_page sysctl.
Approved by: mw(mentor)
Sponsored by: Stormshield
Obtained from: Semihalf
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D35349
Store the shared page address in struct vmspace.
Also instead of storing absolute addresses of various shared page
segments save their offsets with respect to the shared page address.
This will be more useful when the shared page address is randomized.
Approved by: mw(mentor)
Sponsored by: Stormshield
Obtained from: Semihalf
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D35393
Use a getter macro instead of fetching the sigcode address directly
from a sysent of a given process. It assumes that the sigcode is stored
in the shared page, which is true in all cases, except for a.out
binaries. This will be later useful when the shared page address
randomization is introduced.
No functional change intended.
Approved by: mw(mentor)
Sponsored by: Stormshield
Obtained from: Semihalf
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D35392
Some of the ofed/infiniband code has INET and INET6 address handling
code without using ifdefs. This failed with a recent change to INET,
in which IN_LOOPBACK() started using a VNET variable, and which is not
present if INET is not configured. Add #ifdef INET, and INET6 for good
measure, in cma_loopback_addr(), along with inclusion of the options
headers in ib_cma.c.
Reviewed by: hselasky rgrimes bz
Differential Revision: https://reviews.freebsd.org/D35835
(cherry picked from commit 752b7632776237f9c071783acdd1136ebf5f287d)
For version 2 extend the TMUV2_TMSAR() write loop over all site_ids
registered for a particular SoC and actually use the site_id rather
than always just the first [0] (which for the LX2080 would be a
problem given there is no site0).
Later, while version 2 adds the SITEs to enable to TMSR in bits 0..<n>,
version 1 (e.g., LS1028, LS1046, LS1088) add MSITEs to TMR
bits 16..31 or rather 15..0(16-<n>). Adjust the loops to only enable
the site_ids listed for the particular SoC for monitoring. This now
also deals with sparse site_ids (not starting at 0, or not being
contiguous).
MFC after: 1 week
Sponsored by: Traverse Technologies (providing Ten64 HW for testing)
Reviewed by: mmel
Differential Revision: https://reviews.freebsd.org/D35764
Configure the number of sites (sensors) based on SoC.
This avoids timeouts reading non-existent sensors.
The changes are based on mmel's initial work at:
914e3f0098
MFC after: 1 week
Sponsored by: Traverse Technologies (providing Ten64 HW for testing)
Reviewed by: mmel
Differential Revision: https://reviews.freebsd.org/D35759
The passed cpuid is always equal to the one stored in the callout
structure. No functional change intended.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Clang 15 warns:
sys/dev/cxgbe/cudbg/cudbg_lib.c:2949:6: error: variable 'i' set but not used [-Werror,-Wunused-but-set-variable]
int i = 0;
^
Apparently 'i' was meant as the current retry counter, but '1' was used
in the while loop comparison instead, making the loop potentially
infinite, if 'busy' never gets reset.
MFC after: 3 days
Reviewed by: np
Differential Revision: https://reviews.freebsd.org/D35834
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
Keep the definition around since it's used by userspace.
Reviewed by: alc, imp, kib
Tested by: pho
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35791
It's unused now. Keep the OBJ_DEFAULT identifier, but make it an alias
of OBJT_SWAP for the benefit of out-of-tree code.
Reviewed by: alc, imp, kib
Tested by: pho
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35790
With the removal of OBJT_DEFAULT, OBJ_ANON implies OBJ_SWAP.
Note, this means that vm_object_split() is more expensive than it used
to be, as it holds busy locks until the end of the range is reached,
even if the object has no swap blocks allocated.
Reviewed by: alc, kib
Tested by: pho
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35789
Now that OBJT_DEFAULT objects can't be instantiated, we can simplify
checks of the form object->type == OBJT_DEFAULT || (object->flags &
OBJ_SWAP) != 0. No functional change intended.
Reviewed by: alc, kib
Tested by: pho
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35788
With the removal of OBJT_DEFAULT, we can simply handle this in
swap_pager_dealloc(). No functional change intended.
Suggested by: alc
Reviewed by: alc, kib
Tested by: pho
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35787
With the removal of OBJT_DEFAULT, we can assume that pager operations
provide an object with OBJ_SWAP set. Also, we do not need to convert
objects from type OBJT_DEFAULT. Thus, remove checks for OBJ_SWAP and
remove code which modifies the object type. In some places, replace the
check for OBJ_SWAP with a check for whether any swap blocks are
assigned.
Reviewed by: alc, kib
Tested by: pho
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35786
With this change, OBJT_DEFAULT objects are no longer allocated.
Instead, anonymous objects are always of type OBJT_SWAP and always have
OBJ_SWAP set.
Modify the page fault handler to check the swap block radix tree in
places where it checked for objects of type OBJT_DEFAULT. In
particular, there's no need to invoke getpages for an OBJT_SWAP object
with no swap blocks assigned.
Reviewed by: alc, kib
Tested by: pho
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35785
Clang 15 warns:
sys/dev/cxgb/cxgb_sge.c:1290:21: error: variable 'txsd' set but not used [-Werror,-Wunused-but-set-variable]
struct tx_sw_desc *txsd = &txq->sdesc[txqs->pidx];
^
It appears 'txsd' is a leftover from a previous refactoring (see
3f345a5d09b6), but is no longer used for anything, and can be removed
without any functional change.
MFC after: 3 days
Reviewed by: np
Differential Revision: https://reviews.freebsd.org/D35833
Historically, GEOM utilities (gpart(8), gstripe(8), gmirror(8),
etc) used the gctl_error() routine to report errors. If they called
gctl_error() they would exit with EXIT_FAILURE, otherwise they would
return with EXIT_SUCCESS. If they used gctl_error() to output an
informational message, for example when run with the -v (verbose)
option, they would mistakenly exit with EXIT_FAILURE. A further
limitation of the gctl_error() function was that it could only be
called once. Messages from any additional calls to gctl_error()
would be silently discarded.
To resolve these problems a new function, gctl_msg() has been added.
It can be called multiple times to output multiple messages. It
also has an additional errno argument which should be zero if it is
an informational message or an errno value (EINVAL, EBUSY, etc) if
it is an error. When done the gctl_post_messages() function should
be called to indicate that all messages have been posted. If any
of the messages had a non-zero errno, the utility will EXIT_FAILURE.
If only informational messages (with zero errno) were posted, the
utility will EXIT_SUCCESS.
Tested by: Peter Holm
PR: 265184
MFC after: 1 week
With clang 15, the following -Werror warning is produced:
sys/dev/agp/agp.c:910:16: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
agp_find_device()
^
void
This is because agp_find_device() is declared with a (void) argument
list, and defined with an empty argument list. Make the definition match
the declaration.
MFC after: 3 days
Replace struct timeval in header with struct timespec.
To differentiate header formats, add a new KTR_VERSIONED flag
set in the header type field similar to the existing KTRDROP flag.
To make it easier to extend ktrace headers in the future,
extend the existing header with a version field (version 0 is
reserved for older records without KTR_VERSIONED) as well as
new fields holding the thread ID and CPU ID.
Reviewed by: jhb, pauamma
Differential Revision: https://reviews.freebsd.org/D35774
MFC after: 2 weeks
