<br><div class="gmail_quote">On Wed, Oct 12, 2011 at 9:41 AM, David McCullough <span dir="ltr"><<a href="mailto:david_mccullough@mcafee.com">david_mccullough@mcafee.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
Jivin satpal parmar lays it down ...<br>
</div><div class="im">> Please find my response below.<br>
><br>
><br>
> -SP<br>
><br>
><br>
> On Wed, Oct 12, 2011 at 12:52 AM, Paul Wouters <<a href="mailto:paul@xelerance.com">paul@xelerance.com</a>> wrote:<br>
><br>
><br>
> On Tue, 11 Oct 2011, satpal parmar wrote:<br>
><br>
><br>
><br>
> 2. Ping is first thing I am doing after boot up. So no load on CPU of any kind. Ping works fine without<br>
> OCF (and cryptosoft, cryptodev) and H/W driver. In fact I am able to ping with OCF + cryptosoft (see<br>
> log below). Only when I enable H/W accelerator support ping is crashing. So one may conclude driver is<br>
> the culprit. But I am able to do standalone testing of H/W accelerators using drivers, cryptodev and<br>
> cryptotest as mentioned in wiki entry. So my doubt is if the interface for ipsec stack (NETKEY in my<br>
> case) is consistent with h/w driver I am using. I am not very confident of my understanding of ipsec<br>
> (netkey) + OCF + h/w driver intersection and interfaces.<br>
><br>
><br>
><br>
> Are you saying it works without cryptodev but not with cryptodev?<br>
> cryptodev is the /dev/crypto userland driver to accelerate userland<br>
> crypto, and has nothing to do with the OCF kernel accelerated crypto (kinda)<br>
><br>
><br>
> Ok. Let me explain how I see it. There can be four configuration for running IPsec on my setup:<br>
><br>
> a) No OCF. No cryptosoft, cryptodev patch. Just kernel + Netkey IPsec stack + Openswan<br>
> (Linux Openswan U2.6.33/K2.6.37(netkey) ). Ping works. I can see ESP packet using wireshark.<br>
<br>
<br>
</div>yes<br>
<div class="im"><br>
<br>
> b) Apply TI OCF patch + H/W driver patch + OCF crypto-tool patch (dated 20100325). Disable H/W drivers.<br>
> Ping works. So I conclude cryptosoft + Ipsec works. Hope this conclusion is right.<br>
<br>
<br>
</div>yes<br>
<div class="im"><br>
<br>
> c) Now enable H/W accelerator drivers but disable cryptosoft (logic being why use emulation whn i have h/w).<br>
> But ping crash.<br>
<br>
<br>
</div>Ok, you HW drivers are broken in my opinion.<br>
<div class="im"><br>
<br>
> d) Use both H/w acceleration + S/W emulation (cryptosoft). I am not sure what should be the behavior here.<br>
<br>
<br>
</div>My previous email should clear that up.<br>
<div class="im"><br>
<br>
> I understand /dev/crypto is userland interface. But I do not see any userland crypto requirement when I am running IPsec. But now I remember Pluto is userland and may need it. Not sure. Please confirm. What would be behavior if it do not find any cryptodev?<br>
<br>
<br>
</div>You do not need cryptodev, and it is not causing you any problems either<br>
way.<br>
<div><div></div><div class="h5"><br>
> 3. I am not sure if I correctly understand what you mean when you said I am using OCF or not. I think I<br>
> am using it correctly as mention in TI wiki entry. Here is snippet from my config file and log from<br>
> board<br>
><br>
> # OCF Configuration<br>
> #<br>
> CONFIG_OCF_OCF=m<br>
> # CONFIG_OCF_RANDOMHARVEST is not set<br>
> CONFIG_OCF_CRYPTODEV=m<br>
> CONFIG_OCF_CRYPTOSOFT=m<br>
><br>
><br>
><br>
> Note that if you need CONFIG_OCF_CRYPTODEV, the patch also patches other parts of the linux<br>
> tree. That is, you cannot just have the CONFIG_OCF_CRYPTODEV as a module.<br>
><br>
> I agree. We got patch from vendor for testing of H/W accelerators using OCF-linux and crypto-tools. And this testing was successful. Openswan was not in picture from vendor point of view. I am assuming it will have full OCF support. I will double check with them. Do Openswan expect anything specific from OCF. Anyway to confirm what I have?<br>
><br>
><br>
> a) When I am not using OCF and H/W accelerator which (s/w)crypto library is used by ipsec<br>
> for encryption ?<br>
><br>
><br>
><br>
> Two answers. for the kernel, either KLIPS (via cryptoapi or when not found via native crypto)<br>
> For the userland, openswan uses either NSS (no OCF support AFAIK) or native/openssl (with OCF<br>
> support).<br>
><br>
> So for IPsec running on linux kernel I need crypto (algorithm) support in both kernel and user space. Kernel space is provided by crptoapi which is already part of kernel (so no OCF required) and in userspace its provided by NSS. Here I have a query: Will Openswan crib I do not have right (or expected crypto support either in s/w or H/W) in kernel or userspace?<br>
><br>
><br>
> b) When we have support of both cryptosoft (software emulation of H/W accelerators) and<br>
> H/W accelerators (drivers ) how IPsec choose which one to use? Is it a good practice? Do we have any<br>
> reason to do that?<br>
><br>
><br>
><br>
> I believe the HW takes precedence, but I know in the past that was not always the case.<br>
> But when there is no klips, it has to go via cryptosoft to netkey to the hardware using native<br>
> acceleration, not OCF, if I'm not mistaken.<br>
><br>
> Ok. Lets see if David have nay input on this.<br>
><br>
><br>
> c) Do I need cryptosoft or cryptodev when I am using h/w acclerators? AFAIU I do not need cryptosoft<br>
> (why use s/w emulation when i have h/w !). But not sure about cryptodev if it is used by OCF to<br>
> provide interface to IPsec stack.<br>
><br>
><br>
><br>
> cryptosoft is used for accelerating kernel crypto (most important - many packets means much crypto)<br>
> cryptodev is used to accelerate userland crypto (IPsec IKE) which per tunnel requires a few crypto<br>
> operations per hour, so not *that* important. (in fact, having a good entropy device for DiffieHellman<br>
> is probably more important for speed then the HW acceleration for IKE in userland)<br>
><br>
><br>
> So I conclude I need cryptodev interface for proper working of Openswan.<br>
<br>
</div></div>No, cryptodev is optional, I would leave it out for now.<br>
<br>
The 2 options I think you have to choose from are:<br>
<br>
1. use netkey + HW drivers (no cryptodev, no OCF).<br>
<br>
From what I can see above this is causing a crash for you. I may be<br>
wrong here though as you might be using openswan+cryptoAPI<br>
(CONFIG_KLIPS_ALG=y, CONFIG_KLIPS_ENC_CRYPTOAPI=y)<br></blockquote><div><br></div><div><font class="Apple-style-span" color="#006600">No. For some reasons we decided to go with NETKEY. My kernel is KLIPS virgin hence no KLIPS related flags. I doubt 'No OCF' is a option for reasons you mention in your previous mail.</font> From Paul's response I understand <font class="Apple-style-span" color="#006600">Pluto may be using crptodev for user land crypto . But not confirmed.(Yessss it's very confusing!). </font> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
2. use klips + OCF + cryptosoft + HW drivers<br>
Not sure you have cosen this option yet, or of ot os what you are<br>
using. At least its an alternative that may work (given you<br>
cryptodev/cryptotest testing worked).</blockquote><div><font class="Apple-style-span" color="#006600">Not plans for KLIPS yet. Like to understand the root cause here as we all agree that my current setup should work as far as support from kernel , IPsec stack (netkey), OCF, native Crytoapi, HW/ driver goes.</font> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Cheers,<br>
Davidm<br>
<div><div></div><div class="h5"><br>
<br>
--<br>
David McCullough, <a href="mailto:david_mccullough@mcafee.com">david_mccullough@mcafee.com</a>, Ph:+61 734352815<br>
McAfee - SnapGear <a href="http://www.mcafee.com" target="_blank">http://www.mcafee.com</a> <a href="http://www.uCdot.org" target="_blank">http://www.uCdot.org</a><br>
</div></div></blockquote></div><br>