ocf-linux-users — Anything and everything ocf-linux related

Re: [Ocf-linux-users] [Openswan Users] IPSec L2tpv3 throughput low using Netkey kernel stack

[David M. <dav...@mc...>]

Jivin Paul Wouters lays it down ...
> On Tue, 17 May 2011, Kim Phillips wrote:
> 
> >>> but when the Sec driver is configured as module into the kernel the module doesn;t get inserted
> >>> gives segmentation fault and if the Sec driver is configured as non-module type the kernel doesn't
> >>> bootsup at all!
> >>
> >> David might be able to help with this. The ubsec driver is mostly used on linksys/asus machines,
> >> perhaps yours is slightly different?
> >
> > Based on the freescale URL posted to users@openswan, I assume you're
> > referring to the "SEC23DRVRS" driver?  That is a standalone driver,
> > and won't be of use unless you're prepared to write code to
> > integrate it into your IPsec stack.
> >
> > Known working (to me at least) IPsec offload configuration for the
> > 8315 should be NETKEY with CONFIG_CRYPTO_DEV_TALITOS configured in
> > a vanilla kernel.  To be able to tell whether h/w crypto offload is
> > in operation, see 'grep talitos /proc/interrupts' run.
> 
> Ah, i thought he meant the ubsec one. Talitos I believe is also supported with OCF and KLIPS
> IPsec, but I'm sure David can confirm that.

Yeah, Kim wrote the driver,  but the in kernel one is more up to date ;-)

Cheers,
Davidm

-- 
David McCullough,      dav...@mc...,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org

Re: [Ocf-linux-users] [Openswan Users] IPSec L2tpv3 throughput low using Netkey kernel stack

[Paul W. <pa...@xe...>]

On Tue, 17 May 2011, Kim Phillips wrote:

>>> but when the Sec driver is configured as module into the kernel the module doesn;t get inserted
>>> gives segmentation fault and if the Sec driver is configured as non-module type the kernel doesn't
>>> bootsup at all!
>>
>> David might be able to help with this. The ubsec driver is mostly used on linksys/asus machines,
>> perhaps yours is slightly different?
>
> Based on the freescale URL posted to users@openswan, I assume you're
> referring to the "SEC23DRVRS" driver?  That is a standalone driver,
> and won't be of use unless you're prepared to write code to
> integrate it into your IPsec stack.
>
> Known working (to me at least) IPsec offload configuration for the
> 8315 should be NETKEY with CONFIG_CRYPTO_DEV_TALITOS configured in
> a vanilla kernel.  To be able to tell whether h/w crypto offload is
> in operation, see 'grep talitos /proc/interrupts' run.

Ah, i thought he meant the ubsec one. Talitos I believe is also supported with OCF and KLIPS
IPsec, but I'm sure David can confirm that.

Paul

Re: [Ocf-linux-users] [Openswan Users] IPSec L2tpv3 throughput low using Netkey kernel stack

[Kim P. <kim...@fr...>]

On Tue, 17 May 2011 14:27:59 -0400
Paul Wouters <pa...@xe...> wrote:

> On Mon, 16 May 2011, Vasanth Ragavendran wrote:
> 
> > but when the Sec driver is configured as module into the kernel the module doesn;t get inserted
> > gives segmentation fault and if the Sec driver is configured as non-module type the kernel doesn't
> > bootsup at all!
> 
> David might be able to help with this. The ubsec driver is mostly used on linksys/asus machines,
> perhaps yours is slightly different?

Based on the freescale URL posted to users@openswan, I assume you're
referring to the "SEC23DRVRS" driver?  That is a standalone driver,
and won't be of use unless you're prepared to write code to
integrate it into your IPsec stack.

Known working (to me at least) IPsec offload configuration for the
8315 should be NETKEY with CONFIG_CRYPTO_DEV_TALITOS configured in
a vanilla kernel.  To be able to tell whether h/w crypto offload is
in operation, see 'grep talitos /proc/interrupts' run.

> Note that slow throughput could also be caused by fragmentation as a result of the extra IPsec
> header space, causing you to encrypt two packets for every one unencrypted packet. Try setting
> your LAN MTU to 1400 and see if the problem remains?

or lower?  Whether this is causing the problem can be verified by
comparing no-encryption vs. 'null' algorithm encryption.

Kim

Re: [Ocf-linux-users] [Openswan Users] IPSec L2tpv3 throughput low using Netkey kernel stack

[Paul W. <pa...@xe...>]

On Mon, 16 May 2011, Vasanth Ragavendran wrote:

> but when the Sec driver is configured as module into the kernel the module doesn;t get inserted
> gives segmentation fault and if the Sec driver is configured as non-module type the kernel doesn't
> bootsup at all!

David might be able to help with this. The ubsec driver is mostly used on linksys/asus machines,
perhaps yours is slightly different?

Note that slow throughput could also be caused by fragmentation as a result of the extra IPsec
header space, causing you to encrypt two packets for every one unencrypted packet. Try setting
your LAN MTU to 1400 and see if the problem remains?

Paul

Re: [Ocf-linux-users] Can cryptosoft be used as a bridge between OCF and Linux crypto APIs

[Zhou, B. <b-...@ti...>]

I have figured it out why. I need to use higher cra_priority in my driver than in xxx-generic.c.

Regards,
Bin

-----Original Message-----
From: Zhou, Bin 
Sent: Friday, May 06, 2011 1:58 PM
To: David McCullough; Yun-Fong Loh
Cc: ocf...@li...
Subject: Re: [Ocf-linux-users] Can cryptosoft be used as a bridge between OCF and Linux crypto APIs

I have to exclude aes-generic.c and des-generic.c from kernel build to make cryptosoft use my HW drivers. Is this as expected? Or something is wrong?

Thanks,
Bin

-----Original Message-----
From: David McCullough [mailto:dav...@Mc...] 
Sent: Thursday, May 05, 2011 7:00 PM
To: Yun-Fong Loh
Cc: Zhou, Bin; ocf...@li...
Subject: Re: [Ocf-linux-users] Can cryptosoft be used as a bridge between OCF and Linux crypto APIs


