VIA Eden Padlock Encryption Accelerator/RNG support

Voami

I know I am not alone in having pfsense running on VIA Edens with on-chip AES acceleration and a suitably entropic RNG (per http://www.cryptography.com/resources/whitepapers/VIA_rngsum.pdf).

It looks like support for this functionality is in freebsd 6.2: http://www.freebsd.org/relnotes/6-STABLE/relnotes/i386/new.html

What kind of expectations should we have about this hitting pfsense?

gbelanger

I may be wrong but I was under the impression that pfSense supports the Padlock encryption acceleration through the crypto() and random() functions when using the padlock module. This has been included since FreeBSD 6.0.

The FreeBSD padlock module should support the VIA ACE (Advanced Crypto Engine) and the VIA RND. Note that apparently not all Via C3 Nemeniah have the ACE built-in, as you can see from this output of dmesg | grep CPU:

CPU: VIA C3 Nehemiah+RNG (1002.28-MHz 686-class CPU)

And loading the padlock module (kldload padlock.ko) gives me this error:
PADLOCK: No ACE support.
But still loads the module.

I'm now also running C7's, on which the padlock module has been improved. See differences here:
http://www.via.com.tw/en/products/processors/c7/

It would definately be interesting to have a better idea of how this is all implemented, I'd love to enable/disable it and compare benchmarks.

The padlock module seems to be loaded only by the vpn_ipsec_configure() function from /etc/inc/vpn.inc, and only if the ACE engine is present, so I'm not sure how much it really is supported.

It also seems that the OpenSSL included in pfSense is padlock-ready. Try this command:
openssl engine padlock

If the feedback says (padlock) VIA PadLock (RNG, ACE), you are in business. If not (in my case no-RNG, no-ACE) then its possible that your processor doesnt have the padlock engine or that its not yet recognized (like my C7's).

Here is a reference article (targeted at Linux, but very informative):
http://www.linuxjournal.com/article/8042

-G

gbelanger

Regarding the C7, turns out the padlock.ko module that comes with FreeBSD does not work properly (because of a small bug). So I re-compiled the module with the correction and my Via C7 now shows this:

openssl engine padlock

(padlock) Via PadLock (no-RNG, ACE)

Ideally it would see the random number generators, but at least it now recognizes the Advanced Crypto Engine (ACE).

Testing with:

openssl speed -evp aes-256-ecp -engine cryptodev

Gives me 11 000 KBybes/second for the 8k blocks (those more likely to be sped up by the hardware engine)

but

openssl speed -evp aes-256-ecp -engine padlock

1 629 211 KBytes/second!!! Well over one gigabyte of throughput. (Actually 13 GBits second)

However, since the C7 CPU is still not recognized, the VPN.inc file would not load the padlock module when starting up (It looks for the ACE string). Also, loading the padlock.ko module does not speed up the cryptodev subsystem, and running openssl with the padlock engine gives the same results with or without the loaded module, so its probably accessing it directly.

Which brings me to the conclusion that while this is close to working, I'm not sure this is actually doing what it should be doing at present. I would love to see this baby run with all the acceleration of the ACE.

It just blows me away that the Crypto-accelerated results are almost 120 times faster (60 times with the more common cbc algorithms). That means no more VPN bottlenecks. Very cool.

Hopefully, someone smarter than me will help make this work?

-G

hoba

That are some promising results. I have 2 via C3 nehemias 1GHz at home. I can setup these as testsystems for a dev with remote access if somebody is interested.

sullrich

FreeBSD bug… Tis' the reason it's not enabled. MAYBE FreeBSD 6.2 will be better but I am fighting 4 different panics and they are about to release a RC which in my opinion is a bad move.

Either way 6.2 is going to be some work before it will be ready for us and I have no doubt we won't be able to release at the same time. May take an additional month+.

Bottom line, it's on our list to be handled at some point.

gbelanger

Regarding this, just some precisions I would like (if you have time, Scott):

What do the FreeBSD bug(s) refer to? Recognizing the RNG/ACE on the CPU or actually using it?
Is this a major bug or something that can be worked out? Would it be worth it so start a bounty, for example?

I would participate in a bounty if you think it's doable. If its purely dependent on the FreeBSD core, then we'll just have to wait it out…

Thanks-

Guillaume