Re: [Ocf-linux-users] The development problem of developing an OCF driver, could you please give me some hint?

[Liu H. <onl...@gm...>]

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.

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?

And my hardware do support hash, I haven't implement it because I want to
develop a simplest driver at first.

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.

Thanks for your time.

Much appreciated!
Hui

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