[Design] Making KLIPS 1 asynchronous to support H/W crypto

Hello,

in the search for the elusive hardware encryption for FreeS/WAN I have been trying to redo the Colubris hardware encryption patch for FreeS/WAN 1.91 with FreeS/WAN 2.00(-rc1).

I decided to try and do it `the right way'. This involved basically making KLIPS 1 support asynchronous encryption operations, and then making the minimal changes necessary to offload the actual encryption to Martin Gadbois' cryptolib.

The idea of making KLIPS 1 support asynchronous encryption is that of breaking up loops and basic blocks in which encryption can take place and allow re-entry from a callback.

This is accomplished by keeping the decrypting function's state not on the stack but on the heap and passing pointers to it around.

Fortunately, for ipsec_rcv in linux/net/ipsec/ipsec_rcv.c this is already partially done by encapsulating almost all necessary state in an ipsec_rcv_state struct. All that needs to be done is break the function at the correct place so that a callback can re-enter the decryption from an interrupt handler for a crypto-board and allocate the ipsec_rcv_state struct on the heap.

Note that it isn't quite as easy, as the code *does* take locks, and these need to be released at appropriate times.

For ipsec_start_xmit the situation is not that easy. It has not been refactored yet.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

The ipsec_start_xmit code is one huge function of some 1600 lines. The first 343 lines of these, up to the comment /* start encapsulation loop here XXX */ are not directly involved with encrypting. The next 1094 lines *are*. The last 132 lines are involved with actually sending the packet and cleaning up.

Now, the 1094 lines that are directly involved with encrypting form 1 single loop. In this loop there is code that sets up the encryption steps and a loop that then does the actual encryption.

This loop ought to be split off, so that entry into the loop can be done asynchronously. This means that every loop nesting level from the outer loop down to the actual encryption call needs to be factored out into a seperate function. The trouble is in a few issues:

• what state does the loop keep, and what state should therefore be carried over the asynchronous call?
• what locks does the loop hold and what locks can and can not be released over the asynchronous call?

Accompanied are my patch to FreeS/WAN 2.00-rc1 (afaik it should also patch cleanly to 2.00-rc2, but I haven't tested that), and my version of the cryptolib that applies cleanly to a RedHat 2.4.18-24 kernel. (Took me a bit to figure out: Martin's cryptolib actually also supports synchronous encryption, so I first tried that, but most hardware doesn't, so it didn't actually work :), and KLIPS 1 is *monstrous* to say the very least. I think I can pinpoint at least 1 bug just by reading the code... I still need to verify that though.)

Now, what I want to know: am I completely off the rocker on my assessment? Is this approach reasonable? Are there obvious pitfalls? I am concerned about possible information leaks due to for instance releasing the tdb_lock when asynchronously encrypting a transmit request: the ipsec_sa table may get modified in the meantime. Fortunately releasing the lock when encrypting upon receive seems to merely result in a spurious drop, and I don't feel the need to deal with those, higher level protocols as TCP can do that. IP doesn't guarantee reception of data anyway.

Comments?

Doei, Arthur.

-- 
+- Arthur van Leeuwen, Systems Consultant, arthurvl@xos.nl -+
|  X/OS Experts in Open Systems BV                          |
|  Kruislaan 419                     Phone: +31 20 6938364  |
|  1098 VA  Amsterdam                Fax:   +31 20 6948204  |

_______________________________________________ Design mailing list Design@lists.freeswan.org http://lists.freeswan.org/mailman/listinfo/design

Do you need more help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek