freebsd security - May 2015 - Atom C2758 - loading aesni(4) reduces performance

## Kevin Day (toasty at dragondata.com):
> > If you have cryptodev loaded, this is to be expected as OpenSSL will
> > use /dev/crypto instead of the AES-NI instructions..  Just don't
load
> > cryptodev and you'll be fine..
> 
> So to make sure I?m understanding? openssl has native AES-NI support, and
> it also can use /dev/crypto. It?s preferring /dev/crypto, but /dev/crypto
> has much higher overhead?
Yes (I hadn't thought of cryptodev, because "why would one load that
without really special crypto hardware?").
The overhead is obvious - when offloading the crypto operations to
the kernel, the benefit of the kernel/hardware crypto support has
to be better than the penalty of communicating with the kernel; and
as you already have AES-NI support in openssl, there's not that much
chance that the kernel is that much faster than openssl itself.

Regards,
Christoph

-- 
Spare Space

On Mon, 25 May 2015 13:41:31 +0200
Christoph Moench-Tegeder wrote:
> ## Kevin Day (toasty at dragondata.com):
> 
> > > If you have cryptodev loaded, this is to be expected as OpenSSL
> > > will use /dev/crypto instead of the AES-NI instructions..  Just
> > > don't load cryptodev and you'll be fine..
> > 
> > So to make sure I?m understanding? openssl has native AES-NI
> > support, and it also can use /dev/crypto. It?s
> > preferring /dev/crypto, but /dev/crypto has much higher overhead?
> 
> Yes (I hadn't thought of cryptodev, because "why would one load
that
> without really special crypto hardware?").
> The overhead is obvious - when offloading the crypto operations to
> the kernel, the benefit of the kernel/hardware crypto support has
> to be better than the penalty of communicating with the kernel; and
> as you already have AES-NI support in openssl, there's not that much
> chance that the kernel is that much faster than openssl itself.
But AFAIK you need the crypto module for AES-NI support in geli.

Is there any way to have both work optimally?