Date: Fri, 07 Dec 2018 17:04:49 -0700 From: Ian Lepore <ian@freebsd.org> To: Jung-uk Kim <jkim@FreeBSD.org>, Jeremy Chadwick <jdc@koitsu.org>, freebsd-stable@freebsd.org Subject: Re: /dev/crypto not being used in 12-STABLE Message-ID: <1544227489.1860.321.camel@freebsd.org> In-Reply-To: <995cddb8-f4ce-b9c9-aa8f-5e7cd5c465e2@FreeBSD.org> References: <20181207020124.GA87799@icarus.home.lan> <995cddb8-f4ce-b9c9-aa8f-5e7cd5c465e2@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1544227489.1860.321.camel>