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: Liu H. <onl...@gm...> - 2011-07-26 13:35:27
|
David,
It is very clear~~
Much appreciated!
Hui
2011/7/26 David McCullough <dav...@mc...>
>
> 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
>
--
Thanks & Best Regards
Liu Hui
--
|
