-----BEGIN PGP SIGNED MESSAGE-----
{my appologies if I already sent this}
>>>>> "Martin" == Martin Gadbois <martin.gadbois@colubris.com> writes:
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?
Martin> This is a drop-in replacement for existing applications that uses
Martin> functions like des_ede3_cbc_encrypt(). Those application will benefits
Martin> immedialtly from hardware acceleration.
For applications that still have to have a function calling sequence for
crypto, hash and compression operations, then the high-level cryptoAPI
functions should be appropriate.
My plan here is to:
1) bring up loop-cryptoAPI under UML, add this to our regression tests.
(Yes, FreeSWAN will test loopback file system crypto every night)
2) add the necessary 'setup' functions to cryptoAPI to ask for names
of functions properly.
3) have KLIPS initially call the high-level CryptoAPI functions
4) introduce the low-level functions, with KLIPS as the test
application, always running the loopback file system crypto tests.
5) get some hardware + drivers and beat them into submission.
Martin> hardware (or
Martin> | Martin> software) to execute the request, according to specified
Martin> | Martin> limitations.
Martin> |
Martin> | Sure, but users have to have a way to override things.
Martin> Ok. "aes-cbc/hardware" would do that.
That's my idea.
Martin> | My feeling is that one opens the "esp/3DES/HMAC-MD5" cipher if one
Martin> wants it
Martin> | done in one operation and ESP knows this stuff.
Martin> Isn't that complicating the "Naming of ciphers"?
Yes, it needs to be named "esp/3DES-hmac-md5 or some such. There are
combinatorial issues here. Suggestions?
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.
Martin> list of transform (algorithm, offset, len) to do on the request. I
Martin> though that is what you meant with the tc_cmdqueue member.
tc_cmdqueue is the prev/next pointers for the queue on which this work item
sits. The calling application can queue many packets towards the crypto
system.
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.
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.
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"
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
Martin> VPN keys
Martin> | stay in the hardware, while RW or OE get LRU). I would think that perhaps
Martin> | this stuff goes into to initialization code for creating the
Martin> cipher_context
Martin> | ("open_session" as you call it).
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.
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?
] Internet Security. Have encryption, will travel |1 Fish/2 Fish [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |Red F./Blow F [
]mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto [
] At the far end of some dark fiber - wait that's dirt! |for everyone [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys
iQCVAwUBPUAdp4qHRg3pndX9AQHtCwQAijm4sKA/OTtW/OZhXnZltOuBNurN/A/D
/0RXd66Inr7omLUqN9x1DhZc7mGoWMQW5p9aP9j5IMz/vOnWYYPIDNqMMZfIoqEO
uMQBbDAiYHukbPtkxAig3Y0P1xZX1kbqMaz/+0lsl7apGhFOyBLbrKclrYiVNg2/
x/eh2AidzHY=
=Bg3X
-----END PGP SIGNATURE-----
-
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
