/dev/crypto not being used in 12-STABLE

Ian Lepore ian at freebsd.org
Sat Dec 8 00:04:57 UTC 2018

On Fri, 2018-12-07 at 18:38 -0500, Jung-uk Kim wrote:
> > So while OpenSSL now uses more of its own native C and assembly code
> > (e.g. for AES-NI support), and that's certainly faster than all the
> > overhead that cryptodev(4) brings with it (see jhb@'s post), I wonder:
>> > 1. What happens to people using crypto hardware accelerators, ex.
> > hifn(4), padlock(4), ubsec(4), and safe(4)?  How exactly would OpenSSL
> > utilise these H/W accelerators if the devcrypto engine is disabled?
> padlock has a dynamic engine, i.e., /usr/lib/engines/padlock.so.  I
> believe glxsb, hifn(4), safe(4), and ubsec(4) users are very rare
> nowadays.  If we have significant number of users and they show
> reasonable performance, then I will reconsider my decision.

What about non-x86 hardware? Most 32-bit ARM chips have crypto
accelleration hardware which is not implemenented as cpu instructions
(or accessible in any way from userland).

-- Ian

More information about the freebsd-stable mailing list