Jivin Yun-Fong Loh lays it down ...
> On Thu, May 5, 2011 at 1:27 PM, Zhou, Bin <b-...@ti...> wrote:
> > Yun,
> > Thanks for your response. That's good news to me:-)
> >
> > By saying "can practically be used", I meant it can handle all use cases of OpenSSL; and the reason I asked that is because I see following comments in cryptosoft.c and it makes me feel that some cases might not be handled here. I'm not familiar with OpenSSL, so not sure if this logic prevents some openSSL usage.
> >
> > static void swcr_process_req(struct swcr_req *req)
> > {
> > ?? ?? ?? ??struct swcr_data *sw;
> > ?? ?? ?? ??struct cryptop *crp = req->crp;
> > ?? ?? ?? ??struct cryptodesc *crd = req->crd;
> > ?? ?? ?? ??struct sk_buff *skb = (struct sk_buff *) crp->crp_buf;
> > ?? ?? ?? ??struct uio *uiop = (struct uio *) crp->crp_buf;
> > ?? ?? ?? ??int sg_num, sg_len, skip;
> >
> > ?? ?? ?? ??dprintk("%s()\n", __FUNCTION__);
> >
> > ?? ?? ?? ??/*
> > ?? ?? ?? ?? * Find the crypto context.
> > ?? ?? ?? ?? *
> > ?? ?? ?? ?? * XXX Note that the logic here prevents us from having
> > ?? ?? ?? ?? * XXX the same algorithm multiple times in a session
> > ?? ?? ?? ?? * XXX (or rather, we can but it won't give us the right
> > ?? ?? ?? ?? * XXX results). To do that, we'd need some way of differentiating
> > ?? ?? ?? ?? * XXX between the various instances of an algorithm (so we can
> > ?? ?? ?? ?? * XXX locate the correct crypto context).
> > ?? ?? ?? ?? */
> >
> > Regards,
> > Bin
> 
> That's a reasonable concern, I had not noticed that before.
> 
> I'm not entirely familiar with how OpenSSL works as well, but from
> looking at engine/hw_cryptodev.c in OpenSSL, it seems to invoke
> operations in a discrete manner so it doesn't look to me like a
> problem.

Thats a fair judgement.

What this means is that you cannot chain 3DES and 3DES together in the same
session.  This is pretty unlikely requirement and I don't believe the
openssl code would ever consider it,  they would be 2 seperate des
operations on seperate sessions with seperate keys etc.

In this context a session is something like "3des+sha1" or "aes128+md5".
So you can see that "3des+3des" is something you will rarely if ever require
even if openssl did support it.

Cheers,
Davidm

-- 
David McCullough,      dav...@mc...,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Ocf-linux-users mailing list
Ocf...@li...
https://lists.sourceforge.net/lists/listinfo/ocf-linux-users

Re: [Ocf-linux-users] Can cryptosoft be used as a bridge between OCF and Linux crypto APIs

[Zhou, B. <b-...@ti...>]

I have to exclude aes-generic.c and des-generic.c from kernel build to make cryptosoft use my HW drivers. Is this as expected? Or something is wrong?

Thanks,
Bin

-----Original Message-----
From: David McCullough [mailto:dav...@Mc...] 
Sent: Thursday, May 05, 2011 7:00 PM
To: Yun-Fong Loh
Cc: Zhou, Bin; ocf...@li...
Subject: Re: [Ocf-linux-users] Can cryptosoft be used as a bridge between OCF and Linux crypto APIs


Jivin Yun-Fong Loh lays it down ...
> On Thu, May 5, 2011 at 1:27 PM, Zhou, Bin <b-...@ti...> wrote:
> > Yun,
> > Thanks for your response. That's good news to me:-)
> >
> > By saying "can practically be used", I meant it can handle all use cases of OpenSSL; and the reason I asked that is because I see following comments in cryptosoft.c and it makes me feel that some cases might not be handled here. I'm not familiar with OpenSSL, so not sure if this logic prevents some openSSL usage.
> >
> > static void swcr_process_req(struct swcr_req *req)
> > {
> > ?? ?? ?? ??struct swcr_data *sw;
> > ?? ?? ?? ??struct cryptop *crp = req->crp;
> > ?? ?? ?? ??struct cryptodesc *crd = req->crd;
> > ?? ?? ?? ??struct sk_buff *skb = (struct sk_buff *) crp->crp_buf;
> > ?? ?? ?? ??struct uio *uiop = (struct uio *) crp->crp_buf;
> > ?? ?? ?? ??int sg_num, sg_len, skip;
> >
> > ?? ?? ?? ??dprintk("%s()\n", __FUNCTION__);
> >
> > ?? ?? ?? ??/*
> > ?? ?? ?? ?? * Find the crypto context.
> > ?? ?? ?? ?? *
> > ?? ?? ?? ?? * XXX Note that the logic here prevents us from having
> > ?? ?? ?? ?? * XXX the same algorithm multiple times in a session
> > ?? ?? ?? ?? * XXX (or rather, we can but it won't give us the right
> > ?? ?? ?? ?? * XXX results). To do that, we'd need some way of differentiating
> > ?? ?? ?? ?? * XXX between the various instances of an algorithm (so we can
> > ?? ?? ?? ?? * XXX locate the correct crypto context).
> > ?? ?? ?? ?? */
> >
> > Regards,
> > Bin
> 
> That's a reasonable concern, I had not noticed that before.
> 
> I'm not entirely familiar with how OpenSSL works as well, but from
> looking at engine/hw_cryptodev.c in OpenSSL, it seems to invoke
> operations in a discrete manner so it doesn't look to me like a
> problem.

Thats a fair judgement.

What this means is that you cannot chain 3DES and 3DES together in the same
session.  This is pretty unlikely requirement and I don't believe the
openssl code would ever consider it,  they would be 2 seperate des
operations on seperate sessions with seperate keys etc.

In this context a session is something like "3des+sha1" or "aes128+md5".
So you can see that "3des+3des" is something you will rarely if ever require
even if openssl did support it.

Cheers,
Davidm

-- 
David McCullough,      dav...@mc...,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org

Re: [Ocf-linux-users] Can cryptosoft be used as a bridge between OCF and Linux crypto APIs

[Zhou, B. <b-...@ti...>]

David,
Here is a question from my colleague:
 
Would this present a problem with modes that use the same underlying cipher for encrypt and for authentication such as AES for CBC mode and aes-xcbc-mac (which uses AES again in CBC mode with a different key in order to produce an authentication tag)?

Thanks,
Bin

-----Original Message-----
From: David McCullough [mailto:dav...@Mc...] 
Sent: Thursday, May 05, 2011 7:00 PM
To: Yun-Fong Loh
Cc: Zhou, Bin; ocf...@li...
Subject: Re: [Ocf-linux-users] Can cryptosoft be used as a bridge between OCF and Linux crypto APIs


Jivin Yun-Fong Loh lays it down ...
> On Thu, May 5, 2011 at 1:27 PM, Zhou, Bin <b-...@ti...> wrote:
> > Yun,
> > Thanks for your response. That's good news to me:-)
> >
> > By saying "can practically be used", I meant it can handle all use cases of OpenSSL; and the reason I asked that is because I see following comments in cryptosoft.c and it makes me feel that some cases might not be handled here. I'm not familiar with OpenSSL, so not sure if this logic prevents some openSSL usage.
> >
> > static void swcr_process_req(struct swcr_req *req)
> > {
> > ?? ?? ?? ??struct swcr_data *sw;
> > ?? ?? ?? ??struct cryptop *crp = req->crp;
> > ?? ?? ?? ??struct cryptodesc *crd = req->crd;
> > ?? ?? ?? ??struct sk_buff *skb = (struct sk_buff *) crp->crp_buf;
> > ?? ?? ?? ??struct uio *uiop = (struct uio *) crp->crp_buf;
> > ?? ?? ?? ??int sg_num, sg_len, skip;
> >
> > ?? ?? ?? ??dprintk("%s()\n", __FUNCTION__);
> >
> > ?? ?? ?? ??/*
> > ?? ?? ?? ?? * Find the crypto context.
> > ?? ?? ?? ?? *
> > ?? ?? ?? ?? * XXX Note that the logic here prevents us from having
> > ?? ?? ?? ?? * XXX the same algorithm multiple times in a session
> > ?? ?? ?? ?? * XXX (or rather, we can but it won't give us the right
> > ?? ?? ?? ?? * XXX results). To do that, we'd need some way of differentiating
> > ?? ?? ?? ?? * XXX between the various instances of an algorithm (so we can
> > ?? ?? ?? ?? * XXX locate the correct crypto context).
> > ?? ?? ?? ?? */
> >
> > Regards,
> > Bin
> 
> That's a reasonable concern, I had not noticed that before.
> 
> I'm not entirely familiar with how OpenSSL works as well, but from
> looking at engine/hw_cryptodev.c in OpenSSL, it seems to invoke
> operations in a discrete manner so it doesn't look to me like a
> problem.

Thats a fair judgement.

What this means is that you cannot chain 3DES and 3DES together in the same
session.  This is pretty unlikely requirement and I don't believe the
openssl code would ever consider it,  they would be 2 seperate des
operations on seperate sessions with seperate keys etc.

In this context a session is something like "3des+sha1" or "aes128+md5".
So you can see that "3des+3des" is something you will rarely if ever require
even if openssl did support it.

Cheers,
Davidm

-- 
David McCullough,      dav...@mc...,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org

Re: [Ocf-linux-users] Can cryptosoft be used as a bridge between OCF and Linux crypto APIs

[Lide, D. <dl...@ti...>]

Would this present a problem with modes that use the same underlying cipher for encrypt and for authentication such as AES for CBC mode and aes-xcbc-mac (which uses AES again in CBC mode with a different key in order to produce an authentication tag) ?


-----Original Message-----
From: David McCullough [mailto:dav...@mc...] 
Sent: Thursday, May 05, 2011 7:00 PM
To: Yun-Fong Loh
Cc: ocf...@li...
Subject: Re: [Ocf-linux-users] Can cryptosoft be used as a bridge between OCF and Linux crypto APIs


Jivin Yun-Fong Loh lays it down ...
> On Thu, May 5, 2011 at 1:27 PM, Zhou, Bin <b-...@ti...> wrote:
> > Yun,
> > Thanks for your response. That's good news to me:-)
> >
> > By saying "can practically be used", I meant it can handle all use cases of OpenSSL; and the reason I asked that is because I see following comments in cryptosoft.c and it makes me feel that some cases might not be handled here. I'm not familiar with OpenSSL, so not sure if this logic prevents some openSSL usage.
> >
> > static void swcr_process_req(struct swcr_req *req) { ?? ?? ?? 
> > ??struct swcr_data *sw; ?? ?? ?? ??struct cryptop *crp = req->crp; 
> > ?? ?? ?? ??struct cryptodesc *crd = req->crd; ?? ?? ?? ??struct 
> > sk_buff *skb = (struct sk_buff *) crp->crp_buf; ?? ?? ?? ??struct 
> > uio *uiop = (struct uio *) crp->crp_buf; ?? ?? ?? ??int sg_num, 
> > sg_len, skip;
> >
> > ?? ?? ?? ??dprintk("%s()\n", __FUNCTION__);
> >
> > ?? ?? ?? ??/*
> > ?? ?? ?? ?? * Find the crypto context.
> > ?? ?? ?? ?? *
> > ?? ?? ?? ?? * XXX Note that the logic here prevents us from having 
> > ?? ?? ?? ?? * XXX the same algorithm multiple times in a session ?? 
> > ?? ?? ?? * XXX (or rather, we can but it won't give us the right ?? 
> > ?? ?? ?? * XXX results). To do that, we'd need some way of 
> > differentiating ?? ?? ?? ?? * XXX between the various instances of 
> > an algorithm (so we can ?? ?? ?? ?? * XXX locate the correct crypto context).
> > ?? ?? ?? ?? */
> >
> > Regards,
> > Bin
> 
> That's a reasonable concern, I had not noticed that before.
> 
> I'm not entirely familiar with how OpenSSL works as well, but from 
> looking at engine/hw_cryptodev.c in OpenSSL, it seems to invoke 
> operations in a discrete manner so it doesn't look to me like a 
> problem.

Thats a fair judgement.

What this means is that you cannot chain 3DES and 3DES together in the same session.  This is pretty unlikely requirement and I don't believe the openssl code would ever consider it,  they would be 2 seperate des operations on seperate sessions with seperate keys etc.

In this context a session is something like "3des+sha1" or "aes128+md5".
So you can see that "3des+3des" is something you will rarely if ever require even if openssl did support it.

Cheers,
Davidm

-- 
David McCullough,      dav...@mc...,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today.  Delivers lowest initial acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Ocf-linux-users mailing list
Ocf...@li...
https://lists.sourceforge.net/lists/listinfo/ocf-linux-users

Re: [Ocf-linux-users] Can cryptosoft be used as a bridge between OCF and Linux crypto APIs

[Zhou, B. <b-...@ti...>]

Thanks a lot for your explanations, which make us concern free to use cryptosoft as a bridge. 

Best regards,
Bin

-----Original Message-----
From: David McCullough [mailto:dav...@Mc...] 
Sent: Thursday, May 05, 2011 7:00 PM
To: Yun-Fong Loh
Cc: Zhou, Bin; ocf...@li...
Subject: Re: [Ocf-linux-users] Can cryptosoft be used as a bridge between OCF and Linux crypto APIs


Jivin Yun-Fong Loh lays it down ...
> On Thu, May 5, 2011 at 1:27 PM, Zhou, Bin <b-...@ti...> wrote:
> > Yun,
> > Thanks for your response. That's good news to me:-)
> >
> > By saying "can practically be used", I meant it can handle all use cases of OpenSSL; and the reason I asked that is because I see following comments in cryptosoft.c and it makes me feel that some cases might not be handled here. I'm not familiar with OpenSSL, so not sure if this logic prevents some openSSL usage.
> >
> > static void swcr_process_req(struct swcr_req *req)
> > {
> > ?? ?? ?? ??struct swcr_data *sw;
> > ?? ?? ?? ??struct cryptop *crp = req->crp;
> > ?? ?? ?? ??struct cryptodesc *crd = req->crd;
> > ?? ?? ?? ??struct sk_buff *skb = (struct sk_buff *) crp->crp_buf;
> > ?? ?? ?? ??struct uio *uiop = (struct uio *) crp->crp_buf;
> > ?? ?? ?? ??int sg_num, sg_len, skip;
> >
> > ?? ?? ?? ??dprintk("%s()\n", __FUNCTION__);
> >
> > ?? ?? ?? ??/*
> > ?? ?? ?? ?? * Find the crypto context.
> > ?? ?? ?? ?? *
> > ?? ?? ?? ?? * XXX Note that the logic here prevents us from having
> > ?? ?? ?? ?? * XXX the same algorithm multiple times in a session
> > ?? ?? ?? ?? * XXX (or rather, we can but it won't give us the right
> > ?? ?? ?? ?? * XXX results). To do that, we'd need some way of differentiating
> > ?? ?? ?? ?? * XXX between the various instances of an algorithm (so we can
> > ?? ?? ?? ?? * XXX locate the correct crypto context).
> > ?? ?? ?? ?? */
> >
> > Regards,
> > Bin
> 
> That's a reasonable concern, I had not noticed that before.
> 
> I'm not entirely familiar with how OpenSSL works as well, but from
> looking at engine/hw_cryptodev.c in OpenSSL, it seems to invoke
> operations in a discrete manner so it doesn't look to me like a
> problem.

Thats a fair judgement.

What this means is that you cannot chain 3DES and 3DES together in the same
session.  This is pretty unlikely requirement and I don't believe the
openssl code would ever consider it,  they would be 2 seperate des
operations on seperate sessions with seperate keys etc.

In this context a session is something like "3des+sha1" or "aes128+md5".
So you can see that "3des+3des" is something you will rarely if ever require
even if openssl did support it.

Cheers,
Davidm

-- 
David McCullough,      dav...@mc...,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org

Re: [Ocf-linux-users] Can cryptosoft be used as a bridge between OCF and Linux crypto APIs

[David M. <dav...@mc...>]

Jivin Yun-Fong Loh lays it down ...
> On Thu, May 5, 2011 at 1:27 PM, Zhou, Bin <b-...@ti...> wrote:
> > Yun,
> > Thanks for your response. That's good news to me:-)
> >
> > By saying "can practically be used", I meant it can handle all use cases of OpenSSL; and the reason I asked that is because I see following comments in cryptosoft.c and it makes me feel that some cases might not be handled here. I'm not familiar with OpenSSL, so not sure if this logic prevents some openSSL usage.
> >
> > static void swcr_process_req(struct swcr_req *req)
> > {
> > ?? ?? ?? ??struct swcr_data *sw;
> > ?? ?? ?? ??struct cryptop *crp = req->crp;
> > ?? ?? ?? ??struct cryptodesc *crd = req->crd;
> > ?? ?? ?? ??struct sk_buff *skb = (struct sk_buff *) crp->crp_buf;
> > ?? ?? ?? ??struct uio *uiop = (struct uio *) crp->crp_buf;
> > ?? ?? ?? ??int sg_num, sg_len, skip;
> >
> > ?? ?? ?? ??dprintk("%s()\n", __FUNCTION__);
> >
> > ?? ?? ?? ??/*
> > ?? ?? ?? ?? * Find the crypto context.
> > ?? ?? ?? ?? *
> > ?? ?? ?? ?? * XXX Note that the logic here prevents us from having
> > ?? ?? ?? ?? * XXX the same algorithm multiple times in a session
> > ?? ?? ?? ?? * XXX (or rather, we can but it won't give us the right
> > ?? ?? ?? ?? * XXX results). To do that, we'd need some way of differentiating
> > ?? ?? ?? ?? * XXX between the various instances of an algorithm (so we can
> > ?? ?? ?? ?? * XXX locate the correct crypto context).
> > ?? ?? ?? ?? */
> >
> > Regards,
> > Bin
> 
> That's a reasonable concern, I had not noticed that before.
> 
> I'm not entirely familiar with how OpenSSL works as well, but from
> looking at engine/hw_cryptodev.c in OpenSSL, it seems to invoke
> operations in a discrete manner so it doesn't look to me like a
> problem.

Thats a fair judgement.

What this means is that you cannot chain 3DES and 3DES together in the same
session.  This is pretty unlikely requirement and I don't believe the
openssl code would ever consider it,  they would be 2 seperate des
operations on seperate sessions with seperate keys etc.

In this context a session is something like "3des+sha1" or "aes128+md5".
So you can see that "3des+3des" is something you will rarely if ever require
even if openssl did support it.

Cheers,
Davidm

-- 
David McCullough,      dav...@mc...,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org

Re: [Ocf-linux-users] Can cryptosoft be used as a bridge between OCF and Linux crypto APIs

[Yun-Fong L. <yl...@ed...>]

On Thu, May 5, 2011 at 1:27 PM, Zhou, Bin <b-...@ti...> wrote:
> Yun,
> Thanks for your response. That's good news to me:-)
>
> By saying "can practically be used", I meant it can handle all use cases of OpenSSL; and the reason I asked that is because I see following comments in cryptosoft.c and it makes me feel that some cases might not be handled here. I'm not familiar with OpenSSL, so not sure if this logic prevents some openSSL usage.
>
> static void swcr_process_req(struct swcr_req *req)
> {
>        struct swcr_data *sw;
>        struct cryptop *crp = req->crp;
>        struct cryptodesc *crd = req->crd;
>        struct sk_buff *skb = (struct sk_buff *) crp->crp_buf;
>        struct uio *uiop = (struct uio *) crp->crp_buf;
>        int sg_num, sg_len, skip;
>
>        dprintk("%s()\n", __FUNCTION__);
>
>        /*
>         * Find the crypto context.
>         *
>         * XXX Note that the logic here prevents us from having
>         * XXX the same algorithm multiple times in a session
>         * XXX (or rather, we can but it won't give us the right
>         * XXX results). To do that, we'd need some way of differentiating
>         * XXX between the various instances of an algorithm (so we can
>         * XXX locate the correct crypto context).
>         */
>
> Regards,
> Bin

That's a reasonable concern, I had not noticed that before.

I'm not entirely familiar with how OpenSSL works as well, but from
looking at engine/hw_cryptodev.c in OpenSSL, it seems to invoke
operations in a discrete manner so it doesn't look to me like a
problem.

Yun

Re: [Ocf-linux-users] Can cryptosoft be used as a bridge between OCF and Linux crypto APIs

[Yun-Fong L. <yl...@ed...>]

I have used cryptosoft successfully with OpenSSL.

What criteria are you using to determine whether it can "practically be used"?

Yun

On Thu, May 5, 2011 at 12:20 PM, Zhou, Bin <b-...@ti...> wrote:
> Hi,
>
> We are doing Linux Async Crypto drivers for HW accelerators (AES, DES/3DES,
> SHA1/MD5) and kernel version we are using now is 2.6.37. Since user space
> APIs for Linux Crypto are still under development and not available in
> 2.6.37, we are looking at putting OCF on top of Linux crypto APIs. We see
> that there is cryptosoft module in OCF package which can translate between
> OCF requests and Linux crypto requests.
>
> Does anybody know if cryptosoft can practically be used as a bridge to
> handle all possible OpenSSL use cases?
>
> If it can not, is there any other existing software that is able to perform
> as a bridge?
>
>
>
> Many thanks in advance!
>
>
>
> Bin
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> Ocf-linux-users mailing list
> Ocf...@li...
> https://lists.sourceforge.net/lists/listinfo/ocf-linux-users
>
>

Re: [Ocf-linux-users] Can cryptosoft be used as a bridge between OCF and Linux crypto APIs

[Zhou, B. <b-...@ti...>]

Yun,
Thanks for your response. That's good news to me:-)

By saying "can practically be used", I meant it can handle all use cases of OpenSSL; and the reason I asked that is because I see following comments in cryptosoft.c and it makes me feel that some cases might not be handled here. I'm not familiar with OpenSSL, so not sure if this logic prevents some openSSL usage.

static void swcr_process_req(struct swcr_req *req)
{
	struct swcr_data *sw;
	struct cryptop *crp = req->crp;
	struct cryptodesc *crd = req->crd;
	struct sk_buff *skb = (struct sk_buff *) crp->crp_buf;
	struct uio *uiop = (struct uio *) crp->crp_buf;
	int sg_num, sg_len, skip;

	dprintk("%s()\n", __FUNCTION__);

	/*
	 * Find the crypto context.
	 *
	 * XXX Note that the logic here prevents us from having
	 * XXX the same algorithm multiple times in a session
	 * XXX (or rather, we can but it won't give us the right
	 * XXX results). To do that, we'd need some way of differentiating
	 * XXX between the various instances of an algorithm (so we can
	 * XXX locate the correct crypto context).
	 */

Regards,
Bin


-----Original Message-----
From: Yun-Fong Loh [mailto:yl...@ed...] 
Sent: Thursday, May 05, 2011 4:05 PM
To: Zhou, Bin
Cc: ocf...@li...
Subject: Re: [Ocf-linux-users] Can cryptosoft be used as a bridge between OCF and Linux crypto APIs

I have used cryptosoft successfully with OpenSSL.

What criteria are you using to determine whether it can "practically be used"?

Yun

On Thu, May 5, 2011 at 12:20 PM, Zhou, Bin <b-...@ti...> wrote:
> Hi,
>
> We are doing Linux Async Crypto drivers for HW accelerators (AES, DES/3DES,
> SHA1/MD5) and kernel version we are using now is 2.6.37. Since user space
> APIs for Linux Crypto are still under development and not available in
> 2.6.37, we are looking at putting OCF on top of Linux crypto APIs. We see
> that there is cryptosoft module in OCF package which can translate between
> OCF requests and Linux crypto requests.
>
> Does anybody know if cryptosoft can practically be used as a bridge to
> handle all possible OpenSSL use cases?
>
> If it can not, is there any other existing software that is able to perform
> as a bridge?
>
>
>
> Many thanks in advance!
>
>
>
> Bin
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> Ocf-linux-users mailing list
> Ocf...@li...
> https://lists.sourceforge.net/lists/listinfo/ocf-linux-users
>
>

[Ocf-linux-users] Can cryptosoft be used as a bridge between OCF and Linux crypto APIs

[Zhou, B. <b-...@ti...>]

Hi,
We are doing Linux Async Crypto drivers for HW accelerators (AES, DES/3DES, SHA1/MD5) and kernel version we are using now is 2.6.37. Since user space APIs for Linux Crypto are still under development and not available in 2.6.37, we are looking at putting OCF on top of Linux crypto APIs. We see that there is cryptosoft module in OCF package which can translate between OCF requests and Linux crypto requests.
Does anybody know if cryptosoft can practically be used as a bridge to handle all possible OpenSSL use cases?
If it can not, is there any other existing software that is able to perform as a bridge?

Many thanks in advance!

Bin

Re: [Ocf-linux-users] ocf-bench generates "Error in OCF processing: 5" using talitos SEC driver

[David M. <dav...@mc...>]

Jivin 张绪峰 lays it down ...
> Hi All,
> 
> I have found a bug to run ocf-bench on ocf talitos driver.
> the request_size should not be 1500, because it is not a multiple of 64 bits while DEU data
> size register need it to be, or DEU will generate error interrupt.

Ok,  there is a patch for a newer version of ocf (depending on which version
you are running) that already addresses this.

Read http://sourceforge.net/mailarchive/message.php?msg_id=26796850 and get
the patch http://sourceforge.net/mailarchive/attachment.php?list_name=ocf-linux-users&message_id=20101222154234.GA25009%40mcafee.com&counter=1

This patch is aginst version ocf-linux-20100325,  so if you are not running
that version you may have some problems with the patch.

> But I still have another error interrupt need to be resolved, that's channel_1 CCPSR Error 50.
> from the 8548e datasheet, I get this description:
> -----------------------------------------------------------------------------------
> Error value 50:
> MDTE. A master data transfer error was received from the master bus interface. When the SEC, while acting
> as a bus master, detects an error, the controller passes the error to the channel in use. The channel halts and
> activates an interrupt. The channel can only be restarted by writing a ??1?? to the continue or reset bit in the
> channel configuration register, or resetting the whole SEC.
> -----------------------------------------------------------------------------------
> But this don't mean much to me, how can I determine which cause this error?

I have no idea on this one, sorry,  sounds like something is making the
hardware unhappy.  Could be the buffers ocf-bench is passing down or
something wrong within the driver,  no idea really.

Cheers,
Davidm


> At 2011-04-14 14:24:47,"David McCullough" <dav...@mc...> wrote:
> 
> >
> >Jivin ??? lays it down ...
> >> Hi experts,
> >> 
> >> I met some difficulties to run ocf-bench.ko on talitos SEC driver.
> >> It always generate errors "Error in OCF processing: 5" when run "insmod ocf-bench.ko" on 8548e board.
> >> 
> >> How to reproduce:
> >> 1. configure "CONFIG_CRYPTO_DEV_TALITOS=n" "CONFIG_OCF_TALITOS=m"
> >>                     "CONFIG_OCF_OCF=y" "CONFIG_OCF_CRYPTODEV=y" "CONFIG_OCF_BENCH=m"
> >> 2. build the kernel and boot the 8548e board.
> >> 3. insmod talitos.ko
> >> 4. insmod ocf-bench.ko
> >> Then I got such errors "Error in OCF processing: 5". 
> >> I know it is due to SEC h/w receive error interrupts during request processing,
> >> and the error bits in Channel_1 CCPSR register is 50 and 55. But I don't know how to do with it.
> >> 
> >> I also run some openssl speed test such as "openssl speed -evp des -elapsed" on ocf talitos driver, 
> >> it seems work fine, no error interrupt happens.
> >> 
> >> So I want to know why this problem could happen? 
> >> Any advice would be appreciated, thanks in advance!
> >
> >So it sounds like it's working but ocf-bench is causing the driver
> >headaches.
> >
> >Which version of ocf are you using ?
> >
> >Check through the ocf-bench code for something like this:
> >
> >	if (request_batch)
> >		crp->crp_flags |= CRYPTO_F_BATCH;
> >	if (request_cbimm)
> >		crp->crp_flags |= CRYPTO_F_CBIMM;
> >
> >If you have it then good,  otherwise you need to find where crp->crp_flags
> >is set and try setting it to one of the following:
> >
> >		crp->crp_flags = (CRYPTO_F_BATCH|CRYPTO_F_CBIMM);
> >		crp->crp_flags = CRYPTO_F_CBIMM;
> >		crp->crp_flags = CRYPTO_F_BATCH;
> >		crp->crp_flags = 0;
> >
> >That may fix it. Also,  the latest ocf-bench does an SHA1/AES test,  just in
> >case that is confusing you with des working above.  So not only does it use
> >AES but it also hashes at the same time.  Could be something to look into.
> >
> >Cheers,
> >Davidm
> >
> >-- 
> >David McCullough,      dav...@mc...,  Ph:+61 734352815
> >McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org
> 
> 
> 
> 

-- 
David McCullough,      dav...@mc...,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org

Re: [Ocf-linux-users] ocf-bench generates "Error in OCF processing: 5" using talitos SEC driver

[张绪峰 <sea...@12...>]

Hi All,

I have found a bug to run ocf-bench on ocf talitos driver.
the request_size should not be 1500, because it is not a multiple of 64 bits while DEU data
size register need it to be, or DEU will generate error interrupt.
But I still have another error interrupt need to be resolved, that's channel_1 CCPSR Error 50.
From the 8548e datasheet, I get this description:
-----------------------------------------------------------------------------------
Error value 50:
MDTE. A master data transfer error was received from the master bus interface. When the SEC, while acting
as a bus master, detects an error, the controller passes the error to the channel in use. The channel halts and
activates an interrupt. The channel can only be restarted by writing a ‘1’ to the continue or reset bit in the
channel configuration register, or resetting the whole SEC.
-----------------------------------------------------------------------------------
But this don't mean much to me, how can I determine which cause this error?



Thanks,
Xufeng Zhang




At 2011-04-14 14:24:47，"David McCullough" <dav...@mc...> wrote:

>
>Jivin 张绪峰 lays it down ...
>> Hi experts,
>> 
>> I met some difficulties to run ocf-bench.ko on talitos SEC driver.
>> It always generate errors "Error in OCF processing: 5" when run "insmod ocf-bench.ko" on 8548e board.
>> 
>> How to reproduce:
>> 1. configure "CONFIG_CRYPTO_DEV_TALITOS=n" "CONFIG_OCF_TALITOS=m"
>>                     "CONFIG_OCF_OCF=y" "CONFIG_OCF_CRYPTODEV=y" "CONFIG_OCF_BENCH=m"
>> 2. build the kernel and boot the 8548e board.
>> 3. insmod talitos.ko
>> 4. insmod ocf-bench.ko
>> Then I got such errors "Error in OCF processing: 5". 
>> I know it is due to SEC h/w receive error interrupts during request processing,
>> and the error bits in Channel_1 CCPSR register is 50 and 55. But I don't know how to do with it.
>> 
>> I also run some openssl speed test such as "openssl speed -evp des -elapsed" on ocf talitos driver, 
>> it seems work fine, no error interrupt happens.
>> 
>> So I want to know why this problem could happen? 
>> Any advice would be appreciated, thanks in advance!
>
>So it sounds like it's working but ocf-bench is causing the driver
>headaches.
>
>Which version of ocf are you using ?
>
>Check through the ocf-bench code for something like this:
>
>	if (request_batch)
>		crp->crp_flags |= CRYPTO_F_BATCH;
>	if (request_cbimm)
>		crp->crp_flags |= CRYPTO_F_CBIMM;
>
>If you have it then good,  otherwise you need to find where crp->crp_flags
>is set and try setting it to one of the following:
>
>		crp->crp_flags = (CRYPTO_F_BATCH|CRYPTO_F_CBIMM);
>		crp->crp_flags = CRYPTO_F_CBIMM;
>		crp->crp_flags = CRYPTO_F_BATCH;
>		crp->crp_flags = 0;
>
>That may fix it. Also,  the latest ocf-bench does an SHA1/AES test,  just in
>case that is confusing you with des working above.  So not only does it use
>AES but it also hashes at the same time.  Could be something to look into.
>
>Cheers,
>Davidm
>
>-- 
>David McCullough,      dav...@mc...,  Ph:+61 734352815
>McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org

Re: [Ocf-linux-users] ocf-bench generates "Error in OCF processing: 5" using talitos SEC driver

[张绪峰 <sea...@12...>]

At 2011-04-14 14:24:47，"David McCullough" <dav...@mc...> wrote:

>
>Jivin 张绪峰 lays it down ...
>> Hi experts,
>> 
>> I met some difficulties to run ocf-bench.ko on talitos SEC driver.
>> It always generate errors "Error in OCF processing: 5" when run "insmod ocf-bench.ko" on 8548e board.
>> 
>> How to reproduce:
>> 1. configure "CONFIG_CRYPTO_DEV_TALITOS=n" "CONFIG_OCF_TALITOS=m"
>>                     "CONFIG_OCF_OCF=y" "CONFIG_OCF_CRYPTODEV=y" "CONFIG_OCF_BENCH=m"
>> 2. build the kernel and boot the 8548e board.
>> 3. insmod talitos.ko
>> 4. insmod ocf-bench.ko
>> Then I got such errors "Error in OCF processing: 5". 
>> I know it is due to SEC h/w receive error interrupts during request processing,
>> and the error bits in Channel_1 CCPSR register is 50 and 55. But I don't know how to do with it.
>> 
>> I also run some openssl speed test such as "openssl speed -evp des -elapsed" on ocf talitos driver, 
>> it seems work fine, no error interrupt happens.
>> 
>> So I want to know why this problem could happen? 
>> Any advice would be appreciated, thanks in advance!
>
>So it sounds like it's working but ocf-bench is causing the driver
>headaches.
Thank you very much for your prompt reply, Davidm.
Actually, the original driver was not working at first, the talitos_probe() function
will never be called, after I made some changes, then it works.
Here is the change:
--- a/crypto/ocf/talitos/talitos.c      
+++ b/crypto/ocf/talitos/talitos.c     
@@ -1306,8 +1306,7 @@
 #ifdef CONFIG_PPC_MERGE
 static struct of_device_id talitos_match[] = {
        {
-               .type = "crypto",
-               .compatible = "talitos",
+               .compatible = "fsl,sec2.0",
        },
        {},
 };
>
>Which version of ocf are you using ?
I'm not very sure about that, from the ChangeLog file, the newest update time is: 2008-09-18 01:27.

>
>Check through the ocf-bench code for something like this:
>
>	if (request_batch)
>		crp->crp_flags |= CRYPTO_F_BATCH;
>	if (request_cbimm)
>		crp->crp_flags |= CRYPTO_F_CBIMM;
>
I didn't find such codes in ocf-bench.c.

>If you have it then good,  otherwise you need to find where crp->crp_flags
>is set and try setting it to one of the following:
>
>		crp->crp_flags = (CRYPTO_F_BATCH|CRYPTO_F_CBIMM);
>		crp->crp_flags = CRYPTO_F_CBIMM;
>		crp->crp_flags = CRYPTO_F_BATCH;
>		crp->crp_flags = 0;
I have tried each of these four setting, no one works, the same error. 
"crp->crp_flags = CRYPTO_F_CBIMM;" is the original setting.


Thanks,
Ted
>
>That may fix it. Also,  the latest ocf-bench does an SHA1/AES test,  just in
>case that is confusing you with des working above.  So not only does it use
>AES but it also hashes at the same time.  Could be something to look into.
>
>Cheers,
>Davidm
>
>-- 
>David McCullough,      dav...@mc...,  Ph:+61 734352815
>McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org

Re: [Ocf-linux-users] ocf-bench generates "Error in OCF processing: 5" using talitos SEC driver

[David M. <dav...@mc...>]

Jivin 张绪峰 lays it down ...
> Hi experts,
> 
> I met some difficulties to run ocf-bench.ko on talitos SEC driver.
> It always generate errors "Error in OCF processing: 5" when run "insmod ocf-bench.ko" on 8548e board.
> 
> How to reproduce:
> 1. configure "CONFIG_CRYPTO_DEV_TALITOS=n" "CONFIG_OCF_TALITOS=m"
>                     "CONFIG_OCF_OCF=y" "CONFIG_OCF_CRYPTODEV=y" "CONFIG_OCF_BENCH=m"
> 2. build the kernel and boot the 8548e board.
> 3. insmod talitos.ko
> 4. insmod ocf-bench.ko
> Then I got such errors "Error in OCF processing: 5". 
> I know it is due to SEC h/w receive error interrupts during request processing,
> and the error bits in Channel_1 CCPSR register is 50 and 55. But I don't know how to do with it.
> 
> I also run some openssl speed test such as "openssl speed -evp des -elapsed" on ocf talitos driver, 
> it seems work fine, no error interrupt happens.
> 
> So I want to know why this problem could happen? 
> Any advice would be appreciated, thanks in advance!

So it sounds like it's working but ocf-bench is causing the driver
headaches.

Which version of ocf are you using ?

Check through the ocf-bench code for something like this:

	if (request_batch)
		crp->crp_flags |= CRYPTO_F_BATCH;
	if (request_cbimm)
		crp->crp_flags |= CRYPTO_F_CBIMM;

If you have it then good,  otherwise you need to find where crp->crp_flags
is set and try setting it to one of the following:

		crp->crp_flags = (CRYPTO_F_BATCH|CRYPTO_F_CBIMM);
		crp->crp_flags = CRYPTO_F_CBIMM;
		crp->crp_flags = CRYPTO_F_BATCH;
		crp->crp_flags = 0;

That may fix it. Also,  the latest ocf-bench does an SHA1/AES test,  just in
case that is confusing you with des working above.  So not only does it use
AES but it also hashes at the same time.  Could be something to look into.

Cheers,
Davidm

-- 
David McCullough,      dav...@mc...,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org

[Ocf-linux-users] ocf-bench generates "Error in OCF processing: 5" using talitos SEC driver

[张绪峰 <sea...@12...>]

Hi experts,

I met some difficulties to run ocf-bench.ko on talitos SEC driver.
It always generate errors "Error in OCF processing: 5" when run "insmod ocf-bench.ko" on 8548e board.

How to reproduce:
1. configure "CONFIG_CRYPTO_DEV_TALITOS=n" "CONFIG_OCF_TALITOS=m"
                    "CONFIG_OCF_OCF=y" "CONFIG_OCF_CRYPTODEV=y" "CONFIG_OCF_BENCH=m"
2. build the kernel and boot the 8548e board.
3. insmod talitos.ko
4. insmod ocf-bench.ko
Then I got such errors "Error in OCF processing: 5".
I know it is due to SEC h/w receive error interrupts during request processing,
and the error bits in Channel_1 CCPSR register is 50 and 55. But I don't know how to do with it.

I also run some openssl speed test such as "openssl speed -evp des -elapsed" on ocf talitos driver,
it seems work fine, no error interrupt happens.

So I want to know why this problem could happen?
Any advice would be appreciated, thanks in advance!



Thanks,
Ted

[Ocf-linux-users] ocf-bench generates "Error in OCF processing: 2" when crytosoft driver is built-in

[张绪峰 <sea...@12...>]

Hi experts,

I met errors "Error in OCF processing: 2" when I run "insmod ocf-bench.ko" when crytosoft driver is made built-in,
but if build crytosoft driver as a module, then such errors don't happen.
I tried to debug this problem and found the second algorithm(eg. CRYPTO_3DES_CBC) is not supported,
so it returns error "crypto_newsession failed 22" when creating newsessions, afterward it would generate such
errors "Error in OCF processing: 2" in ocf_cb() function.
But what's the difference between make crytosoft driver built-in and not built-in? this is really hard to understand for me.
How to reproduce(fedora system):
1. configure ocf, crytodev and crytosoft drivers as built-in, configure ocf-bench as a module.
2. boot the system and run "insmod ocf-bench.ko", then got the error by "cat /var/log/message".
I would appreciate if anybody could give any suggestions.
Thanks in advance!


Thanks,
Ted

Re: [Ocf-linux-users] RSA function using hardware PKEU

[David M. <dav...@mc...>]

Jivin kaoru lays it down ...
> What's ixp safenet? It supports freescale sec2 hw public key ops?
> Could you give me a link to homepage?

No,  the ixp driver and the safenet driver are the only drivers that support
PK ops.

They are for different hardware.

There are currently no drivers that support the freescale sec2 PK HW,

Cheers,
Davidm

> On 2011-03-30 18:55, David McCullough Wrote:
> >
> > Jivin kaoru lays it down ...
> >> Hello everyone, I'm a newbie with OCF.
> >>
> >> My board used freescale MPC8315E processor. Followed README, i patched
> >> kernel and openssl-0.9.8i.
> >>
> >> The question is:
> >> use "openssl speed -evp des -engine cryptodev -elapsed" testing, the
> >> talitos interrupt number increased,
> >> but use "openssl speed -engine cryptodev rsa -elapsed" testing, the
> >> tailitos interrupt number not increased.
> >>
> >> I found talitos/talitos.c issue "add support for public key ops (PKEU)".
> >> Whether it means that rsa function using the hardware PKEU not implement?
> >
> > The talitos driver in OCF does not do any PK accelerations.
> > I don't know if the HW is capable of it,  but the code certainly isn't at
> > the moment :-)
> >
> > To check just look for a crypto_kregister in the driver.  Currently only the
> > ixp and safenet drivers do this,
> >
> > Cheers,
> > Davidm
> >
> >
> 
> -- 
> Regards
> 
> ??????????????
> ??
> Mobile:   13426333791
> Tel:      010-82890375-807
> Addr:     ???????????9??29????????1605
> HomePage: http://www.yytek.com
> 
> 

-- 
David McCullough,      dav...@mc...,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org

Re: [Ocf-linux-users] RSA function using hardware PKEU

[kaoru <ga...@yy...>]

What's ixp safenet? It supports freescale sec2 hw public key ops?
Could you give me a link to homepage?

Thanks.

On 2011-03-30 18:55, David McCullough Wrote:
>
> Jivin kaoru lays it down ...
>> Hello everyone, I'm a newbie with OCF.
>>
>> My board used freescale MPC8315E processor. Followed README, i patched
>> kernel and openssl-0.9.8i.
>>
>> The question is:
>> use "openssl speed -evp des -engine cryptodev -elapsed" testing, the
>> talitos interrupt number increased,
>> but use "openssl speed -engine cryptodev rsa -elapsed" testing, the
>> tailitos interrupt number not increased.
>>
>> I found talitos/talitos.c issue "add support for public key ops (PKEU)".
>> Whether it means that rsa function using the hardware PKEU not implement?
>
> The talitos driver in OCF does not do any PK accelerations.
> I don't know if the HW is capable of it,  but the code certainly isn't at
> the moment :-)
>
> To check just look for a crypto_kregister in the driver.  Currently only the
> ixp and safenet drivers do this,
>
> Cheers,
> Davidm
>
>

-- 
Regards

北京云涌科技发展有限责任公司
高渊
Mobile:   13426333791
Tel:      010-82890375-807
Addr:     北京市海淀区安宁庄西路9号院29号楼金泰富地大厦1605
HomePage: http://www.yytek.com

Re: [Ocf-linux-users] RSA function using hardware PKEU

[Kim P. <kim...@fr...>]

On Wed, 30 Mar 2011 20:55:08 +1000
David McCullough <dav...@mc...> wrote:

> Jivin kaoru lays it down ...
> > I found talitos/talitos.c issue "add support for public key ops (PKEU)".
> > Whether it means that rsa function using the hardware PKEU not implement?
> 
> The talitos driver in OCF does not do any PK accelerations.
> I don't know if the HW is capable of it,  but the code certainly isn't at
> the moment :-)

the SEC h/w on the 8315 is capable, but you're right - the driver
doesn't implement public key ops.

Kim

Re: [Ocf-linux-users] RSA function using hardware PKEU

[David M. <dav...@mc...>]

Jivin kaoru lays it down ...
> Hello everyone, I'm a newbie with OCF.
> 
> My board used freescale MPC8315E processor. Followed README, i patched 
> kernel and openssl-0.9.8i.
> 
> The question is:
> use "openssl speed -evp des -engine cryptodev -elapsed" testing, the 
> talitos interrupt number increased,
> but use "openssl speed -engine cryptodev rsa -elapsed" testing, the 
> tailitos interrupt number not increased.
> 
> I found talitos/talitos.c issue "add support for public key ops (PKEU)".
> Whether it means that rsa function using the hardware PKEU not implement?

The talitos driver in OCF does not do any PK accelerations.
I don't know if the HW is capable of it,  but the code certainly isn't at
the moment :-)

To check just look for a crypto_kregister in the driver.  Currently only the
ixp and safenet drivers do this,

Cheers,
Davidm


-- 
David McCullough,      dav...@mc...,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org

[Ocf-linux-users] RSA function using hardware PKEU

[kaoru <ga...@yy...>]

Hello everyone, I'm a newbie with OCF.

My board used freescale MPC8315E processor. Followed README, i patched 
kernel and openssl-0.9.8i.

The question is:
use "openssl speed -evp des -engine cryptodev -elapsed" testing, the 
talitos interrupt number increased,
but use "openssl speed -engine cryptodev rsa -elapsed" testing, the 
tailitos interrupt number not increased.

I found talitos/talitos.c issue "add support for public key ops (PKEU)".
Whether it means that rsa function using the hardware PKEU not implement?

Thanks for reply.

-- 
Regards
HomePage: http://www.yytek.com/