/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