Phil Stracchino wrote:
> FWIW, memory says we tried using GnuTLS once. It turns out that for
> this purpose it is (or was) horribly broken. In fact, at the time, I
> seem to recall the mere presence of Red Hat's GnuTLS lib broke Bacula
> altogether.
Yeah. I've found it to be pretty broken in other ways - I'm STILL having
to rebuild the subversion client against openssl to get working support
for client certificates due to a gnutls bug, and I rebuild netatalk
against openssl to get dhx password hashes that aren't supported in gnutls.
It doesn't look like gnutls is any better than openssl in terms of
parallel encryption support anyway. The whole affair seems to be a
licensing kerfuffle rather than anything else.
>> It'd be lovely to be able to use the IPP libraries in Bacula (and many
>> other things) for parallel crypto and many other parallel tasks, as
>> they're excellent even without special hardware. Unfortunately they're
>> rather GPL-incompatible and are only "free" for non-commercial use.
>
> It would indeed be very nice to be able to use that kind of hardware
> crypto support without having to jump through licensing hoops.
You don't have to jump through any licensing hoops to use the hardware
crypto. Intel have submitted patches that've been accepted into OpenSSL
1.0 . For Via's C3/C7 PadLock hardware crypto, support has been around
for ages and is certainly in OpenSSL 0.9.8.
Run "openssl engine" for a list of built-in engines in your version of
OpenSSL. Dynamically loaded engines for rarer hardware crypto devices
and/or those that need special configuration are availible in
/usr/lib/ssl/engines/ .
Those licensing hoops would have to be jumped to use Intel's fast
parallel *software* crypto engine to do multi-core/multi-threaded
AES-CTR mode encryption.
Bacula should probably work with Intel's hardware crypto out of the box.
If it doesn't, most likely all that'd be required would be to call:
ENGINE_load_builtin_engines();
ENGINE_register_all_complete();
in init_crypto() , and:
ENGINE_cleanup();
when crypto is cleaned up. See "man 3 engine". In fact, as PadLock
support comes pre-loaded and Intel crypto probably will too, it may not
even be neccessary to call ENGINE_load_builtin_engines() at all, only
ENGINE_register_all_complete(). Asking openssl to load all engines will
let it use other less common hardware crypto systems like some of the
add-on hw crypto PCI cards, though, and it's cheap enough not to even be
detectable in something as long-lived as bacula-fd.
OpenSSL is smart enough to pick a hardware engine if one exists, and
fall back to software if there's no suitable engine for the task at
hand. IIRC that's all I had to do to patch PadLock support into OpenSSH
when I needed it for my thin clients at work.
It's a trivial change that would enable Bacula to use any builtin
hardware crypto engine supported by OpenSSL. Worth making, so that by
the time the new Intel hardware hits Bacula supports it?
--
Craig Ringer
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
