linux: Allow connect() with destination port 0
Linux allows connect() with destination port 0, but FreeBSD returns
EADDRNOTAVAIL in in_pcbconnect() and in6_pcbladdr(). Some Linux programs
(e.g. the new Android CLI tool) rely on this for routability checks,
however.
Add an SV_CONN_PORT0 flag to sv_flags which is set in the Linux sysvecs,
allowing the port 0 guard in the connect paths to be bypassed.
Reviewed by: glebius, kib
Differential Revision: https://reviews.freebsd.org/D60659
kern_linker.c: add kern_ implementations
kldsym(2) is more complex than typical because it requires translation
of struct kld_sym_lookup which is a weird in/out structure. Out of
paranoia we avoid copying out the symname pointer in the capability
version to eliminate the possiblity of leaking a capability (but not
invalidating a pointer userspace might be using via copyout()).
Effort: CHERI upstreaming
Sponsored by: DARPA, AFRL, Innovate UK
Pull Request: https://github.com/freebsd/freebsd-src/pull/2284
wait6(2): add user_wait6
sys_wait6 is a little more complicated than typical as compat layers
need to translate siginfo_t.
Effort: CHERI upstreaming
Sponsored by: Innovate UK
Pull Request: https://github.com/freebsd/freebsd-src/pull/2284
adduser.conf.5: No crossreferences in titles
Crossreferences in titles are strongly discouraged and incompatible
with our own tooling. This is a wontfix by most of manpages ecosystem
because it is bad editorial style in the first place.
MFC after: 3 days
freelocale.3: No crossreferences in titles
Crossreferences in titles are strongly discouraged and incompatible
with our own tooling. This is a wontfix by most of manpages ecosystem
because it is bad editorial style in the first place.
MFC after: 3 days
fmtcheck.3: No crossreferences in titles
Crossreferences in titles are strongly discouraged and incompatible
with our own tooling. This is a wontfix by most of manpages ecosystem
because it is bad editorial style in the first place.
MFC after: 3 days
arch.7: Mechanical fixes
+ Increase portability by never starting content lines with symbols
+ Improve search results by adding tunables to the variable database
+ Improve search result consistency by correcting description style
MFC after: 3 days
openssl: export only the engine entry points
Upstream links every dynamic engine with a version script,
engines/<name>.ld, that exports bind_engine and v_check and makes
everything else local. FreeBSD's engines had no version script, so
they exported every global symbol, including _init and _fini.
loader_attic.so compiles its own copy of crypto/pem/pvkfmt.c and so
also exported 21 of its functions; 14 of them (b2i_*, i2b_*) have the
same names as public libcrypto functions.
Add one Version.map for all engines, the same as upstream's, and use it
from engines/Makefile.inc.
The engines are loaded only with dlopen(), and libcrypto looks up only
bind_engine and v_check, so hiding the other symbols does not affect
any consumer.
Tested via tinderbox: capi.so, devcrypto.so and loader_attic.so link
with --no-undefined-version and export only bind_engine and v_check.
[8 lines not shown]
openssl: fix engine defines to match upstream
Two engine Makefiles define different macros from upstream's
engines/build.info:
- padlock: engines/e_padlock.c builds the engine only when PADLOCK_ASM
is defined. Upstream defines it on x86 and x86_64, but our Makefile
never did, so padlock.so has been a stub whose bind_engine() returns
0 and the e_padlock-x86*.S code it links was never called. Define
PADLOCK_ASM on amd64 and i386, where that asm is built.
- loader_attic: upstream defines OPENSSL_NO_PROVIDER_CODE; the Makefile
had OPENSSL_NO_PROVIDER_CORE. No source tests either name, so the
build does not change; this only follows upstream.
Found by comparing per-file compile flags against an upstream 3.5.9
build. Checked by preprocessing e_padlock.c for amd64 and i386:
COMPILE_PADLOCKENG is now defined.
[5 lines not shown]
tests/sys/file: add tests for the lowest fd after fork
fdcopy() skips plain kqueues and close-on-fork descriptors when it
copies the table into the child. Check that dup(2) in the child still
returns the lowest unused descriptor, both when the skipped descriptor
is the lowest free slot and when it sits above an existing hole.
Test cases:
kqueue_no_hole a plain kqueue is the lowest descriptor; the
child's dup() reuses its slot
kqueue_two two adjacent plain kqueues; the child's dup()
returns the lower one
kqueue_above_hole a plain kqueue sits above a closed descriptor;
the child's dup() returns the hole
kqueue_cponfork a KQUEUE_CPONFORK kqueue is copied; the child's
dup() returns the next slot
clofork_no_hole an O_CLOFORK descriptor is the lowest one; the
child's dup() reuses its slot
[14 lines not shown]
virtio_random: defer first enqueue until after DRIVER_OK
According to the virtio spec:
> The driver MUST NOT send any buffer available notifications to the
> device before setting DRIVER_OK.
DRIVER_OK isn't set until after attach completes, so defer the first
enqueue. We haven't found any problems as a result of this to the best
of my knowledge: q35 and other devices that we *have* been used with
will apparently check when we go DRIVER_OK.
Tested with q35 virtio-random, which still works.
Reported by: llm-postcr
Reviewed by: kfv, markj
Fixes: f1c5a2e3a62505 ("virtio_random: Pipeline fetching the data")
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
[2 lines not shown]
virtio_random: stop on detach, don't poll
If the device is hung, then polling will block the detach and hang us.
Stop it and drain the queue instead. This fixes a hang on detach in
some circumstances without the upcoming virtio_pci_modern fix.
Reviewed by: bnovkov, kfv
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
(cherry picked from commit cce522853aae3da45b131c2522dd2510edf083e7)
virtio_pci_modern: enable virtqueues before completing attach
Most of our drivers setup interrupt(s) and virtqueues are enabled at
that time, but nothing will currently enable them for devices that we're
only going to poll. This most notably affects virtio-random, and the
problem can be observed with qemu's q35 emulation and a random device
attached. The q35 implementation ignores the ring unless it's enabled,
so vtrnd_harvest() will consistently EAGAIN rather than contribute
anything of value, but with this patch it becomes functional.
This can be reproduced with a qemu invocation like so:
qemu-system-x86_64 -machine q35,accel=tcg -cpu max -smp 2 -m 2G \
-drive file=FreeBSD-16.0-CURRENT-amd64-ufs.qcow2,if=virtio \
-device pcie-root-port,id=rp1,bus=pcie.0,chassis=1 \
-object rng-random,id=rng0,filename=/dev/urandom \
-device virtio-rng-pci,rng=rng0,bus=rp1 \
-display curses
[5 lines not shown]
virtio_random: avoid using vtrnd_detach in the failure path
On the off chance that we discover more than one virtio-random device,
the second one will deregister the global instance or trip an invariant
when it fails to attach and calls vtrnd_detach().
We don't have that many resources to free, so just inline those. This
is purely a hygiene thing, we haven't seen an instance of this in the
wild (to my knowledge).
Reviewed by: bnovkov, kfv
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
(cherry picked from commit 26ba71f73e8914ecd9e5b1e7bb864fee41158d04)
virtio_random: defer first enqueue until after DRIVER_OK
According to the virtio spec:
> The driver MUST NOT send any buffer available notifications to the
> device before setting DRIVER_OK.
DRIVER_OK isn't set until after attach completes, so defer the first
enqueue. We haven't found any problems as a result of this to the best
of my knowledge: q35 and other devices that we *have* been used with
will apparently check when we go DRIVER_OK.
Tested with q35 virtio-random, which still works.
Reported by: llm-postcr
Reviewed by: kfv, markj
Fixes: f1c5a2e3a62505 ("virtio_random: Pipeline fetching the data")
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
[2 lines not shown]
virtio_pci_modern: enable virtqueues before completing attach
Most of our drivers setup interrupt(s) and virtqueues are enabled at
that time, but nothing will currently enable them for devices that we're
only going to poll. This most notably affects virtio-random, and the
problem can be observed with qemu's q35 emulation and a random device
attached. The q35 implementation ignores the ring unless it's enabled,
so vtrnd_harvest() will consistently EAGAIN rather than contribute
anything of value, but with this patch it becomes functional.
This can be reproduced with a qemu invocation like so:
qemu-system-x86_64 -machine q35,accel=tcg -cpu max -smp 2 -m 2G \
-drive file=FreeBSD-16.0-CURRENT-amd64-ufs.qcow2,if=virtio \
-device pcie-root-port,id=rp1,bus=pcie.0,chassis=1 \
-object rng-random,id=rng0,filename=/dev/urandom \
-device virtio-rng-pci,rng=rng0,bus=rp1 \
-display curses
[5 lines not shown]
virtio_random: stop on detach, don't poll
If the device is hung, then polling will block the detach and hang us.
Stop it and drain the queue instead. This fixes a hang on detach in
some circumstances without the upcoming virtio_pci_modern fix.
Reviewed by: bnovkov, kfv
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
(cherry picked from commit cce522853aae3da45b131c2522dd2510edf083e7)
virtio_random: avoid using vtrnd_detach in the failure path
On the off chance that we discover more than one virtio-random device,
the second one will deregister the global instance or trip an invariant
when it fails to attach and calls vtrnd_detach().
We don't have that many resources to free, so just inline those. This
is purely a hygiene thing, we haven't seen an instance of this in the
wild (to my knowledge).
Reviewed by: bnovkov, kfv
Sponsored by: Stormshield
Sponsored by: Klara, Inc.
(cherry picked from commit 26ba71f73e8914ecd9e5b1e7bb864fee41158d04)
linux: Bound native getdents and getdents64 batches
linux_getdents() and linux_getdents64() round their native read size up
to DEV_BSIZE before converting entries. For an unaligned caller buffer,
the native batch can contain more entries than fit in the Linux buffer.
Conversion then returns EINVAL even after copying complete entries,
and the native read has already advanced the directory position.
For counts of at least DEV_BSIZE, use min(args->count, MAXBSIZE) instead.
A 768-byte request, such as rustix's initial directory read, now uses a
768-byte native buffer rather than 1024. The converted Linux dirent and
dirent64 records are no larger than their native counterparts, so the
whole translated batch fits. Returning a short batch is allowed, and
consuming the whole native batch avoids needing to rewind the directory
position.
Keep the existing sizing for counts below DEV_BSIZE. This fixes the
oversized-batch case in both getdents interfaces, including legacy
getdents for 32-bit and 64-bit callers. The remaining small-buffer,
[8 lines not shown]
cryptodev: zero key material before freeing it
The /dev/crypto cipher and MAC keys are copied from userland and
released with free(), leaving the key bytes in freed kernel memory.
Use zfree() so the key material is cleared on session teardown and on
the setup error path.
Reviewed by: markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D61324
