We don't have anything to tunnel without INET or INET6, so just smack
it with the same config(5) hammer that ovpn uses and exclude it from
such builds.
Reported by: mjg
Reviewed by: emaste, markj
Differential Revision: https://reviews.freebsd.org/D60896
c4640126f1 ("loader.efi: Apply command-line DHCP overrides earlier")
was really good, but moving it just one statement earlier is even
better. polarian on Libera describes a GELI setup on a system that
doesn't advertise a serial console via ConOut. They don't have serial
input at the point that they would get prompted for the GELI passphrase,
but if we parse args just before devinit() then he can override the
console with `efibootmgr -e`. This gives UEFI one advantage over BIOS
loader, as /boot.config isn't available to provide that kind of override
if your impediment is GELI.
We also considered reading loader.env earlier, but we have a chicken/egg
problem in that we must have probed for the ESP to be able to open() it.
We would instead need a devinit_early() and devinit_late() scheme that
allows GELI probing to be deferred until the later pass, after reading
loader.env to pick up the console override. That's an idea I'd still
like to discuss because it's more robust than hoping that firmware won't
wipe out our efibootmgr(8) entries.
Tested by: polarian on Libera
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D60449
When doing a basic `jls -n`, jls(8) will jailparam_get() the mac.label
for every jail on the system using the same set of jailparams, and thus
the same jp_value. We only init the mac_t the first time, so the first
jail would populate it with `?` from /etc/mac.conf and the resulting
jail_get(2) would clobber it with the empty string, then a second jail
would try to pass the empty string to the kernel and fail because it
must have a non-zero length.
Fix it by invoking jps_get() every time. Drop some comments to note
that jps_get() will be invoked with zero || garbage from previous call,
and be sure that we don't leak our previous mac_t. There aren't any
other jps_get implementations at this time, so this shouldn't cause any
unexpected problems.
Reported by: ivy
Reviewed by: jamie
Differential Revision: https://reviews.freebsd.org/D57280
The original implementation assumed that the start/reply doorbells
lived within the device _CRS space, but that isn't always the case. On
my AMD Ryzen 7640U-based frame.work laptop, device memory runs from
0xc0500000-0xc0500fff while the doorbells are up around 0xc0508000.
Stop sanity checking the addresses and just map them in to work reliably
whether they're within the device range or not.
pluton_wait_reply is cribbed from tpm_wait_for_u32, but rewritten
slightly to read in just one place and to read one last time before
giving up at the end of the timeout, just in case.
Reviewed by: kbowling
Differential Revision: https://reviews.freebsd.org/D59327
If an explicit loader wasn't requested, then bhyveload(8) maintains a
/boot handle that it can use for swapping to a different flavor. This
means that we expose all of the host /boot to the sandbox for the
duration of script execution.
Add a callback to ack that we're OK with the interpreter so that
bhyveload(8) can release the bootfd. This is worth doing because it's
prior to guest script execution, so we're still running a reasonably
untainted process.
Reviewed by: imp, jhb
Differential Revision: https://reviews.freebsd.org/D58771
As noted in the comment, some headsets with a hardware sidetone are
incredibly sensitive and emit immediate feedback upon attach with the
current system-wide default of 75%. Drop it down just for snd_uaudio(4)
to avoid incredibly unpleasant surprises.
MFC after: 3 days
Reviewed by: christos
Differential Revision: https://reviews.freebsd.org/D59199
The default on my laptop is annoyingly bright, and this is a useful
feature to mitigate that. The backlight script is largely a copy of the
mixer service which provides the same value for mixers, but this one is
specifically dependant on kld to allow DRM drivers a chance to attach.
Note that it's off by default to avoid interference with DEs, and
document the capability in backlight(8). Set backlight_enable=YES in
rc.conf(5) to enable save/restore.
Relnotes: maybe
Reviewed by: bapt, ivy, manu, ziaee
Differential Revision: https://reviews.freebsd.org/D59296
The Logitech H390, for instance, has the following interface layout:
~~
7 INPUT 34 INPUT 10 INPUT
Mic (0x201) Mic (0x201) USB Stream (0x101)
| | |
v v |
19 FEATURE 35 FEATURE |
| | |
v v |
25 EXTENSION +------> 36 MIXER <---+
| |
v v
13 OUTPUT 22 FEATURE
USB Stream (0x101) |
v
16 OUTPUT
Speaker (0x301)
~~
The 7->13 path on the left is a typical microphone-in configuration,
while the right side is a little more complicated. The 34 -> 35 -> 36
leg is describing a hardware sidetone control, while the other is a
standard audio-out configuration.
During feature unit evaluation, we need to pick up the scenario of node
35 above, which is directly wiring the microphone to the speaker. Right
now we'll likely tie it to the pcm/vol levels and this unit will emit
a very prompt feedback screech, but it's really shaped more like a
MONITOR control.
This avoids mishandling feature unit 22 because that's evaluated in one
of the other cases: one of the inputs is the USB stream, so it's
wired up as a PCM.
One note on this headset: the presence of mixer 36 currently breaks the
`vol` control, leaving only `pcm` to control the volume. Given that it
has both Mic and USB input, I suspect we get a 1:1 cluster configuration
for the Mic input but something more complicated for the USB input that
we end up ignoring. Thus, "vol" might technically control the monitor
volume but isn't wired up to the USB input cluster. I have not had a
chance to confirm this, yet.
PR: 291424
Reviewed by: christos
Differential Revision: https://reviews.freebsd.org/D58779
Some devices take a little longer, and the spec doesn't really seem to
mandate a maximum. The common path in usbd_req_set_address() has
already been bumped to 1s and I have a headset (Logitech H390) that does
need a little bit longer, so let's match it in xhci.
Reviewed by: aokblast
Differential Revision: https://reviews.freebsd.org/D58717
It was intended that one could close the hole back in loader, but the
sysctl was actually not marked TUNABLE. The hardening menu option thus
did nothing, because we wouldn't read the value from kenv.
Reported by: markj
Fixes: 6e81fbf583 ("bsdinstall: add a hardening knob [...]")
Fixes: 4fd518fcb2 ("kern: add a security knob to disable [...]")
We can probaby consider these kernel bugs, in which case asserting is
not the most helpful thing we can do. Let's emit the necessary details
to stderr and exit non-zero to aid debugging these without completely
blocking the ability to export all of the well-formed metrics.
Reviewed by: rew
Differential Revision: https://reviews.freebsd.org/D57983
This improves performance by reducing the number of allocations as we
write into the memstream, both in the fully buffered case with larger
memstreams and also more trivially in the line- and un-buffered case as
they flush back to the underlying buffer more often.
The inspiration for this was taken from Apple's implementation in
https://github.com/apple-oss-distributions/libc, but expanded to include
wmemstream for consistency. I've added a test for the bug that I hit in
libder that caused me to notice this in the first place, and fixed that
bug in this version.
Reviewed by: des, jhb (both slightly previous version)
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D57355
It's useful to be able to track both facts with a single variable, but
it also makes it more difficult to change how the buffer size scales.
As an example, Apple's implementation seems to scale the buffer size by
1.5x on growth, presumably in an attempt to reduce trips into realloc().
This might be questionable in the face of stdio buffering, but avoiding
serious churn in the line- or un-buffered case is a net positive if
doing so isn't incredibly invasive.
Reviewed by: des, jhb, obiwac
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D57354
Inverting the condition after realloc*() is a minor cleanup, but makes
the success path a little cleaner to ease a future change.
Reviewed by: des, jhb
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D57353
This fixes an issue with the Solo2 (and likely some of the Nitrokey
family) where hangs would occur with OpenSSH- it issues a CANCEL prior
to closing the device unconditionally, and without draining the read
endpoint we end up seeing the response to that CANCEL the next time
OpenSSH tries to connect. This throws the entire command/response
sequence out of whack.
This call used to break Yubikeys in some situations, but the fix that
landed in 28d85db46b ("xhci: Do not drop and add bits in xhci") seems
to have addressed that- presumably we sometimes end up stopping the
command and desyncing at the controller level. This probably implies
that we need a SYNCWRITE HID quirk, but that requires a little more work
in usbhid_sync_xfer() and this doesn't seem to cause any problems in
normal usage.
Reviewed by: aokblast, wulf
Differential Revision: https://reviews.freebsd.org/D58199
Matches tcpdump naming, but without getting more intense as you add more
-t. This slightly reduces the post-processing needed on usbdump output
to diff two transactions.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D58196
Presumably surfaced by -fstack-protector-strong, rk8xx_settime was
triggering SSP when ntpd set the time on the RockPro64, at the very
least. A minor oops meant that the weeks mask was getting tossed into
the wrong field, and the mask was never populated. The mask is 0x7 for
all three of these, thus overflowing the `data` array in settime by one
byte.
PR: 296719
Reported by: jsm, "Tenkawa" on Discord
Reviewed by: mmel
Differential Revision: https://reviews.freebsd.org/D58182
This is a mask, so the new value should have taken the next bit to avoid
breaking a shell script that's interpreted by a binmisc-activated
interpreter.
Add a brief note that the new value is only used within the ELF
activator.
Fixes: 389c124fec ("imgact_elf.c indicate that interpreter [...]")
Reported by: "polyduekes" on discord, madpilot
Reviewed by: kib, sjg (both previous version)
Differential Revision: https://reviews.freebsd.org/D58063
Attempting to handle the error gracefully can easily result in missing
SIGSYS, so this was made to always succeed in
39024a8914 ("syscalls: fix missing SIGSYS for several ENOSYS errors")
and returns the nosys entry on failure.
Drop the pretense of returning an error and clean up a few dead error
paths.
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D57848
`error` here is the return value of syscall_thread_enter() rather than
the syscall itself, so the committed audit records do not reflect
reality. This is less harmful than them recording an error when the
operation actually succeeded, but it could still possibly be used to
throw off IDS techniques with things like bsmtrace.
Approved by: so
Security: FreeBSD-SA-26:45.audit
Security: CVE-2026-49426
Reviewed by: des, kib, markj, csjp
Differential Revision: https://reviews.freebsd.org/D57847
Prometheus doesn't allow spaces, let's normalize this to what we use
elsewhere for consistency. The sysctl exporter could probably do this
itself, but let's decouple that from the immediate problem: matching the
label between the exported data and in-tree is nice for greppability.
PR: 296179
Reviewed by: asomers, wulf
Differential Revision: https://reviews.freebsd.org/D57966
This is a distillation of the environment described in the PR, using
a dummy shlib and mapping it repeatedly. This takes advantage of the
guard page added in 2767a1f368 to reliably crash if rtld tries to
scale its stack usage excessively with the # DSOs loaded.
PR: 295991
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D57954
This both lets us quickly identify a slot that's been deallocated while
debugging, and forces us to take a fault if something tries to call one
of the methods anyways somehow with osd_destructors[slot - 1] == NULL.
Reviewed by: imp, jamie
Differential Revision: https://reviews.freebsd.org/D48075
It's relatively simple, but we'll do it a couple of times; pull it
out into a macro.
Reviewed by: imp (previous version), jamie
Differential Revision: https://reviews.freebsd.org/D48074
FreeBSD's vfs_mountroot() will collect `mnt_time` from every filesystem
that we mounted and use the highest timestamp as a source for the system
time if we didn't get anything from an attached RTC.
Use the rrd mechanism added to gather up a notion of the latest time
and set it on mnt_time. If the timestamp db is empty, we just fallback
to the uberblock timestamp and hope that that is in the right ballpark.
Relevant: FreeBSD PR254058[0] reporting the problem downstream
[0] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254058
Reviewed-by: Alexander Motin <[email protected]>
Reviewed-by: Brian Behlendorf <[email protected]>
Reviewed-by: Chris Longros <[email protected]>
Signed-off-by: Kyle Evans <[email protected]>
Closes#18645
Returns 0 if the database is empty, otherwise it returns the highest
value of the minutely db. dbrrd_add() will already enforce the property
that these are monotonically increasing, so we won't try to second-guess
it.
Reviewed-by: Alexander Motin <[email protected]>
Reviewed-by: Brian Behlendorf <[email protected]>
Reviewed-by: Chris Longros <[email protected]>
Signed-off-by: Kyle Evans <[email protected]>
Closes#18645
We sometimes store sensitive things in the kenv that get zapped, but we
really shouldn't rely on that zapping to actually happen. Most
unprivileged processes don't really need to read from the kernel
environment in the first place, so add a knob that allows it to be
disabled.
Note that we consider jailed root to be unprivileged from this
perspective; they have their own meta/env concepts and we should
encourage users to take advantage of those for passing information to
jails.
"Hey we should do something about that": dch
Reviewed by: imp, ziaee, zlei (all slightly previous version)
Differential Revision: https://reviews.freebsd.org/D57697
The current verbiage somewhat indicates that always adjusts the time,
which hasn't been true as far back as I had the energy to `git blame`.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D57676
The current format seems to be a little confusing, and the version of it
for index 0 was broken by the below-referenced commit. Break our
UNUSED macros out into one per unused bit to enumerate the entirety of
the space and make it easier to claim an unused one.
Fixes: b165e9e3ea ("Add fchroot(2)")
Reviewed by: oshogbo (previous version), kib, markj
Differential Revision: https://reviews.freebsd.org/D57505
so2rele was introduced in 1000cc4a0d and it was necessary there, but
the cleanup in a837d1fe49 rendered it redundant if our own KASSERT
is to be believed: we've asserted that `so2->so_splice_back == sp` and
`sp` has been dereferenced above, so there's no condition left where
we shouldn't release the socket reference at the end. Indeed, the
change in so_splice() to NULL out sp->dst removes that possible state of
a partially constructed splice: if sp->dst is set, it has been ref'd.
Reviewed by: gallatin, markj
Differential Revision: https://reviews.freebsd.org/D57558
We have a native version now, plumb it through to the Linuxolator.
Reviewed by: glebius, markj
Differential Revision: https://reviews.freebsd.org/D57427
We test both the standard case where we want to reject any SCM_RIGHTS
message, as well as the case where the kernel discards the unwanted file
upon receipt.
Reviewed by: glebius (previous version), markj
Differential Revision: https://reviews.freebsd.org/D57426
This is almost a trivial factoring, but it's still a bit of boilerplate
that we don't care to rewrite- the SO_PASSRIGHTS test will still receive
some data, so the iovec construction still saves us a few lines.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D57544
This is a little different than the others in that it's not valid for
anything but unix(4) sockets. New cases were added that jump into the
more standard case out of a light preference for not taking advantage of
case FALLTHROUGH with the additional logic- it doesn't scale very well
for new cases added that might be slightly special, so we might as well
just add the labels up-front.
Reviewed by: glebius, markj
Differential Revision: https://reviews.freebsd.org/D57424
With exception to sockopt functionality, implement the so_options flag
in unix(4) itself. The general argument for the flag is that SCM_RIGHTS
can be used maliciously for, e.g., a DoS that the receiving side can't
avoid if it is expecting other control messages.
This option gives the receiver a way to disable SCM_RIGHTS on the
sender-side, surfacing an EPERM to them instead. This seems to match
the semantics that Linux offers.
If an SCM_RIGHTS was already sent before we disabled SO_PASSRIGHTS, then
a subsequent recvmsg(2) will silently discard any in-flight files. This
has the downside of punting a file with the potential to hang over to
the deferred-close task, but perhaps usage of the option would
discourage folks from attempting to take advantage of that possibility
anyways.
Various manpages updated to describe the new behavior.
The ru_msgsnd accounting here might need to be re-evaluated: some error
paths will increment it while others will not, and it isn't really
clearly labelled. At some point in the operation enough work has been
done that one could consider it enough resources to count, but it's not
obvious that it should work this way. This change doesn't attempt to
address that.
Reviewed by: glebius
Differential Revision: https://reviews.freebsd.org/D57423
For native files we can do more minimal fixes to avoid this large of a
hammer, but for third party files it may not be worth the effort to try
and patch them. NetBSD has the original _FORTIFY_SOURCE implementation
that ours is based on, for instance, but tests sourced from there can't
do an __ssp_real(foo) without being certain that `foo` actually has a
fortified definition.
This change does always define _FORTIFY_SOURCE as a result, so gate it
on CFLAGS not already containing _FORTIFY_SOURCE definitions.
This re-applies c46a0b5907, but without re-defining _FORTIFY_SOURCE
needlessly.
PR: 294881
Reviewed by: markj, sjg (both previous version)
Differential Revision: https://reviews.freebsd.org/D57356
This is useful for driving BE changes from the loader command prompt,
rather than having to use the menu. Note that the active carousel in
the boot environment carousel doesn't currently reflect a switch in
boot environments done this way- I'm considering this only a minor bug,
as you probably can't or won't go back to the menu if you're using these
commands.
Reviewed by: imp (previous version)
Specifically on the RPi CM4, we currently don't set the controller up
right and it never moves into the ready state (we don't observe the link
active bit). Failure to cleanup here actually results in a panic not
long after, due to a use-after-free in the rman bits. Further down in
pci_host_generic, we have some rman stashed in the softc that are
initialized and placed onto the rman tailq, then the softc is later
freed without an rman_fini() to pull them off of the tailq properly.
Note that PCIe on this board won't come up at boot without something
plugged in, so it currently can't be booted with an empty slot with the
intent to hotplug a supported card. Some issues with controller startup
have been observed with Broadcom NICs in the wild, but no problems have
been observed with other NICs and a variety of different PCIe cards.
Shout-out to Vince <[email protected]> for the extensive debugging and
analysis to arrive at this conclusion.
Reviewed by: andrew, imp
Differential Revision: https://reviews.freebsd.org/D56897
If device_attach() fails, we're expected to actually cleanup after
ourselves because device_detach() will not be called. Factor out the
cleanup bits that don't rely on attach having actually succeeded so
that we can cleanup properly in bcm2838_pci.
Reviewed by: andrew, imp
Differential Revision: https://reviews.freebsd.org/D56896
For symmetry with ofw_bus_setup_iinfo, the next commits will use it to
properly cleanup on failure in bcm2838_pci.
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D56895
The new KPI is only used in <asm/set_memory.h>, but it's provided in
linux_page.c. The latter only includes the former indirectly by way of
<linux/io.h>, and that's only conditionally included outside of 32-bit
ARM there.
All of our archs have the necessary pmap_page_set_memattr(), so just
move the declaration into <linux/page.h> instead of trying to reason
about the usability of <asm/set_memory.h> directly in linux_page.c.
Reported by: jenkins (via ivy)
These calls are used for buddy pages at least in drm's ttm_pool, which
leads to a panic when we invoke lowmem handlers and drm tries to shrink
the pool.
Cope with numpages > 1 by traversing the contiguous pages and executing
the adjustment there, as well, as suggested by markj@. Previous
versions have tried to use the corresponding `set_memory_*()` functions,
but it is believed that not updating `md.pat_mode` breaks subsequent
userspace mappings in ways that may result in things like screen tearing
or other artifacts when running i915kms.
This stabilized my amdgpu laptop running two VMs, chromium and a
concurrent buildworld.
Reviewed by: bz, markj
Differential Revision: https://reviews.freebsd.org/D57004
This and the E3000 are both handled by the r8169 driver in Linux, and
reportedly this is infact just a straight re-brand of the RTL8126.
Tested by: "Sinetek" on Discord
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D56917
We note a reason why you might need it, but there's an equally important
reason you may need to omit it: interpreted programs. Add a note
accordingly, along with the workaround configuration if there's reason
you can't help it.
PR: 294780
Reviewed by: Jan Bramkamp <crest_freebsd_rlwinm.de>, kib
Differential Revision: https://reviews.freebsd.org/D56704
Besides being a little hard to parse through visually, this had its own
bug of inspecting st->st_mode to determine what to pass to devname(3),
which is only correct for st_rdev.
For st_dev, you're likely to be looking at files or directories and
attempting to assess what device they're located on, so the mode is
meaningless- we just have to assume that our filesystems are on
character devices and attempt to resolve st_dev as such.
Reviewed by: des, kib (previous version)
Differential Revision: https://reviews.freebsd.org/D56565
The getgroups test is a NetBSD tests, so just apply our larger hammer
and disable the feature entirely. The audit test can take a more
surgical approach and use __ssp_real() appropriately, since it's a local
one.
PR: 294881
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D56735
Annex K specifies an interface for handling constraint violations from
gets_s, but we previously broke this for some classes of get_s misuse.
Provide a more nuanced version that tries to dodge errors that would
trigger a constraint handler while still providing value. Notably, we
don't want to trigger a failure unless the passed-in length reasonably
fits within an RSIZE_MAX, because gets_s will immediately call larger
lengths bogus and fail.
PR: 294881
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D56734
For native files we can do more minimal fixes to avoid this large of a
hammer, but for third party files it may not be worth the effort to try
and patch them. NetBSD has the original _FORTIFY_SOURCE implementation
that ours is based on, for instance, but tests sourced from there can't
do an __ssp_real(foo) without being certain that `foo` actually has a
fortified definition.
This change does always define _FORTIFY_SOURCE as a result, so gate it
on CFLAGS not already containing _FORTIFY_SOURCE definitions.
PR: 294881
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D56733
The current and historical versions of ctld would flag our initial set
of kernel ports as dummies, because their portal groups were empty since
portals come from the configuration on-disk.
As a result, we would never try to remove a kernel port at startup that
didn't exist in the configuration (possibly a feature if you wanted
concurrent ctld(8)), and we would always try to port->kernel_add() on
ports in the configuration (even if they actually did have an existing
kernel port).
Flag these portal groups as kernel groups so that we avoid trying to add
ports that already exist. It may be the case that the kernel_remove()
loop in conf::apply() needs to do something other than the current
`oldport->is_dummy()` to avoid removing ports that it isn't supposed to
be managing, but that wuld also seem to apply to LUNs that would be
removed today.
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D51782
Various calls in the implementation can clobber errno; preserve it for
the caller since none of these will bubble up pass/fail to simplify
some future error handling in ctld.
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D56539
The specificgid functionality has historically allowed only a single
group to be exempt, but in practice one might want a few services to
be exempt for reasons. From a security perspective, we probably don't
want to encourage unrelated users to be grouped together solely for
this purpose, as that creates one point of shared access that could be
used for nefarious purposes.
Normalize the group list as we do cr_groups to allow for linear matching
rather than quadratic, we just need to account for the differences in
FreeBSD 15.0+ where cr_groups is entirely supplementary groups vs.
earlier versions, where cr_groups[0] is the egid and the rest is
sorted.
Reviewed by: csjp, des (earlier version)
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D56592
mpc_name and mpc_fullname are string literals in correct usage, so they
should really be const instead.
mpc_ops aren't typically const, but the framework shouldn't be doing
anything to clobber it; thus, good to constify it as a reminder.
Switch to using a slightly more semantically correct `void **` in the
fastpath bits while we're here, since we only do arithmetic on the outer
layer of pointer and compare the inner to a pointer-typed (NULL).
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D55702
The unmount check is straightforward and only really needs the
struct mount and flags used, in case a MAC policy wants to reject
force-unmounts or do special handling for FSID-based unmounts.
The mount check offers as much information as I think might be of
interest to a MAC policy: the vnode to be mounted on, vfsconf, and
applicable mount options. XNU also has a later version that just takes
a struct mount for everything that VFS_MOUNT() has to offer, but my
draft policy doesn't need any of that. It also doesn't really need the
unmount check, but it seems reasonable to add it while I'm here.
The update check similarly passes the flags/options for the operation,
along with the struct mount and label.
Reviewed by: kib, olce
Differential Revision: https://reviews.freebsd.org/D55601
The new version of incrementing `jid` is a little cleaner and harder to
mess up, and also fix a nwlin omission while we're here.
These comments were dropped on D51502; ngie takes a co-author credit
so that they're not blamed for the commit message, but I can't claim
that I tweaked their suggestions.
Co-authored-by: ngie
Nobody will test it as long as it's not tied into the top-level target,
and we don't really have a good reason not to cut over to it since it
does produce identical results. Switch over but do not remove the old
sh implementation yet, just in case.
Note that this replacement is driven by a significant speedup from how
the new version is designed: tha lua version actually tries to
parallelize its data collection efforts to speed up generation.
Reviewed by: imp (previous version), emaste
Differential Revision: https://reviews.freebsd.org/D56558
161f8edc65 ("bsd.mkopt.mk: Prepare a list of all build options")
restructured things and now we should simply strip the leading double
underbar. This fixes the oddity noticed in
4ed20e0236 ("kshim/usb: Add build option."), where WITH_CASPER made
a surprise appearance.
This is a part of D56558, but not the meat of the change.
Reviewed by: emaste, imp
AMD64 Architecture Programmer's Manual Volume 3 says the following:
> ECX[15:0] contains a count of the number of sequential pages to
> invalidate in addition to the original virtual address, starting from
> the virtual address specified in rAX. A count of 0 invalidates a
> single page. ECX[31]=0 indicates to increment the virtual address at
> the 4K boundary. ECX[31]=1 indicates to increment the virtual address
> at the 2M boundary. The maximum count supported is reported in
> CPUID function 8000_0008h, EDX[15:0].
ECX[31] being what we call INVLPGB_2M_CNT, signaling to increment the
VA by 2M.
> This instruction invalidates the TLB entry or entries, regardless of
> the page size (4 Kbytes, 2 Mbytes, 4 Mbytes, or 1 Gbyte). [...]
Combined with this, my interpretation of the current code is: if
<va> is aligned on a PDE boundary, we'll use INVLPGB_2M_CNT to try and
invalidate <cnt> PDEs with a single call, but that only works if <va> is
the start of at least <cnt> 2M pages. Otherwise, if <va> or any of the
subsequent PDEs isn't actually a superpage, then we would actually only
invalidate the *first* page within the PDE before skipping to the next
PDE, leaving the remainder of the 4K pages in between as they were.
The implication would seem to be that we would need to inspect the range
that we're trying to invalidate if we're planning on using
INVLPGB_2M_CNT at all, so this patch just simplifies it to a series of
4K invalidations. My gut feeling is that we likely still come out on
top vs. the TLB shootdown we're avoiding.
This seems to explain some issues we've seen lately with fdgrowtable()
and kqueue on recent Zen4/Zen5 EPYC hardware, where we'd experience
corruption that we can't explain.
PR: 293382
Reviewed by: alc, kib, markj
Differential Revision: https://reviews.freebsd.org/D56458
Notably, confirm in the child that our close-on-fork fd is actually
closed, and break RECV_ALL out into a table and check each bit
individually to provide a better message when the test fails.
While we're here, just switch to waitid() rather than trying to identify
the point where we have to make the switch. This reduces maintenance
slightly, as keeping our assertion static would require still adding to
a _RECV_ALL mask *just* for that purpose.
Reviewed by: kib, markj (both slightly earlier version)
Differential Revision: https://reviews.freebsd.org/D56372
This is not a functional change, but it makes it more clear upon
inspection of the definition that the mapping property described is
preserved. Maybe more importantly, if one ends up getting an index
wrong or punching a hole in the name array unexpectedly, then it'll
hopefully manifest more clearly as a (null) or nullptr deref rather than
potentially just emitting the wrong namespace name.
It's noted that this almost certainly invalidates its use in C++, but
there aren't really any known C++ consumers of it- let's just cross
that bridge if we get there.
Reviewed by: kib, mckusick, rmacklem
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D55323
We use -xattr in our openrsync tests for convenience, and it seems like
a good addition to FreeBSD. -xattr and -xattrname will both consult all
available namespaces by default, but -xattrname allows filtering by
namespace using a "user:" or "system:" prefix.
Inspired by: https://github.com/apple-oss-distributions/shell_cmds
Reviewed by: kib, rmacklem
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D55286
The 'simplification' commit referenced below actually broke one aspect
of MFD_HUGETLB: the caller isn't supposed to be required to specify a
size. MFD_HUGETLB by itself without a shift mask just requests a large
page, so we revert that part of memfd_create() back.
While we're here, fix up the related parts of the manpages a little bit,
since MFD_HUGETLB is actually supported. The manpage claims that we
would return ENOSYS if forced mappings weren't supported, but this was
actually not true. However, that seems like a very important
distinction to make between ENOSYS and EOPNOTSUPP, so fix the
implementation to match the docs.
Fixes: 8b8cf4ece6 ("memfd_create: simplify HUGETLB support [...]")
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D56114
This is purely a cosmetic change to make it a little easier on the eyes,
rather than jumping back to the else branch up top. Re-flow it to use
another loop on the outside and just inline the re-lock before we repeat
after awaking from fluxwait.
The !killkn path should maybe issue a wakeup if there's a thread in
KQ_SLEEP so that userland can observe the EOF, but this isn't a
practical problem today: pretty much every case of knlist_clear is tied
to a file descriptor and called in the close(2) path. As a consequence,
potentially affected knotes are almost always destroyed before we even
get to knlist_clear().
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D56226
Just copy over a timer and a write-filter, be sure that we can observe
both in the child. Maybe the timer should check for a minimum time
passed, but I don't know that we'd be likely to get that wrong.
This also adds a negative test with a kqueue that is *not* set for
CPONFORK being added to the first one, made readable, and confirming
that we don't see a knote for it in the child.
Some other improvements to the test noted in the review are planned in
the short term, but they're not particularly worth blocking adding this
as a basic sanity check.
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D56223
We'll subsequently just knote_free() since the knote is barely
constructed, but that bypasses any logic that might release references
on owned files/fops. Defer clearing those until the knote actually owns
them and update the comment to draw the line more clearly.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D56318
This allows something like the following local.lua to install a filter
to implement its own notion of hidden BEs using a naming convention of
a leading dot to hide them:
-- file: /boot/lua/local.lua
local core = require("core")
local function be_hide(be)
if core.isSingleUserBoot() then
-- All BEs are accepted for single-user
return true
end
local name = be:match("/([^/]+)$")
if not name then
-- Accept malformed BEs, for whatever reason
return true
end
return name:match("^%.") == nil
end
if core.bootenvFilter then
-- Just in case we need to be compatible with older versions of
-- core.lua without the filtering functionality.
core.bootenvFilter(be_hide)
end
-- EOF
Requested by: Marek Zarychta
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D55359
We currently assert that kn_status is accurate, but there's more room
for error. Neither of these are very likely, but currently we'd blow up
in SLIST*() macros instead of providing more obvious diagnostics. It's
perhaps only worth testing these because knlist_remove() requires
getting logic across both f_attach() and f_detach() correct.
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D56211
The influx logic in knote_fdclose() is a little misguided, the resulting
wakeup() call should always be redundant: knote_drop_detached() will
always issue a wakeup before it returns, so anything waiting on *that*
knote that had entered fluxwait should have been woken up then. This is
the obvious divergence from the other influx/wakeup pattern in the
implementation, which will kn_influx-- and then issue the wakeup after
it has processed all of the knotes it can make progress on.
While we're here, the kq_knlist cannot shrink, so we can avoid that
condition in the loop and avoid potentially excessive wakeups from
fluxwait on kqueues that we didn't touch.
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D56210
kqueue_fork_copy() is likely to have transitioned at least one knote
through a flux state, so we should check whether we need to wake
anything up on the way out to avoid a possible deadlock.
This was a part of D56210, but we'll close the review with the next
commit.
Fixes: b11289f871 ("kqueuex(2): add KQUEUE_CPONFORK")
Reviewed by: kib, markj
This is a cosmetic change, rather than a functional one: comparing the
knlistsize against the fd requires a little bit of mental gymnastics to
confirm that this is fine and not doing unnecessary work in some cases.
Notably, one must consider that kq_knlistsize only grows in KQEXTENT
chunks, which means that concurrent threads trying to grow the kqueue
to consecutive fds will usually not result in the list being replaced
twice. One can also more clearly rule out classes of arithmetic
problems in the final `else` branch.
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D56209
These are non-standard and specific to the version used in loader. We
have some desire to recognize symlinks to avoid filtering out kernel
symlinks in the autodetection bits when they would be perfectly fine to
`load`.
This won't be usable right away, so any impending use will need to be
careful to account for nil.
Reported by: leres
memchr(3) will happily believe we've passed in a valid object, but
hostsize could easily exceed the bounds of fullhost. Clamp it down to
the string size to be safe and avoid UB. This plugs a potential
overread noted in the compat shim that was just added.
Reviewed by: des
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D54623
INT_MAX is already larger than a reasonable hostname might be, but
size_t makes some of this easier to reason about as we do arithmetic
with it. This would maybe not be worth it if we had to bump the
soversion because of it, but libutil does symbol versioning now so we
can provide a compat shim.
While we're here, fix some inconsistencies in argument names in the
manpage.
Reviewed by: des
Obtained from: https://github.com/apple-oss-distributions/libutil
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D54622
It's not at all clear why I wrote it like this, but we can do better.
I wouldn't think this really has any meaningful security implications
since the hierarchy in question can't really be modified by the guest
scripts, but it would seem to make it a little more robust.
Fixes: 6779d44bd8 ("bhyveload: use a dirfd to support -h")
Reviewed by: bnovkov, markj
Differential Revision: https://reviews.freebsd.org/D55379
As written, we'll repeatedly jps_free() the first element, which is
obviously bogus. Fix it to index appropriately.
Fixes: db3b39f063 ("libjail: extend struct handlers [...]")
The MAC framework provides a lot of useful functionality that can be
configured per-jail without requiring the use of labels. Having another
entry point that we invoke just for general prison cleanup rather than
freeing the label is useful to allow a module that can otherwise work
off of a series of MAC entry points + sysctls for configuration to free
its per-jail configuration without having to bring in osd(9).
One such example in the wild is HardenedBSD's secadm, but some of my
own personal use had wanted it as well- it was simply overlooked in the
final version because my first policy made more sense with labels. On
that note, it's expected that prison_cleanup and prison_destroy_label
will effectively be mutually exclusive -- the former only used when
a label isn't needed, the latter when it is.
Note that prison_cleanup isn't perfectly symmetrical w.r.t.
prison_created: the latter takes a label as well, because it's called
later in jail setup and a better point for propagation than when the
label is created.
As discussed with olce@, we may want to later revisit the notion that
struct labels get passed around explicitly along with the referenced
object and consider stripping them from all entry points in favor of
an object -> label accessor or something.
__FreeBSD_version bumped to force a rebuild of MAC policies.
Reviewed by: olce
Differential Revision: https://reviews.freebsd.org/D54833
In particular, if one simply does a non-recursive `ls` on a directory
that is not accessible, there are some classes of errors that may cause
it to fail that wouldn't be surfaced unless we do an fts_read() that
will recurse into the inaccessible directory. Catch those kinds of
errors here since we cannot expect to an FTS_ERR/FTS_DNR entry to follow
up on them.
PR: 287451
Reviewed by: kib
Discusssed with: des
Differential Revision: https://reviews.freebsd.org/D51056
There were a few problem here:
- TPM2_Shutdown results in a response that we need to either process
or ignore, otherwise any tpm20_write or tpm20_harvest call will
trivially hang on an `sc->pending_data_length != 0`
- We should have a matching TPM2_Startup upon resume to restore any
state that should have persisted
- We must drain the harvest task before we suspend to avoid problems
there
This commit is sufficient to avoid breaking suspend/resume.
PR: 291067
Fixes: a2d5ed9442 ("Introduce driver for TPM 2.0 in CRB and [...]")
Fixes: 4ee7d3b011 ("Allow using TPM as entropy source.")
Co-authored-by: markj (D53835)
Tested by: garga
Differential Revision: https://reviews.freebsd.org/D55074
The Pluton startmethod uses a simple doorbell mechanism to wakeup the
TPM unit after we've issued various forms of state change, with the
registers to use specified in the startmethod-specific segment of the
TPM2 table (up to 12 bytes after the StartMethod).
At the very least, this is the kind of TPM in use by my AMD Zen 4-based
Minisforum machine.
Differential Revision: https://reviews.freebsd.org/D53683
The tmp rc script has much the same problem that the var does: it wants
to test if /tmp is writable, and mount a tmpfs if it's not. This means
that we actually want our zfs datasets mounted first, because we might
have a /tmp dataset that changes the story.
The ordering problem is particularly noticable with a r/o zfs root,
since the write test will fail and we'll mount a tmpfs that later gets
covered by our /tmp dataset. If that /tmp dataset inherited readonly,
then we're still in trouble.
This also fixes `tmpmfs=yes`, which would again get covered by a zfs
dataset with the existing ordering.
Reviewed by: des
Differential Revision: https://reviews.freebsd.org/D54995
lposix is the last holdout of modules built into flua until we can fix
the module design to have the right parts require()able. Address a
valid bug in lua_read() found at a higher WARNS and drop the override
entirely. Some of the modules could possibly be re-evaluated.
Fixes: c2caf3b331 ("flua: lposix: add more useful functions [...]")
Reported by: des
Reviewed by: des
Sponsored by: Klara, Inc.
Sponsored by: NetApp, Inc.
The struct spacectl_range we use is only really used in these three
lines of code, so re-scope it down to just the dealloc branch. This is
marginally easier to reason about what might be necessary to replace in
porting our truncate(1) to other platforms.
While we're here, add a test for the -d flag to be sure it really does
punch a hole in the file. The test also tries to confirm that it does
not disturb other segments of the file in the process, just to inspire
some confidence that it's not corrupting the file somehow.
Sponsored by: Klara, Inc.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D51207
Nobody else's mac.conf(5) has any entries for jails, so they get a
trivial ENOENT and we fail before we can fetch any jail parameters.
Most notably, this breaks `jls -s` / `jls -n` if you do not have any
loaded policy that applies jail labels.
Add an entry that works for everyone, and hardcode that as an ENOENT
fallback in libjail to provide a smoother transition. This is probably
not harmful to leave in long-term, since mac.conf(5) will override it.
This unearthed one additional issue, in that mac_get_prison() in the
MAC framework handled the no-label-policies bit wrong. We don't want
to break jail utilities enumerating jail parameters automatically, so
we must ingest the label in all cases -- we can still use it as a small
optimization to avoid trying to copy out any label. We will break
things if a non-optional element is specified in the copied in label,
but that's expected.
The APIs dedicated to jaildescs remain unphased, since they won't be
used in the same way.
Fixes: db3b39f063 ("libjail: extend struct handlers [...]")
Fixes: bd55cbb50c ("kern: add a mac.label jail parameter")
Reported by: jlduran (on behalf of Jenkins)
Reviewed by: jlduran
Differential Revision: https://reviews.freebsd.org/D54786
The prison may also be considered part of the subject by way of its
ucred association, but I don't think this is significantly different
enough today than before recent work -- policies could have always
taken them into account, and some did (e.g., mac_bsdextended).
Reported by: olce
Reviewed by: olce, ziaee
Differential Revision: https://reviews.freebsd.org/D54748
In particular, we should provide a hint about mac.conf(5), since libjail
will just use the mac_prepare_type(3) API to provide a reasonably sane
interface for system administrators. Progammers wanting to fetch an
arbitrary MAC label would need to bypass libjail and use jail_get(2)
directly with their own prepared `struct mac`.
Differential Revision: https://reviews.freebsd.org/D54067
MAC label handling is a little special; to avoid being too disruptive,
we allocate a `mac_t *` here for the value so that we can mac_prepare()
or mac_from_text() into. As a result, we need:
- A custom free() handler to avoid leaking the *jp_value
- A custom jailparam_get() handler to mac_prepare() the mac_t and
populate the iove properly, so that the kernel doesn't have to
do something funky like copyin, dereference, copyin again.
- A custom jailparam_set() handler to similarly populate the iovec
properly.
Reviewed by: jamie
Differential Revision: https://reviews.freebsd.org/D53960
Instead of ad-hoc comparisons against the struct type in a few places,
start to abstract out an interface for dealing with struct types. For
now, this just means that we have some special jailparam_import and
jailparam_export handling for the ip addr types, but in the next commit
we'll extend it further to support MAC labels.
Reviewed by: jamie
Differential Revision: https://reviews.freebsd.org/D53959
Have it take a `struct mac` and we'll paper over the difference for
jail(8)/jls(8) in libjail(3). The mac_syscalls.h model is taken from
mac_set_proc_*() that were previously done.
Reviewed by: olce
Differential Revision: https://reviews.freebsd.org/D53958
A future commit to the area will further our jail integration and add
a use for this: the struct mac itself was already copied in as part of
vfs_buildopts(), so we only need to copyin the strings.
We add an explicit flag argument because the jail operation will need to
do it while holding the prison lock.
Reviewed by: olce
Differential Revision: https://reviews.freebsd.org/D53957
We'll still add an old-fashioned jail param to configure jail MAC
labels, but for testing it's really easy to grab a jaildesc and use
that.
Reviewed by: jamie, olce
Differential Revision: https://reviews.freebsd.org/D53956
We'll subsequently use this in the MAC framework to get a struct prison
when we already have the struct file in question, rather than an fd.
Reviewed by: jamie, olce
Differential Revision: https://reviews.freebsd.org/D53955
This adds the following hooks:
- mpo_prison_check_attach: check for subject capability to attach to
a given jail
- mpo_prison_check_create: check for subject capability to create a
jail with the given option set
- mpo_prison_check_get: check for subject capability to fetch the
given parameters for a jail
- mpo_prison_check_set: check for subject capability to set the
given parameters for a jail
- mpo_prison_check_remove: check for subject capability to remove the
jail
check_get wouldn't typically be a privileged operation, but is included
to give MAC policies a wider range of capabilities at a relatively low
cost. We also add two more for the purpose of label propagation:
- mpo_prison_created: surface the creation of a jail so that one can
do propagation to, e.g., the root vnode or any mounts
- mpo_prison_attached: attach an existing process to the jail so that
one can propagate the jail label to the process, as appropriate.
It is unclear if this is preferred vs. having separate associate entry
points for each type of object we might associate. That would split
these up like so:
- prison_created -> prison_associate_vnode
- prison_attached -> prison_associate_proc
Some sample policy ideas that should be feasible to implement with this
set of hooks, in case it's inspiring:
- mac_bomb: policy that allows a poudriere user to construct jails
without root privilege, given a restricted set of jail parameters.
Slap a warning label on it.
- mac_capsule: policy that realizes the capsule idea that I pitched[0]
on -jail@ to create jails that are effectively immutable once
sealed, using these hooks and a label.
Perhaps a silly idea, but a downstream could consider a scenario where
it can implement special jail enumeration using a MAC policy and a
cooperating application that specifies non-parameter options to filter
the results.
[0] https://lists.freebsd.org/archives/freebsd-jail/2025-September/000550.html
Reviewed by: olce (slightly earlier version)
Differential Revision: https://reviews.freebsd.org/D53954
A last-minute change to the jail MAC entry points in D53954 is going to
pass the jail_[gs]et(2) flags to mac_prison_check_[gs]et() so that a
policy can, e.g., reject or allow a change if the intent is to
immediately attach, or disallow some fetching of dying jails.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D54658
Kyle Evans