Re: [Ocf-linux-users] The development problem of developing an OCF driver, could you please give me
Brought to you by:
david-m
Menu
▾
▴
Re: [Ocf-linux-users] The development problem of developing an OCF driver, could you please give me some hint?
|
From: David M. <dav...@mc...> - 2011-07-26 12:48:12
|
Jivin Liu Hui lays it down ...
> Hi David,
>
> Thanks for the timely reply!
>
> I started with ocfnull, but I refer a lot of other drivers' code. So, maybe it is not a problem of ocfnull.
ok
> So, maybe another problem you mentioned is the root cause. Kernel wants my driver to do hash because I specified esp using des-sha1. So, des+sha1 is needed.
>
> But I don't understand the policy of OCF. If I just do DES in my driver, and will crytosoft handle sha1? In my understanding, if my driver doesn't register sha1 and cryptosoft register sha1 then the sha1 work will be done in cryptosoft. i.e. the crypto-combination request will be done in two drivers. Am I wrong?
If your "user" only asked for DES in its session that would be fine, but
openswan asks for DES+SHA1, which your driver cannot do, and cryptosoft
can no longer do.
So OCF does not split your session over multiple drivers for you. I know it
seems illogical, and to some extent I agree, but that is the way it is.
> And my hardware do support hash, I haven't implement it because I want to develop a simplest driver at first.
Ok, then just skip openswan and use cryptotest (from userspace) and
ocfbench.ko in kernel space to check you driver and throughput.
You can also use openssl and load/unload cryptosoft as needed to compare
output etc.
> And I have another question, in the same driver, the combination request(crypt+hash) are handled in one process or two? I took a lot into other drivers, it seems that the combination request can be handled in one process or two. For example, des-sha1, if you register des and sha1 separately, then the des-sha1 will be handled in two process. But you also can check the combination in the first process and handle them together. Am I right? These stuff confused me a lot.
Well they are handled within one "session". How the driver implements that
session is up to the driver. Most of the HW drivers do it in a sinle
operation. cryptosoft does it as 2 sepeerate actions. Depending on your
HW, you may do either. A single HW op is much better than 2 HW op's in
sequence if you can do it. Less copying and passes over the data,
Cheers,
Davidm
> 2011/7/26 David McCullough <dav...@mc...>
>
>
>
> Jivin Liu Hui lays it down ...
>
> > Hi David and all,
> >
> > I am developing an OCF-LINUX-DRIVER for one chip. I got some problems, could you please take a look in it?
> > I started with ocfnull driver template and only added CRYPTO_DES_CBC algorithm to the driver:
>
>
> ocfnull is probably not a good example to follow if you are doing a real HW
> driver. Be sure to look at some of the others as well once you get into it.
>
>
> > crypto_register(cp8_id, CRYPTO_DES_CBC, 0, 0);
> >
> > More alogrithm will be added after this simplest one works.
> >
> > In order to make cryptosoft driver not compete with my driver, I comment the CBC-DES in cryptosoft driver, like this:
> > // [CRYPTO_DES_CBC] = { cbc(des), SW_TYPE_BLKCIPHER, },
> >
> > And I also insmod my driver before cryptosoft.
> > In my opnion, if there are DES-CBC request, they will be sent to my driver.
> >
> > The ocf-linux dispatch work seem works. After I run 'service ipsec start', the newsessson routine in my driver was called, here is the dmesg print:
> > cp8_newsession()
> > cp8_newsession key:cri->cri_klen=64,(cri->cri_klen + 7)/8=8
> > 0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37
> > cp8_freesession()
> >
> > BUT, after I want to set up a connecton by 'ipsec auto --up net-to-net', error happended:
> > 003 ERROR: "net-to-net" #5: pfkey write() of K_SADB_ADD message 19 for Add SA esp.1e94ffe@172.22.14.5 failed. Errno 71: Protocol error
> >
> > The dmesg print show:
> > KLIPS klips_debug:ipsec_alg_enc_key_create: NULL ipsec_alg_enc object
> > KLIPS pfkey_add_parse: not successful for SA: (error), deleting
> >
> > It seems that openswan can't find an ipsec_alg_enc object to create a key.
> >
> > But if I use DES-CBC algorithm of cryptosoft driver, this error will disappear.
> > I can't understand why the key generation is related with ocf-driver because ocf-driver is not in charge of generate key.
> > And I can't see the different between my driver and cryptosoft driver, i.e. why cryptosoft driver works and mine failed?
> >
> > Could you please give me some hint?
>
>
> It is possibly because openswan wants to do a combination hash+crypto. I am
> not sure on this it seems likely given what you have tried. The other
> option may be that ocfnull cut corners that a real driver cannot.
>
> You have a couple of options, test your driver using "cryptotest"
> initially. That will get around the hash+cipher problems.
>
> Second, mod the ocfbench driver to test DES and do no hashing and try that
> for in kernel testing.
>
> Once you have all that and you think you are ready to roll we can look at
> where it should go next. Does your hardware support hashes ? If so then
> get that implemented next and you should be done. If not perhaps we can
> look at how ocf spreads requests across multiple drivers (ie., hashes on one
> driver and ciphers on another).
>
> Cheers,
> Davidm
>
> --
> David McCullough, dav...@mc..., Ph:+61 734352815
> McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
>
>
>
>
>
> --
> Thanks & Best Regards
> Liu Hui
> --
>
>
--
David McCullough, dav...@mc..., Ph:+61 734352815
McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org
|
