kernel - Fix another netinet6 panic, change how ipv6 proxying works
ipv6 isn't naturally proxying subnets on other interface (not responding
to neighbor solicitations) when forwarding is turned on.
However, there are numerous other issues involved here so for now I
am pushing a hack so at least we are backwards-compatible.
* Add a new interface flag, IFF_ANNOUNCE, named "proxy" in ifconfig.
Add "proxy" and "-proxy" options to ifconfig.
* Most non-localhost interfaces will set this bit by default. The bit
can be turned off in ifconfig using -proxy when configuring the interface.
* Adjust nd6_nbr.c (neighbor solicitation code) to respond to
solicitations if (A) the route has RTF_ANNOUNCE set, or (B)
the interface the route is associated with (note: its parent bridge
if the interface is on a bridge) has the IFF_ANNOUNCE bit set.
[10 lines not shown]
kernel - Fix ip6_forward_rt global and related panic
* Make ip6_forward_rt per-cpu, which should fix a route caching panic
that can occur sometimes due to code assuming single-threaded
operation.
evdev: Translate KEY_102ND in evdev_scancode2key()
This is the extra key on AT 102/105-keys keyboards, located just on the
right of the Left Shift key. For instance on a French layout, this key
is used to type '<' and '>'.
This fixes an issue where the key fires no evdev event and thus remains
inactive in an evdev/libinput-enabled X.Org server. The issue only
occurred on an AT keyboard; the same key on a USB keyboard worked fine.
Reported-by: daftaupe
Tested-by: daftaupe, Kentish
Obtained-from: FreeBSD (https://reviews.freebsd.org/D12883)
nrelease: Check GITREV and just fail if empty
The GITREV variable is determined by the tools/gitrev.sh script, which
might fail if the current user has insufficient permission to access the
source directory. That would cause the `uname` to output something
strange that could confuse people. So I think it's better to just fail
the build and require a fix to the build environment.
Reported-by: JustinS
nrelease: Check GITREV and just fail if empty
The GITREV variable is determined by the tools/gitrev.sh script, which
might fail if the current user has insufficient permission to access the
source directory. That would cause the `uname` to output something
strange that could confuse people. So I think it's better to just fail
the build and require a fix to the build environment.
Reported-by: JustinS
nrelease: Fix build due to 'pkg autoremove' removing itself
Since 2025Q1, if the 'ports-mgmt/pkg' package is installed as a
dependency of another package, it will be marked as 'automatic'
and will be removed by a later 'pkg autoremove', which would cause
the nrelease build to fail. Therefore, explicitly install it to
fix the issue.
Reported-by: tuxillo
Discussed-with: bapt
nrelease: Allow /etc/ssl/cert.pem be missing
The 'pkg-bootstrap' target in '/usr/Makefile' has been updated to work
without '/etc/ssl/cert.pem', so ignore copy failure of this file.
nrelease: Improve 'etc.hdd' creation to eliminate inconsistency
Previously, the 'etc.hdd' was created during the 'buildiso' target and
then updated in the 'pkgs' target. However, in the 'pkgs' target, only
the password files (i.e., master.passwd, passwd, group) were copied but
the password DBs (i.e., pwd.db, spwd.db) were not rebuild. This caused
an inconsistency in 'etc.hdd'. When a user tried manual installation
and forgot to run 'pwd_mkdb', the installed system would fail to add new
users and generate errors like:
> pw: user 'myuser' disappeared during update.
> adduser: ERROR: There was an error adding user (myuser).
This commit improves the creation of 'etc.hdd'. Reorder the 'customiso'
target *after* the 'pkgs' target, so we can simply copy the 'etc' to
'etc.hdd' and be done, without any further changes, and the resulting
password files and DBs are in consistency. In addition, this avoids
adding the 'installer' user to the 'etc.hdd' and so we get a cleaner
system by default.
[3 lines not shown]
sys/vfs/hammer2: Zero clear z_stream
Zero clear z_stream local variables as seen in other subsystems
that use zlib. sys/vfs/hammer2/zlib doesn't seem to differ either.
Having non-zero garbage in unused pointer members causes panic in
deflateEnd() / inflateEnd(). These functions actually panic in
FreeBSD when set to zlib or makefs'd with zlib.
tcplay/libtcplay - Reenable use of cryptoapi
Successfully tested with the following ciphers / chained cipher
combinations (created using Veracrypt on Windows):
* AES-256-XTS
* SERPENT-256-XTS
* TWOFISH-256-XTS
* TWOFISH-256-XTS,AES-256-XTS
* SERPENT-256-XTS,TWOFISH-256-XTS,AES-256-XTS
Also tested with cryptdisks(8), which uses libtcplay.
cryptoapi - constify IV and pass-in IV length as well
* This only affects XTS mode as CBC never mutated the IV.
* Never pass-in data of unknown length.
* In case of XTS, add a tweak to the contex, similar to what
FreeBSD does.
* Get rid of crypto_cipher_iv union type. simplify.
* Also ensure that, in case we pass in a "too short" IV,
we never read beyond the end of the passed-in IV. Zero-pad
it in that case.
cryptoapi - simplify session handling
* Make cryptoapi_cipher_session an opaque type.
* Rename cryptoapi_cipher_initsession() to
cryptoapi_cipher_newsession() and return a pointer to the allocated
session, or NULL in case kmalloc() fails.
* Allocate enough memory in order to have space for the cipher context
plus padding for proper alignment.
* No longer return an error from cryptoapi_cipher_freesession().
Silently do the job.
wg: Improve wg_peer_create() to propagate errors
Add the 'int *errp' parameter to wg_peer_create() to propagate the error
from noise_remote_enable() to wg_ioctl_set().
Originally, wg_ioctl_set() returned ENOMEM if wg_peer_create() failed,
but it should actually be ENOSPC because it could only fail because of
noise_remote_enable() that only returns ENOSPC.
See also: https://reviews.freebsd.org/D49796
libtcplay - reenable the cryptodev code for now
The new cryptoapi code needs more thorough testing!
I've run into some issues detecting AES-256-XTS tcplay devices. While I
have working code now that detects AES-256-XTS devices, I do not fully
understand the exact reason - compiler optimizations?
libtcplay: Include rijndael-alg-fst.c to fix the static library
The static library (libtcplay.a) is used by sbin/cryptdisks, which is
built as a static binary. The missing source of 'rijndael-alg-fst.c' caused
sbin/cryptdisks to fail the linking with the following error:
/usr/obj/srv/jenkins/workspace/DragonFlyBSD/ctools_x86_64_x86_64/usr/libexec/binutils234/elf/ld.bfd: /usr/obj/srv/jenkins/workspace/DragonFlyBSD/world_x86_64/usr/lib/libtcplay.a(rijndael-api.o): in function `rijndael_set_key':
rijndael-api.c:(.text+0x12): undefined reference to `rijndaelKeySetupEnc'
/usr/obj/srv/jenkins/workspace/DragonFlyBSD/ctools_x86_64_x86_64/usr/libexec/binutils234/elf/ld.bfd: rijndael-api.c:(.text+0x27): undefined reference to `rijndaelKeySetupDec'
/usr/obj/srv/jenkins/workspace/DragonFlyBSD/ctools_x86_64_x86_64/usr/libexec/binutils234/elf/ld.bfd: /usr/obj/srv/jenkins/workspace/DragonFlyBSD/world_x86_64/usr/lib/libtcplay.a(rijndael-api.o): in function `rijndael_decrypt':
rijndael-api.c:(.text+0x48): undefined reference to `rijndaelDecrypt'
/usr/obj/srv/jenkins/workspace/DragonFlyBSD/ctools_x86_64_x86_64/usr/libexec/binutils234/elf/ld.bfd: /usr/obj/srv/jenkins/workspace/DragonFlyBSD/world_x86_64/usr/lib/libtcplay.a(rijndael-api.o): in function `rijndael_encrypt':
rijndael-api.c:(.text+0x66): undefined reference to `rijndaelEncrypt'
collect2: error: ld returned 1 exit status
Add 'rijndael-alg-fst.c' to SRCS to fix it. Actually, this source is
also listed in sys/crypto/Makefile for rijndael.
