-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Richardson wrote:
| Martin> If, like FreeS/WAN now, you want to replace crypto operations to use
| Martin> hardware but FreeS/WAN cannot wait while the hardware encrypts the
| Martin> packet, what do you do? What I did first is I replaced
| Martin> des_ede3_cbc_encrypt() with the one that does hardware, and wait for it
| Martin> to complete. YOu win, because time(HW) < time(SW).
|
| Yes, but is it clear that we want to fix it so that FreeSWAN does not
| require this?
Yes, yes... I'm talking general use.
| Yes, it needs to be named "esp/3DES-hmac-md5 or some such. There are
| combinatorial issues here. Suggestions?
You either need to be explicit (like I do in H/W accel. patch) or implicit. Explicit is no problems,
as the user specifies the series of operation to do on packet.
For implicit, you might need a general action: "encrypt", "decrypt", "mac", "hmac", "esp".
This action would be followed by the algorithm(s) to use, then the provider type ("hardware"/"software")
Example: "esp/3DES-MD5/hardware", "encrypt/aes-cbc-128"
The problem with strings is parsing it... you might be better off with a stricter approach (several
strings, or a struct)
|
| Martin> In the FreeS/WAN hardware acceleration patch
| Martin> (http://sources.colubris.comg) I use a structure for the request, and a
|
| I should review your patches again.
Look at the header file if_crypto.h.
|
| I thought hard about whether to have a per-command callback, or a
| per-cipher_context callback. I know that each packet will need per-packet
| info. The callback is likely to be called from the hardware interrupt
| context, although in the case of software crypto with no SMP, there will be
| no context switches at all.
|
| In many cases, I would expect the callback to simply enqueue the packet
| onto a queue back to the caller, i.e. KLIPS.
Why queue "back to the caller"? When crypto opreration is done, let's send the packet right away! I
always see a packet like a hot potato: it needs to get off my hands ASAP!
|
| There are some accounting issues:
| 1) should software crypto be done in the net_bh context?
| For SMP, one could simply permit the multi-threading of the
| network bottom half to take care of moving the crypto to multiple
| processors.
That is what is done in FreeSWAN right now, no? I see no need to change that, unless you want to
increase latency!! :-)
|
| 2) instead, we could create a "crypto bottom half" to do software
| crypto. I would actually like this to show up as a kernel thread
| in the process table - this lets people know precisely how much
| CPU is used by crypto. Spawn one per CPU.
|
| This works well for SMP, but on UPs it seems wasteful to pay the
| context switching overhead. Do we do anything when running an SMP
| kernel on a UP? I don't think so.
|
| Hardware is then just another thread that happens to have a
| dedicated "processor"
The same logic applies for a dedicated H/W processor if you need a context switch to a kernel thread
to process a packet. You don't need the context switch latency to be added to the packet's.
|
| 3) there will have to be a KLIPS thread to "receive" the encrypted
| packets. Should this interact with the network bottom half
| somehow? Note that packets that
I would suggest NOT to use kernel threads at all. Do everything in tasklet or bottom handler.
| Martin> Possibly, but in any case, software need to oversee the hardware key
| Martin> management.
|
| Are we agreed that this goes into the open_xform_context() and that this
| portion will need to work, probably some revision after the first try.
As long as we plan for it from now on...
|
| Martin> The FreeS/WAN acceleration patch does not use H/W keys, as our
| Martin> application does not have extra memory to store keys.
|
| I don't quite understand that.
| You that your hardware doesn't have the keys? You prefix them inline to
| each packet then?
Right.
The reason is that my board does not have separate memory to hold keys in. So with every packet, I
attach a pointer to the key. That key is passed to the H/W with each packet.
Some other H/W chip uses DMA and the main host memory to get the key. Others keep the keys in their
own "safe" memory, to be FIPS compliant.
- --
==============
Martin Gadbois
S/W Developper
Colubris Networks Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAj1AXogACgkQ9Y3/iTTCEDnCbACfetNiofB/7eI21RdAWuqBDGv1
VMQAnAyyRbEd1F/8suh7vX3dXhJ2syjH
=H1o9
-----END PGP SIGNATURE-----
-
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
