[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Design] some comments on Linux CryptoAPI - this "atomic" cipherbusiness

-----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/