opencrypto - remove in-kernel crypto(9) framework
The opencrypto crypto(9) API was quite complex (8k LoC), slow and not
used by any other kernel subsystem within DragonFly anymore. It allowed
for chaining various operations, crypto ops and compression, but AFAIK
this was never really used and rather complicated. For a much simpler,
synchronous API see sys/src/crypto/cryptoapi. For a nice writeup on the
problems of crypto(9) in the context of FreeBSD, please see [1].
The opencrypto API was asynchronous by design. This was good back in the
days when dedicated hardware crypto devices did exist to help offload
the CPU. But the world has now changed towards synchronous CPU
instructions like AESNI. These dedicated CPU instructions are best
called synchronously, which removes the need for book-keeping of
asynchronous requests, often greatly simplifying the caller as well as
the API and "backend" implementation.
Furthermore, those dedicated crypto CPU instructions are not limited to
the kernel, they can be directly used by userland applications as well.
[15 lines not shown]
cryptodev: remove /dev/crypto pseudo-device
Remove the /dev/crypto pseudo-device. OpenBSD, which invented this API,
did this step back in release 5.7 (2015).
Note that this commit only removes the userland-facing /dev/crypto
device while still keeping the in-kernel crypto(9) API as-is. The plan
is to finally remove crypto(9) in a future commit.
The only applications within DragonFly that ever made use of /dev/crypto
were tcplay(8), cryptsetup(8) and cryptdisks(8) via libtcplay. But this
dependency on /dev/crypto was dropped in commit
ede102cd94449fe52fa9da25631d9f15af6d62ef as of April 21, 2025 in favor
of doing the crypto operations directly in userland without any help
from the kernel via /dev/crypto.
Userland libraries or applications like OpenSSH and OpenSSL do not use
/dev/crypto, mainly for performance reasons (and portability).
kernel - Do readonly check in .d_open method in mmcsd(4) and virtio_blk(4).
* Makes read-write open fail properly for read-only storage in mmcsd(4) and
virtio_blk(4), instead of only resulting in transfer errors for the
disk writes.
syscons - Add 16bit rendering code for UEFI and KMS driver framebuffers.
This fixes syscons rendering with KMS graphics drivers, when the driver
hands us a 16bit console framebuffer.
virtio_blk - Enable D_KVABIO API.
This should avoid some unnecessary page invalidations.
This driver already was compliant, since it never accesses any of the data
in the bio buffer.
hammer2 - disable FIOSEEKHOLE
* This function is returning incorrect results and needs more work.
Disable for now. Certain portions of the hammer2 btree may not yet
be synchronized even when the file buffers are synced. A SEEK_HOLE
operation just after a file is written but prior to the next full
filesystem may return incorrect data. And there are other issues with
the H2 implementation too.
So... just disable it for now.
* Fixes make configure; make sequences in dports where grep uses
SEEK_HOLE to try to locate any large holes in a file.
test: import more test cases to cryptapi_test
- Import test cases from test/testcases/crypto/* except for aesctr
which we do not have support for.
- Dedup fixtures. We are testing symmetric ciphers here, so there is
no need to keep duplicates of plaintext -> ciphertext and ciphertext
-> plaintext.
- Always test in both directions: Encrypt plaintext and decrypt
ciphertext.
- Store ct (ciphertext) in fixtures.csv.
test: Integrate benchmark into cryptoapi_test util
Print execution times and add "-n REPETITIONS" option.
Take the benchmark results with a grain of salt when comparing the
cryptoapi results against the cryptodev results, as we do not use
the AESNI CPU instruction when crytoapi is used outside the kernel.
While there, parse CLI options using getopt(3) and add a few more
test fixtures.
cryptoapi: inline functions and s/blocklen/blocksize/
- Inline a few functions which previously were macros
- Consistently use "blocksize" instead of "blocklen"
- Use uint8_t for alpha instead of int
- Use memset() in proximity of memcpy()
- Non-functional change
libusb: Implement v1.0 libusb_get_version() API
It seems our USB stack was synced from FreeBSD in 2016, so I inherit the
'nano = 2016' version info from FreeBSD.
This function is at least used by 'sysutils/nut' to fill the
'driver.version.usb' metadata in 'usbhid-ups' driver. The return value
doesn't matter at all.
Obtained-from: FreeBSD (commit 14b896ce80daad378a70a125ca15c2e23cd8d34b)
libusb: Implement v1.0 libusb_get_port_number() API
This function is also used by 'sysutils/nut' to scan the USB devices.
However, nut uses dlopen() to determine the presence of this API and
allows it to be absent.
Obtained-from: FreeBSD (commit 0f2c706643ff211ce1e1eb0cfbc3c05bc67f2311)
hammer2 - Enhance "show" (debugging feature)
Enhance the hammer2 show command to allow a chainspec to be specified
to dump a specific chain. The output will also print the xxhash64
value for the buffer.
vi(1): Tweak and clean up Makefile
- Group -D__REGEX_PRIVATE with -I${SRCDIR}/regex
- Update config.h to define USE_WIDECHAR, which aligns with the vendor
generated one.
