3 ms·

The Kirkwood AES accelerator (mv_cesa) is not exposed to userspace in Linux. It won't accelerate your SSL. You can use it to accelerate dm-crypt, though. I owne

by Wicher 13y ago

The Kirkwood AES accelerator (mv_cesa) is not exposed to userspace in Linux. It won't accelerate your SSL. You can use it to accelerate dm-crypt, though. I owned a Sheevaplug and own a Dreamplug. They're not nearly as fast as even a 2009 Atom... But power-efficient, yes.

rdl 13y ago
Is that just a driver limitation, or is there a problem with the hardware so the driver is written that way? It also doesn't do DMA, so I've heard bad things about performance with it for small packets.
- Wicher 13y ago
  If I remember correctly it's a driver limitation, and theoretically it could be modified so it would do what you want, but consider the amount of userspace/kernelspace crossings to be made just to send some ciphertext over the network to some other party. I imagine something like this would take place: SSL does not happen in the kernel. So you need to send a payload to the kernel to encrypt, you get back the ciphertext, wrap it in your packet (add some headers) and then push this data once more to the kernel, which sends it out over the network for you. Receiving ciphertext would go along similar lines. That's probably not very efficient. Contrast this with full disk encryption using dm_crypt (linux). No shuffling back and forth of data. Userspace only really needs to handle the plaintext (and not even directly, but through the FS layer, which is also in the kernel). So maybe it may just not be worthwile to expose the interface to userspace on reasonably powerful platforms? Anything above a tiny MIPS or old 486? The VIA padlock crypto accelerator is (or was at some point) exposed to userspace and OpenSSL could take advantage of it. I wonder how much of a performance increase that yielded, considering the issue I noted above. Also, hardware accelerators typically only support a couple of modes and key sizes. That's fine for full disk encryption, but in a networked world you need more flexibility.
  - bifrost 13y ago
    > I wonder how much of a performance increase that yielded It yielded 100Mbps+ SCP's with zero system CPU usage, very very handy. I've used a few older SSL accelerators and they were good for about 1Gbps or so. IMHO AES-NI makes these things obsolete, and with that going into the new Intel Atom cores, I think thats likely going to drop a lot of the competition out.
    - rdl 13y ago
      Ah, yes, the Silvermont series should be amazing. It looks like it might have virtualization extensions, too. I can't tell when it's supposed to come out, though. Should rock for NASes too. Right now only certain i3/i5 NAS seem to do AES acceleration, so the cheapest are around $2k bare from QNAP or $999 from iXSystems.
    - deleted 13y ago
      [deleted]

by Wicher 13y ago

rdl 13y ago

Is that just a driver limitation, or is there a problem with the hardware so the driver is written that way? It also doesn't do DMA, so I've heard bad things about performance with it for small packets.

Wicher 13y ago
If I remember correctly it's a driver limitation, and theoretically it could be modified so it would do what you want, but consider the amount of userspace/kernelspace crossings to be made just to send some ciphertext over the network to some other party. I imagine something like this would take place: SSL does not happen in the kernel. So you need to send a payload to the kernel to encrypt, you get back the ciphertext, wrap it in your packet (add some headers) and then push this data once more to the kernel, which sends it out over the network for you. Receiving ciphertext would go along similar lines. That's probably not very efficient. Contrast this with full disk encryption using dm_crypt (linux). No shuffling back and forth of data. Userspace only really needs to handle the plaintext (and not even directly, but through the FS layer, which is also in the kernel). So maybe it may just not be worthwile to expose the interface to userspace on reasonably powerful platforms? Anything above a tiny MIPS or old 486? The VIA padlock crypto accelerator is (or was at some point) exposed to userspace and OpenSSL could take advantage of it. I wonder how much of a performance increase that yielded, considering the issue I noted above. Also, hardware accelerators typically only support a couple of modes and key sizes. That's fine for full disk encryption, but in a networked world you need more flexibility.
- bifrost 13y ago
  > I wonder how much of a performance increase that yielded It yielded 100Mbps+ SCP's with zero system CPU usage, very very handy. I've used a few older SSL accelerators and they were good for about 1Gbps or so. IMHO AES-NI makes these things obsolete, and with that going into the new Intel Atom cores, I think thats likely going to drop a lot of the competition out.
  - rdl 13y ago
    Ah, yes, the Silvermont series should be amazing. It looks like it might have virtualization extensions, too. I can't tell when it's supposed to come out, though. Should rock for NASes too. Right now only certain i3/i5 NAS seem to do AES acceleration, so the cheapest are around $2k bare from QNAP or $999 from iXSystems.
  - deleted 13y ago
    [deleted]