https://cgit.freebsd.org/src/commit/sys/crypto/aesni?h=stable/12&id=95b37a4ed741fd116809d0f2cb295c4e9977f5b6 may have subtly broken a number of IPsec installations by stalling active connections after certain amounts of traffic transferred. We're still trying to confirm, but it looks like this had an overall impact on 12.0 and 12.1 except that only one person in OPNsense traced it back to aesni.ko to our knowledge to effective work around an apparent issue there. If that is not the actual fix, the problem still exists in 12.2 and onward ;) https://github.com/opnsense/core/issues/4415 To answer the question: I guess so, yes, enable for all to have proper errata and increased "test" coverage... Cheers, Franco > On 31. Dec 2020, at 9:07 PM, Shawn Webb <shawn.webb_at_hardenedbsd.org> wrote: > > On Thu, Dec 31, 2020 at 02:51:06PM -0500, Allan Jude wrote: >> We've had the AESNI module for quite a few years now, and it has not >> caused any problems. >> >> I am wondering if there are any objections to including it in GENERIC, >> so that users get the benefit without having to have the "tribal >> knowledge" that 'to accelerate kernel crypto (GELI, ZFS, IPSEC, etc), >> you need to load aesni.ko' >> >> Userspace crypto that uses openssl or similar libraries is already >> taking advantage of these CPU instructions if they are available, by >> excluding this feature from GENERIC we are just causing the "out of the >> box" experience to by very very slow for crypto. >> >> For example, writing 1MB blocks to a GELI encrypted swap-backed md(4) >> device: >> >> with 8 jobs on a 10 core Intel Xeon CPU E5-2630 v4 _at_ 2.20GHz >> >> fio --filename=/dev/md0.eli --device=1 --name=geli --rw=write --bs=1m >> --numjobs=8 --iodepth=16 --end_fsync=1 --ioengine=pvsync >> --group_reporting --fallocate=none --runtime=60 --time_based >> >> >> stock: >> write: IOPS=530, BW=530MiB/s (556MB/s) (31.1GiB/60012msec) >> >> with aesni.ko loaded: >> write: IOPS=2824, BW=2825MiB/s (2962MB/s) (166GiB/60002msec) >> >> >> Does anyone have a compelling reason to deny our users the 5x speedup? > > Note: HardenedBSD has had AESNI enabled on amd64 for nearly six years. > Not a single complaint. > > For reference, HardenedBSD commit: > a5aabd1c8dcc2a5097de56c54ec2a1c8d9352896 > > Thanks, > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > GPG Key ID: 0xFF2E67A277F8E1FA > GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 > https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.ascReceived on Thu Dec 31 2020 - 19:15:14 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:26 UTC