ocf-linux-users Mailing List for Open Cryptographic Framework for Linux (Page 17)
Brought to you by:
david-m
Menu
▾
▴
ocf-linux-users — Anything and everything ocf-linux related
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(12) |
Sep
(39) |
Oct
(16) |
Nov
(7) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(10) |
Feb
(1) |
Mar
(18) |
Apr
(8) |
May
(14) |
Jun
(12) |
Jul
(35) |
Aug
(11) |
Sep
(3) |
Oct
(3) |
Nov
(7) |
Dec
(2) |
| 2009 |
Jan
(20) |
Feb
(12) |
Mar
(31) |
Apr
(20) |
May
(31) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(11) |
Oct
|
Nov
(2) |
Dec
(6) |
| 2010 |
Jan
(20) |
Feb
(10) |
Mar
(16) |
Apr
|
May
(17) |
Jun
|
Jul
(2) |
Aug
(30) |
Sep
(6) |
Oct
|
Nov
|
Dec
(1) |
| 2011 |
Jan
|
Feb
(9) |
Mar
(7) |
Apr
(6) |
May
(20) |
Jun
(2) |
Jul
(13) |
Aug
(4) |
Sep
(7) |
Oct
(9) |
Nov
(5) |
Dec
(2) |
| 2012 |
Jan
(5) |
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
(7) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
(19) |
| 2013 |
Jan
(2) |
Feb
(3) |
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(8) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(2) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
|
From: David M. <Dav...@se...> - 2009-01-05 03:36:24
|
Jivin Marco lays it down ... > Hi, > > I have to use the cpus in object. I'd like to use OCF. I see a bit the > code and I don't understand a thing: is the framework compatible with > the kernel driver already inserted in mainline? I mean, in the kernel > there are the driver for those cpus but I don't see the support of OCF, > is the framework smart to use the kernel drivers instead of rewriting a > similar ones for ocf? I have this doubt because I see some driver like > talitos both in OCF and in the kernel, are they different? No, they are the same, OCF had a talitos driver first ;-) If you don't want to use the OCF version of the driver, use the kernel version and then use the OCF "cryptosoft" driver which uses the kernel crypto API (be it HW or SW to do the work). > If for example I want to use the sec engine and so the talitos driver, do I > have to enable the talitos support both in the ocf menu and in hw driver > kernel menu? Can anyone quickly explain to me the management of the > driver in ocf? The talitos driver is relatively up to date in OCF, though the kernel version gets more attention. You have two options: 1. Enable the OCF talitos driver and do not enable the kernel version 2. Enable the kernel version, and enable the OCF cryptosoft driver. Depending on your application you may better served by one of the options. Using the talitos driver through cryptosoft+OCF would not be ideal IMO, Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com |
|
From: David M. <Dav...@se...> - 2009-01-05 03:34:36
|
Jivin Marco lays it down ...
> Hi,
>
> mot a serious problem but the function kill_proc is not present anymore.
> I propose to modify the function crypto_exit in the crypto.c:
Thanks for the patch, I'll keep that around.
I knew about this problem but I haven't had to move up to 2.6.27 or later yet,
so I hadn't worked out a fix yet or done a release.
If possible, I usually try and use the latest API (ie struct pid) and
then handle old kernels by emulating the new API in compat.h. Not
always possible though :-(
On a quick check it looks like kill_pid and friends are GPL only
symbols. This will be a problem for OCF which is BSD licensed :-(
Cheers,
Davidm
> --- crypto_orig.c 2008-07-03 02:58:33.000000000 +0200
> +++ crypto.c 2008-12-23 17:27:22.000000000 +0100
> @@ -1673,6 +1673,11 @@
> {
> pid_t p;
> unsigned long d_flags;
> +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,26)
> + struct pid *cryptoproc_pid;
> + struct pid *cryptoretproc_pid;
> +#endif
> +
>
> dprintk("%s()\n", __FUNCTION__);
>
> @@ -1683,7 +1688,13 @@
> CRYPTO_DRIVER_LOCK();
> p = cryptoproc;
> cryptoproc = (pid_t) -1;
> +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,26)
> + cryptoproc_pid = find_get_pid(p);
> + if(cryptoproc_pid)
> + kill_pid(cryptoproc_pid, SIGTERM, 1);
> +#else
> kill_proc(p, SIGTERM, 1);
> +#endif
> wake_up_interruptible(&cryptoproc_wait);
> CRYPTO_DRIVER_UNLOCK();
>
> @@ -1692,7 +1703,13 @@
> CRYPTO_DRIVER_LOCK();
> p = cryptoretproc;
> cryptoretproc = (pid_t) -1;
> +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,26)
> + cryptoretproc_pid = find_get_pid(p);
> + if(cryptoretproc_pid)
> + kill_pid(cryptoretproc_pid, SIGTERM, 1);
> +#else
> kill_proc(p, SIGTERM, 1);
> +#endif
> wake_up_interruptible(&cryptoretproc_wait);
> CRYPTO_DRIVER_UNLOCK();
>
>
> Regards,
>
> Marco
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Ocf-linux-users mailing list
> Ocf...@li...
> https://lists.sourceforge.net/lists/listinfo/ocf-linux-users
>
--
David McCullough, dav...@se..., Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com
|
|
From: Marco <mar...@gm...> - 2008-12-23 17:14:59
|
Hi, I have to use the cpus in object. I'd like to use OCF. I see a bit the code and I don't understand a thing: is the framework compatible with the kernel driver already inserted in mainline? I mean, in the kernel there are the driver for those cpus but I don't see the support of OCF, is the framework smart to use the kernel drivers instead of rewriting a similar ones for ocf? I have this doubt because I see some driver like talitos both in OCF and in the kernel, are they different? If for example I want to use the sec engine and so the talitos driver, do I have to enable the talitos support both in the ocf menu and in hw driver kernel menu? Can anyone quickly explain to me the management of the driver in ocf? Thanks. Regards, Marco |
|
From: Marco <mar...@gm...> - 2008-12-23 17:12:40
|
Hi,
mot a serious problem but the function kill_proc is not present anymore.
I propose to modify the function crypto_exit in the crypto.c:
--- crypto_orig.c 2008-07-03 02:58:33.000000000 +0200
+++ crypto.c 2008-12-23 17:27:22.000000000 +0100
@@ -1673,6 +1673,11 @@
{
pid_t p;
unsigned long d_flags;
+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,26)
+ struct pid *cryptoproc_pid;
+ struct pid *cryptoretproc_pid;
+#endif
+
dprintk("%s()\n", __FUNCTION__);
@@ -1683,7 +1688,13 @@
CRYPTO_DRIVER_LOCK();
p = cryptoproc;
cryptoproc = (pid_t) -1;
+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,26)
+ cryptoproc_pid = find_get_pid(p);
+ if(cryptoproc_pid)
+ kill_pid(cryptoproc_pid, SIGTERM, 1);
+#else
kill_proc(p, SIGTERM, 1);
+#endif
wake_up_interruptible(&cryptoproc_wait);
CRYPTO_DRIVER_UNLOCK();
@@ -1692,7 +1703,13 @@
CRYPTO_DRIVER_LOCK();
p = cryptoretproc;
cryptoretproc = (pid_t) -1;
+#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,26)
+ cryptoretproc_pid = find_get_pid(p);
+ if(cryptoretproc_pid)
+ kill_pid(cryptoretproc_pid, SIGTERM, 1);
+#else
kill_proc(p, SIGTERM, 1);
+#endif
wake_up_interruptible(&cryptoretproc_wait);
CRYPTO_DRIVER_UNLOCK();
Regards,
Marco
|
|
From: David M. <Dav...@se...> - 2008-11-19 02:48:14
|
Jivin har...@cs... lays it down ... > Hi there, just to let you know, the kill_proc function has be removed from > the linux kernel in 2.6.27 (not sure which exact release it was removed > from, but pretty recently). So I presume crypto.c and random.c will have > to migrate from using the kill_proc function to the kill_proc_info > function. Thanks for the heads up, we got delayed here moving to 2.6.27 so I hadn't seen that one yet, Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com |
|
From: <har...@cs...> - 2008-11-18 17:18:38
|
Hi there, just to let you know, the kill_proc function has be removed from the linux kernel in 2.6.27 (not sure which exact release it was removed from, but pretty recently). So I presume crypto.c and random.c will have to migrate from using the kill_proc function to the kill_proc_info function. Owen |
|
From: David M. <Dav...@se...> - 2008-11-11 03:37:28
|
Jivin Nawang Chhetan lays it down ... > Hi David, > My device is ipsec driver(i.e. a consumer in Ocf jargon) > using Ocf for look aside crypto. The provider I am using is safe. Ok, that makes sense. You won't be able to just free requests that are pending in the OCF layer. There is no cancel option. Once a request has been handed to OCF you will need to wait for OCF to complete it. It could be tied up in the actual crypto driver or waiting in an OCF queue. Your driver close routine should wait for pending requests to complete before allowing the unload. Cheers, Davidm > On Mon, Nov 10, 2008 at 4:55 PM, David McCullough > <Dav...@se...> wrote: > > > > Jivin Nawang Chhetan lays it down ... > >> Hi All, > >> My device is using Ocf(i.e. offloading symmetric > >> operations), now while doing this I unload the device. But before > >> doing this I have to be sure that all offloaded operations are > >> processed Or atleast inform Ocf that there is no need to process those > >> operations. > >> I think calling crypto_freereq for all the operation is safe and > >> sufficient. Is there a better way to do this ? > > > > Is your device an OCF HW driver (ie., hifn, safe, ...) or a > > driver (like ipsec) using OCF for crypto ? > > > > Cheers, > > Davidm > > > > -- > > David McCullough, dav...@se..., Ph:+61 734352815 > > Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com > > > > > > -- > Nawang Chhetan > Software Engineer > SafeNet India. > -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com |
|
From: Nawang C. <naw...@gm...> - 2008-11-11 03:13:58
|
Hi David,
My device is ipsec driver(i.e. a consumer in Ocf jargon)
using Ocf for look aside crypto. The provider I am using is safe.
On Mon, Nov 10, 2008 at 4:55 PM, David McCullough
<Dav...@se...> wrote:
>
> Jivin Nawang Chhetan lays it down ...
>> Hi All,
>> My device is using Ocf(i.e. offloading symmetric
>> operations), now while doing this I unload the device. But before
>> doing this I have to be sure that all offloaded operations are
>> processed Or atleast inform Ocf that there is no need to process those
>> operations.
>> I think calling crypto_freereq for all the operation is safe and
>> sufficient. Is there a better way to do this ?
>
> Is your device an OCF HW driver (ie., hifn, safe, ...) or a
> driver (like ipsec) using OCF for crypto ?
>
> Cheers,
> Davidm
>
> --
> David McCullough, dav...@se..., Ph:+61 734352815
> Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com
>
--
Nawang Chhetan
Software Engineer
SafeNet India.
|
|
From: David M. <Dav...@se...> - 2008-11-10 11:25:26
|
Jivin Nawang Chhetan lays it down ... > Hi All, > My device is using Ocf(i.e. offloading symmetric > operations), now while doing this I unload the device. But before > doing this I have to be sure that all offloaded operations are > processed Or atleast inform Ocf that there is no need to process those > operations. > I think calling crypto_freereq for all the operation is safe and > sufficient. Is there a better way to do this ? Is your device an OCF HW driver (ie., hifn, safe, ...) or a driver (like ipsec) using OCF for crypto ? Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com |
|
From: Nawang C. <naw...@gm...> - 2008-11-10 06:39:55
|
Hi All,
My device is using Ocf(i.e. offloading symmetric
operations), now while doing this I unload the device. But before
doing this I have to be sure that all offloaded operations are
processed Or atleast inform Ocf that there is no need to process those
operations.
I think calling crypto_freereq for all the operation is safe and
sufficient. Is there a better way to do this ?
--
Nawang Chhetan
Software Engineer
SafeNet India.
|
|
From: Nawang C. <naw...@gm...> - 2008-11-10 05:25:30
|
Hi All,
I am sorry for late mention, I've resolved the issue. Ocf
expects/delivers complete byte string as little endian.
On Fri, Oct 17, 2008 at 12:26 PM, Nawang Chhetan
<naw...@gm...> wrote:
> On Fri, Oct 17, 2008 at 10:17 AM, David McCullough
> <Dav...@se...> wrote:
>>
>> Jivin Nawang Chhetan lays it down ...
>>> Hi David,
>>> I am trying to perform MODEXP operation through OCF. Device I
>>> am using is "safe". But I am totally lost is middle with issues like:
>>> 1. Endianess: Looking at the cryptoktest program it seems we have to pass
>>> the data to "ocf" in Little Endian format.
>>
>> Thats sounds about right.
>>
>>> 2. Word Length: While converting a byte string into Little Endian format, I
>>> am not sure what is the length of a word(4bytes or 8 bytes).
>>
>> The parameters for OCF MODEXP are byte arrays, all the code I can see
>> works on bytes.
>>
> Does that mean, if I have a (hex) byte array as BIGNUM input, I need
> to convert it into little
> endian format i.e. if BigNUM=0x1a2b3c4d 5e6f7182 than I should covert
> it to little endian format by reversing the
> complete string to: 0x82716f5e 4d3c2b1a
>
>> The BIGNUM format from openssl however is word based IIRC.
>>
>>> With lack of proper API documentation I am finding it even hard.
>>> Can you give me some pointers where I can clear my above doubts.
>>
>> You might find it easier to look at the openswan patches and how it
>> converts various formats to the OCF version and back.
>>
>> Although both cryptokeytest and openswan convert from BIGNUM to OCF
>> format. It may help to understand the BIGNUM format first. Then you
>> can see how cryptokeytest does the same op using both openssl and
>> it's own modexp,
>>
>
> BIGNUM in openssl library is a structure,
> struct bignum_st
> {
> BN_ULONG *d; /* Pointer to an array of 'BN_BITS2' bit chunks. */
> int top; /* Index of last used d +1. */
> /* The next are internal book keeping for bn_expand. */
> int dmax; /* Size of the d array. */
> int neg; /* one if the number is negative */
> int flags;
> };
>
> BN_BITS2=64,
> when bignum_to_le conversion is done in cryptoktest each BN_BITS2
> words in "bignum_st->d"( not the complete byte string) is converted to
> little endian.
>
> Is this right comprehension ?
> If so then,(to reiterate you) the modexp input data i.e mod, exp and
> base are stored as caddr_t which boils down to char * i.e. modexp data
> in byte string.
>
> Don't you think little endian conversion of entire byte string should
> have been done, instead of each word.
>
>
>> Cheers,
>> Davidm
>>
>> --
>> David McCullough, dav...@se..., Ph:+61 734352815
>> Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com
>>
>
>
>
> --
> Nawang
>
--
Nawang Chhetan
Software Engineer
SafeNet India.
|
|
From: Nawang C. <naw...@gm...> - 2008-10-17 06:56:22
|
On Fri, Oct 17, 2008 at 10:17 AM, David McCullough
<Dav...@se...> wrote:
>
> Jivin Nawang Chhetan lays it down ...
>> Hi David,
>> I am trying to perform MODEXP operation through OCF. Device I
>> am using is "safe". But I am totally lost is middle with issues like:
>> 1. Endianess: Looking at the cryptoktest program it seems we have to pass
>> the data to "ocf" in Little Endian format.
>
> Thats sounds about right.
>
>> 2. Word Length: While converting a byte string into Little Endian format, I
>> am not sure what is the length of a word(4bytes or 8 bytes).
>
> The parameters for OCF MODEXP are byte arrays, all the code I can see
> works on bytes.
>
Does that mean, if I have a (hex) byte array as BIGNUM input, I need
to convert it into little
endian format i.e. if BigNUM=0x1a2b3c4d 5e6f7182 than I should covert
it to little endian format by reversing the
complete string to: 0x82716f5e 4d3c2b1a
> The BIGNUM format from openssl however is word based IIRC.
>
>> With lack of proper API documentation I am finding it even hard.
>> Can you give me some pointers where I can clear my above doubts.
>
> You might find it easier to look at the openswan patches and how it
> converts various formats to the OCF version and back.
>
> Although both cryptokeytest and openswan convert from BIGNUM to OCF
> format. It may help to understand the BIGNUM format first. Then you
> can see how cryptokeytest does the same op using both openssl and
> it's own modexp,
>
BIGNUM in openssl library is a structure,
struct bignum_st
{
BN_ULONG *d; /* Pointer to an array of 'BN_BITS2' bit chunks. */
int top; /* Index of last used d +1. */
/* The next are internal book keeping for bn_expand. */
int dmax; /* Size of the d array. */
int neg; /* one if the number is negative */
int flags;
};
BN_BITS2=64,
when bignum_to_le conversion is done in cryptoktest each BN_BITS2
words in "bignum_st->d"( not the complete byte string) is converted to
little endian.
Is this right comprehension ?
If so then,(to reiterate you) the modexp input data i.e mod, exp and
base are stored as caddr_t which boils down to char * i.e. modexp data
in byte string.
Don't you think little endian conversion of entire byte string should
have been done, instead of each word.
> Cheers,
> Davidm
>
> --
> David McCullough, dav...@se..., Ph:+61 734352815
> Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com
>
--
Nawang
|
|
From: David M. <Dav...@se...> - 2008-10-17 05:16:16
|
Jivin Nawang Chhetan lays it down ... > Hi David, > I am trying to perform MODEXP operation through OCF. Device I > am using is "safe". But I am totally lost is middle with issues like: > 1. Endianess: Looking at the cryptoktest program it seems we have to pass > the data to "ocf" in Little Endian format. Thats sounds about right. > 2. Word Length: While converting a byte string into Little Endian format, I > am not sure what is the length of a word(4bytes or 8 bytes). The parameters for OCF MODEXP are byte arrays, all the code I can see works on bytes. The BIGNUM format from openssl however is word based IIRC. > With lack of proper API documentation I am finding it even hard. > Can you give me some pointers where I can clear my above doubts. You might find it easier to look at the openswan patches and how it converts various formats to the OCF version and back. Although both cryptokeytest and openswan convert from BIGNUM to OCF format. It may help to understand the BIGNUM format first. Then you can see how cryptokeytest does the same op using both openssl and it's own modexp, Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com |
|
From: Nawang C. <naw...@gm...> - 2008-10-17 04:11:07
|
Hi David,
I am trying to perform MODEXP operation through OCF. Device I
am using is "safe". But I am totally lost is middle with issues like:
1. Endianess: Looking at the cryptoktest program it seems we have to pass
the data to "ocf" in Little Endian format.
2. Word Length: While converting a byte string into Little Endian format, I
am not sure what is the length of a word(4bytes or 8 bytes).
With lack of proper API documentation I am finding it even hard.
Can you give me some pointers where I can clear my above doubts.
Please help.
--
Nawang.
|
|
From: Vrabete, B. <bra...@in...> - 2008-09-19 01:38:50
|
--------------------------------------------------------------------- Intel Shannon Limited Registered in Ireland Registered Office: One Spencer Dock, North Wall Quay, Dublin 1 Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. |
|
From: David M. <Dav...@se...> - 2008-09-18 22:17:48
|
Jivin Vrabete, Brad lays it down ... > Hi, > > OCF has support for session migration: if a driver is removed from the > system, OCF will automatically migrate existing sessions to the next > suitable driver. But it seems the OCF patch to openswan does not handle the > session migration return codes from OCF. In neither of ipsec_ocf_xmit and > ipsec_ocf_rcv crp->crp_etype is not checked. > > Here's my take on the problem. The problem occurs because crp->crp_sid is > allways reset to the initial ipsp->ocf_cryptoid value. When migrationg the > session, OCF replaces the existing sessions to new ones and stores the new > session id in crp->crp_sid. But since both ipsec_ocf_xmit and ipsec_ocf_rcv > are overwriting that value, OCF will try to use the old (removed) driver and > it will eventually try to dereferntiate a NULL pointer. My proposal is to > check crp->crp_etype and, when that is EAGAIN, to change ipsp->ocf_cryptoid > to the new value. (See attached patch). > > There is an additional problem: OCF relies on crp->crp_desc->CRD_INI to > properly intialize the algortihms for the newly created sessions > (crypto.c::crypto_invoke, crypto_newssession. OCF patch to Openswan does not > set all the fields in CRD_INI structure before calling crypto_dispatch. That > works fine except for session migration, when the wrong value is allocated > for cri_mlen = 12 and will make authetication algorithms fail. By setting > cri_mlen = 12 before calling crypto_dispatch in both ipsec_ocf_xmit and > ipsec_ocf_rcv, session migration will properly initialize the authetication > algortihms and the migration will work. Sorry for dragging my feet on this one. Just added your patch to the current ocf/openswan code here and it all looks good. I had to also add the code for the "batched" mode operation, but it was just a repeat of what you had already done for immediate mode. > The only thing I was not able to figure out is how to re-submit the 2 > packets that are going to get lost when the 2 Openswan relaed sessions are > migrated. A naive (or overly optimistic) approach would be to just re-call crypto_dispatch on the request. Which I did and it worked, a small cleanup in crypto.c and everyone is mostly happy :-) I can run ping over the tunnel and pull drivers out while it is running without losing any packets. Not sure I would trust it under heavy load though ;-) I have attached two patches for use with the latest ocf-linux-20080917/openswan-2.6.16 versions on ocf-linux.sourceforge.net. They have your patches and a my additions all rolled into one. Thanks, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com |
|
From: David M. <Dav...@se...> - 2008-09-17 11:53:21
|
Hi all,
A new release of the ocf-linux package is up (20080917):
http://ocf-linux.sourceforge.net/
Not a lot of fixes/updates. Some more portability for different kernels
and a new driver from Intel for their Intel QuickAssist enabled EP80579
Integrated Processor Product Line.
Have also moved the Openswan patches to the latest 2.6.16dr5 development
release. This is merely house keeping and the patch is tiny as OCF is
fully integrated into the current 2.6.16 development releases.
Cheers,
Davidm
--
David McCullough, dav...@se..., Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com
|
|
From: David M. <Dav...@se...> - 2008-08-11 12:05:24
|
Jivin Kevin Fibich lays it down ... > Hi! > > Got another strange one: > > cryptotest: line 249:ioctl(CIOCFINDDEV): No such file or directory > > i get this if i run cryptotest -d /dev/crypto -a aes -v Ok, thats the wrong use of the '-d' option. You use -d when you want to force the use of a particular device when you have multiple ocf devices present/ If I have a hifn, safenet and cryptosoft loaded I can run: cryptotest -d safe -a aes -v cryptotest -d hifn -a aes -v cryptotest -d cryptosoft -a aes -v to test each individually. > /dev/crypto iss et through udev ... maybe udev messes something up? > How can i create the /dev/crypto device by hand? You should need to, but just in case: mknod /dev/crypto c 10 70 Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com |
|
From: Kevin F. <ke...@wh...> - 2008-08-11 09:46:43
|
Hi! Got another strange one: cryptotest: line 249:ioctl(CIOCFINDDEV): No such file or directory i get this if i run cryptotest -d /dev/crypto -a aes -v /dev/crypto iss et through udev ... maybe udev messes something up? How can i create the /dev/crypto device by hand? Tanks alot for any answers! Kevin ---------------------------------------------- WHATEVER MOBILE GmbH Stormsweg 5a, 22085 Hamburg Germany Tel.: +49 (40) 88 88 08 -0 Fax: +49 (40) 88 88 08 -19 Email: ke...@wh... Web: http://www.whatevermobile.com ---------------------------------------------- Geschäftsführung: Michael Lützenkirchen Handelsregister: Amtsgericht Hamburg, HRB 86597 |
|
From: Kevin F. <ke...@wh...> - 2008-08-06 07:16:14
|
Hi!
I am loading geode_aes right after crypto_blkcipher and crypto_algapi ..
Do i understand right that geode_aes *and* cryptosoft ist needed to be loaded?
If i do i get this when running cryptotest -a aes :
Error allocating fallback algo cbc(aes)
BUG: unable to handle kernel NULL pointer dereference at 00000026
IP: [<de8daedd>] :cryptosoft:swcr_newsession+0x35c/0x5ca
*pde = 00000000
Oops: 0000 [#9]
Modules linked in: cryptosoft cryptodev(P) ocf(P) geode_aes crypto_blkcipher crypto_algapi [last unloaded: cryptosoft]
Pid: 2795, comm: cryptotest Tainted: P D (2.6.26 #5)
EIP: 0060:[<de8daedd>] EFLAGS: 00010246 CPU: 0
EIP is at swcr_newsession+0x35c/0x5ca [cryptosoft]
EAX: dd929760 EBX: fffffffe ECX: 00000004 EDX: 00000080
ESI: dd929740 EDI: 00000000 EBP: ddbf4420 ESP: dd937db0
DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process cryptotest (pid: 2795, ti=dd936000 task=dd924a20 task.ti=dd936000)
Stack: dd937ecc dd937de8 00000005 00000008 de8dc820 ddbcf26c 00000286 00000001
de8c93dd dd937ecc dd937f50 00000004 00000004 ddbcf200 00000008 03000000
00000000 03000000 dd930260 de8debcb dd45c100 c030636a bb529c30 ddbda005
Call Trace:
[<de8c93dd>] crypto_newsession+0x191/0x248 [ocf]
[<de8debcb>] cryptodev_ioctl+0x6d8/0x12ec [cryptodev]
[<c030636a>] __nla_put+0x3/0x45
[<c015403b>] do_lookup+0x53/0x145
[<c015bd22>] dput+0x21/0xb8
[<c015571e>] __link_path_walk+0x8b0/0x9e1
[<c0136fd7>] get_page_from_freelist+0x2de/0x365
[<c0141296>] find_mergeable_anon_vma+0x92/0xa1
[<c013dd6c>] handle_mm_fault+0x1b1/0x43c
[<de8df7df>] cryptodev_unlocked_ioctl+0x0/0x17 [cryptodev]
[<de8df7eb>] cryptodev_unlocked_ioctl+0xc/0x17 [cryptodev]
[<c0157486>] vfs_ioctl+0x16/0x49
[<c015769c>] do_vfs_ioctl+0x1e3/0x1f6
[<c03547ff>] do_page_fault+0x266/0x584
[<c01576db>] sys_ioctl+0x2c/0x45
[<c0102fca>] syscall_call+0x7/0xb
[<c030636a>] __nla_put+0x3/0x45
=======================
Code: f7 f9 39 44 24 0c 72 ac 83 3d 00 c8 8d de 00 74 0b 68 95 b6 8d de e8 fd b4 83 e1 5e 8b 1c 24 8b 45 00 8b 53 04 8b 73 0c 8b 58 08 <8b> 43 28 8b 40 10 83 e0 0f 83 f8 04 74 04 0f 0b eb fe 8d 42 07
EIP: [<de8daedd>] swcr_newsession+0x35c/0x5ca [cryptosoft] SS:ESP 0068:dd937db0
---[ end trace 172cd4e6a9c6f493 ]---
-----Ursprüngliche Nachricht-----
Von: David McCullough [mailto:Dav...@se...]
Gesendet: Mittwoch, 6. August 2008 01:49
An: Kevin Fibich
Cc: ocf...@li...
Betreff: Re: [Ocf-linux-users] Geode AES Engine and ocf - not working?
Jivin Kevin Fibich lays it down ...
> Hi!
>
> Got a strange error from cryptotest -a aes -v
>
> CIOCGSESSION: Invalid argument
>
> I get this, no matter if cryptosoft or geode_aes is loaded ...
> If cryptodev is not loaded it tells me that there is no /dev/crypto (which is created by udev on module load)
>
> My lsmod when freshly booted:
>
> Module Size Used by
> geode_aes 5380 0
> cryptodev 11268 0
> crypto_blkcipher 14084 1 geode_aes
> crypto_algapi 11648 2 geode_aes,crypto_blkcipher
Are you loading cryptosoft after the geode modules ?
It needs to detect aes support in the kernel crypto in order to support
it.
> *Note that ocf is compiled directly into the kernel
>
> cryptotest output with cryptodev:
>
> crid = 3000000
> cipher aes keylen 16
> CIOCGSESSION: Invalid argument
Hmm, no idea at the moment. Hopefully someone with this running is
listening :-)
Cheers,
Davidm
> Without cryptodev:
>
> cryptotest: /dev/crypto: No such file or directory
>
> openssl speed aes with cryptodev:
>
> OpenSSL 0.9.8g 19 Oct 2007
> built on: Mon Aug 4 11:48:35 CEST 2008
> options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) idea(int) blowfish(idx)
> compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
> available timing options: TIMES TIMEB HZ=100 [sysconf value]
> timing function used: times
> The 'numbers' are in 1000s of bytes per second processed.
> type 16 bytes 64 bytes 256 bytes 1024 bytes 2048 bytes
> aes-128 cbc 5227.73k 7176.36k 7990.44k 8201.90k 8227.50k
> aes-192 cbc 4687.34k 6225.54k 6809.60k 6961.83k 6980.27k
> aes-256 cbc 4260.90k 5485.61k 5930.41k 6048.09k 6062.08k
>
> without cryptodev:
>
> OpenSSL 0.9.8g 19 Oct 2007
> built on: Mon Aug 4 11:48:35 CEST 2008
> options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) idea(int) blowfish(idx)
> compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM
> available timing options: TIMES TIMEB HZ=100 [sysconf value]
> timing function used: times
> The 'numbers' are in 1000s of bytes per second processed.
> type 16 bytes 64 bytes 256 bytes 1024 bytes 2048 bytes
> aes-128 cbc 5280.08k 7228.65k 8008.62k 8230.91k 8263.68k
> aes-192 cbc 4726.69k 6244.37k 6821.89k 6982.66k 7004.84k
> aes-256 cbc 5019.08k 5731.31k 5964.29k 6029.31k 6036.82k
>
> Dmesg gives the following message:
>
> cryptodev: module license 'BSD' taints kernel.
>
> I really dont know what could be wrong ...
>
> Kernel is linux-2.6.26 patched with
>
> Aufs cvs + squashfs 3.3
>
> ocf-linux-26-20080704.patch and ocf-2.6.26.patch from this list.
>
> Openssl got the patch from ocf-linux-20080704.tar.gz
>
> I doublechecked everything i have in mind ... i really cant find any issue.
>
> -----Ursprüngliche Nachricht-----
> Von: David McCullough [mailto:Dav...@se...]
> Gesendet: Dienstag, 5. August 2008 12:54
> An: Kevin Fibich
> Cc: ocf...@li...
> Betreff: Re: [Ocf-linux-users] Geode AES Engine and ocf - not working?
>
>
> Jivin Kevin Fibich lays it down ...
> >
> >
> > Hi!
> >
> > First of all, thanks fort he fast answer ;-)
> > Is it possible that you just added the ssl aes192 patch to your answer?
> > I took a look into it and found just aes192 and arc four support patched into openssl cryptodev engine ...
>
> I'm having a bad day, AES was always in there, just recently RC4 and
> AES192 were added.
>
> Have a look at the mail list archives, several before you have got this
> working on the geode, it's just a matter of getting it all together
> correctly. If you can't find anything then send in:
>
> * output of lsmod (if you are running as modules)
> * output of "cryptotest -a aes" with cryptodev loaded and without
> cryptodev loaded.
> * output of "openssl speed -evp aes -elapsed" with cryptodev loaded
> and without.
>
> Note that openssl uses cryptodev by default if it detects it.
>
> Cheers,
> Davidm
>
> > -----Ursprüngliche Nachricht-----
> > Von: David McCullough [mailto:Dav...@se...]
> > Gesendet: Dienstag, 5. August 2008 01:46
> > An: Kevin Fibich
> > Cc: ocf...@li...
> > Betreff: Re: [Ocf-linux-users] Geode AES Engine and ocf - not working?
> >
> > Jivin Kevin Fibich lays it down ...
> > > Hi there!
> > >
> > > I am trying to use ocf-linux to get my geode aes engine up and running
> > > for vpn encryption. After days of patching an recompiling on and on i
> > > finally got everything working ... i thought.
> > >
> > > My kernel has ocf linux compiled in and geode_aes, cryptodev +
> > > cryptosoft (for testing) compiled as modules.
> > > My Openssl has the cryptodev patch and lists the cryptodev engine, but
> > > if i encrypt something with and without cryptodev the performance is the
> > > same.
> > >
> > > Maybe someone has an idea or already expirience something like this?
> > > Did i forget something?
> >
> > Yes, some patches were posted to the list IIRC, or maybe not.
> >
> > Anyway, here are the bits ot get user-space acceleration for AES.
> > You probably only need the ssl patch unless you are using cryptotest to
> > test the speed,
> >
> > Cheers,
> > Davidm
> >
> > --
> > David McCullough, dav...@se..., Ph:+61 734352815
> > Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com
> >
>
> --
> David McCullough, dav...@se..., Ph:+61 734352815
> Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com
>
--
David McCullough, dav...@se..., Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com
|
|
From: David M. <Dav...@se...> - 2008-08-05 23:48:38
|
Jivin Kevin Fibich lays it down ... > Hi! > > Got a strange error from cryptotest -a aes -v > > CIOCGSESSION: Invalid argument > > I get this, no matter if cryptosoft or geode_aes is loaded ... > If cryptodev is not loaded it tells me that there is no /dev/crypto (which is created by udev on module load) > > My lsmod when freshly booted: > > Module Size Used by > geode_aes 5380 0 > cryptodev 11268 0 > crypto_blkcipher 14084 1 geode_aes > crypto_algapi 11648 2 geode_aes,crypto_blkcipher Are you loading cryptosoft after the geode modules ? It needs to detect aes support in the kernel crypto in order to support it. > *Note that ocf is compiled directly into the kernel > > cryptotest output with cryptodev: > > crid = 3000000 > cipher aes keylen 16 > CIOCGSESSION: Invalid argument Hmm, no idea at the moment. Hopefully someone with this running is listening :-) Cheers, Davidm > Without cryptodev: > > cryptotest: /dev/crypto: No such file or directory > > openssl speed aes with cryptodev: > > OpenSSL 0.9.8g 19 Oct 2007 > built on: Mon Aug 4 11:48:35 CEST 2008 > options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) idea(int) blowfish(idx) > compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM > available timing options: TIMES TIMEB HZ=100 [sysconf value] > timing function used: times > The 'numbers' are in 1000s of bytes per second processed. > type 16 bytes 64 bytes 256 bytes 1024 bytes 2048 bytes > aes-128 cbc 5227.73k 7176.36k 7990.44k 8201.90k 8227.50k > aes-192 cbc 4687.34k 6225.54k 6809.60k 6961.83k 6980.27k > aes-256 cbc 4260.90k 5485.61k 5930.41k 6048.09k 6062.08k > > without cryptodev: > > OpenSSL 0.9.8g 19 Oct 2007 > built on: Mon Aug 4 11:48:35 CEST 2008 > options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) idea(int) blowfish(idx) > compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM > available timing options: TIMES TIMEB HZ=100 [sysconf value] > timing function used: times > The 'numbers' are in 1000s of bytes per second processed. > type 16 bytes 64 bytes 256 bytes 1024 bytes 2048 bytes > aes-128 cbc 5280.08k 7228.65k 8008.62k 8230.91k 8263.68k > aes-192 cbc 4726.69k 6244.37k 6821.89k 6982.66k 7004.84k > aes-256 cbc 5019.08k 5731.31k 5964.29k 6029.31k 6036.82k > > Dmesg gives the following message: > > cryptodev: module license 'BSD' taints kernel. > > I really dont know what could be wrong ... > > Kernel is linux-2.6.26 patched with > > Aufs cvs + squashfs 3.3 > > ocf-linux-26-20080704.patch and ocf-2.6.26.patch from this list. > > Openssl got the patch from ocf-linux-20080704.tar.gz > > I doublechecked everything i have in mind ... i really cant find any issue. > > -----Ursprüngliche Nachricht----- > Von: David McCullough [mailto:Dav...@se...] > Gesendet: Dienstag, 5. August 2008 12:54 > An: Kevin Fibich > Cc: ocf...@li... > Betreff: Re: [Ocf-linux-users] Geode AES Engine and ocf - not working? > > > Jivin Kevin Fibich lays it down ... > > > > > > Hi! > > > > First of all, thanks fort he fast answer ;-) > > Is it possible that you just added the ssl aes192 patch to your answer? > > I took a look into it and found just aes192 and arc four support patched into openssl cryptodev engine ... > > I'm having a bad day, AES was always in there, just recently RC4 and > AES192 were added. > > Have a look at the mail list archives, several before you have got this > working on the geode, it's just a matter of getting it all together > correctly. If you can't find anything then send in: > > * output of lsmod (if you are running as modules) > * output of "cryptotest -a aes" with cryptodev loaded and without > cryptodev loaded. > * output of "openssl speed -evp aes -elapsed" with cryptodev loaded > and without. > > Note that openssl uses cryptodev by default if it detects it. > > Cheers, > Davidm > > > -----Ursprüngliche Nachricht----- > > Von: David McCullough [mailto:Dav...@se...] > > Gesendet: Dienstag, 5. August 2008 01:46 > > An: Kevin Fibich > > Cc: ocf...@li... > > Betreff: Re: [Ocf-linux-users] Geode AES Engine and ocf - not working? > > > > Jivin Kevin Fibich lays it down ... > > > Hi there! > > > > > > I am trying to use ocf-linux to get my geode aes engine up and running > > > for vpn encryption. After days of patching an recompiling on and on i > > > finally got everything working ... i thought. > > > > > > My kernel has ocf linux compiled in and geode_aes, cryptodev + > > > cryptosoft (for testing) compiled as modules. > > > My Openssl has the cryptodev patch and lists the cryptodev engine, but > > > if i encrypt something with and without cryptodev the performance is the > > > same. > > > > > > Maybe someone has an idea or already expirience something like this? > > > Did i forget something? > > > > Yes, some patches were posted to the list IIRC, or maybe not. > > > > Anyway, here are the bits ot get user-space acceleration for AES. > > You probably only need the ssl patch unless you are using cryptotest to > > test the speed, > > > > Cheers, > > Davidm > > > > -- > > David McCullough, dav...@se..., Ph:+61 734352815 > > Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com > > > > -- > David McCullough, dav...@se..., Ph:+61 734352815 > Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com > -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com |
|
From: Kevin F. <ke...@wh...> - 2008-08-05 12:02:53
|
Hi! Got a strange error from cryptotest -a aes -v CIOCGSESSION: Invalid argument I get this, no matter if cryptosoft or geode_aes is loaded ... If cryptodev is not loaded it tells me that there is no /dev/crypto (which is created by udev on module load) My lsmod when freshly booted: Module Size Used by geode_aes 5380 0 cryptodev 11268 0 crypto_blkcipher 14084 1 geode_aes crypto_algapi 11648 2 geode_aes,crypto_blkcipher *Note that ocf is compiled directly into the kernel cryptotest output with cryptodev: crid = 3000000 cipher aes keylen 16 CIOCGSESSION: Invalid argument Without cryptodev: cryptotest: /dev/crypto: No such file or directory openssl speed aes with cryptodev: OpenSSL 0.9.8g 19 Oct 2007 built on: Mon Aug 4 11:48:35 CEST 2008 options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) idea(int) blowfish(idx) compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 2048 bytes aes-128 cbc 5227.73k 7176.36k 7990.44k 8201.90k 8227.50k aes-192 cbc 4687.34k 6225.54k 6809.60k 6961.83k 6980.27k aes-256 cbc 4260.90k 5485.61k 5930.41k 6048.09k 6062.08k without cryptodev: OpenSSL 0.9.8g 19 Oct 2007 built on: Mon Aug 4 11:48:35 CEST 2008 options:bn(64,32) md2(int) rc4(idx,int) des(ptr,risc1,16,long) aes(partial) idea(int) blowfish(idx) compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 2048 bytes aes-128 cbc 5280.08k 7228.65k 8008.62k 8230.91k 8263.68k aes-192 cbc 4726.69k 6244.37k 6821.89k 6982.66k 7004.84k aes-256 cbc 5019.08k 5731.31k 5964.29k 6029.31k 6036.82k Dmesg gives the following message: cryptodev: module license 'BSD' taints kernel. I really dont know what could be wrong ... Kernel is linux-2.6.26 patched with Aufs cvs + squashfs 3.3 ocf-linux-26-20080704.patch and ocf-2.6.26.patch from this list. Openssl got the patch from ocf-linux-20080704.tar.gz I doublechecked everything i have in mind ... i really cant find any issue. -----Ursprüngliche Nachricht----- Von: David McCullough [mailto:Dav...@se...] Gesendet: Dienstag, 5. August 2008 12:54 An: Kevin Fibich Cc: ocf...@li... Betreff: Re: [Ocf-linux-users] Geode AES Engine and ocf - not working? Jivin Kevin Fibich lays it down ... > > > Hi! > > First of all, thanks fort he fast answer ;-) > Is it possible that you just added the ssl aes192 patch to your answer? > I took a look into it and found just aes192 and arc four support patched into openssl cryptodev engine ... I'm having a bad day, AES was always in there, just recently RC4 and AES192 were added. Have a look at the mail list archives, several before you have got this working on the geode, it's just a matter of getting it all together correctly. If you can't find anything then send in: * output of lsmod (if you are running as modules) * output of "cryptotest -a aes" with cryptodev loaded and without cryptodev loaded. * output of "openssl speed -evp aes -elapsed" with cryptodev loaded and without. Note that openssl uses cryptodev by default if it detects it. Cheers, Davidm > -----Ursprüngliche Nachricht----- > Von: David McCullough [mailto:Dav...@se...] > Gesendet: Dienstag, 5. August 2008 01:46 > An: Kevin Fibich > Cc: ocf...@li... > Betreff: Re: [Ocf-linux-users] Geode AES Engine and ocf - not working? > > Jivin Kevin Fibich lays it down ... > > Hi there! > > > > I am trying to use ocf-linux to get my geode aes engine up and running > > for vpn encryption. After days of patching an recompiling on and on i > > finally got everything working ... i thought. > > > > My kernel has ocf linux compiled in and geode_aes, cryptodev + > > cryptosoft (for testing) compiled as modules. > > My Openssl has the cryptodev patch and lists the cryptodev engine, but > > if i encrypt something with and without cryptodev the performance is the > > same. > > > > Maybe someone has an idea or already expirience something like this? > > Did i forget something? > > Yes, some patches were posted to the list IIRC, or maybe not. > > Anyway, here are the bits ot get user-space acceleration for AES. > You probably only need the ssl patch unless you are using cryptotest to > test the speed, > > Cheers, > Davidm > > -- > David McCullough, dav...@se..., Ph:+61 734352815 > Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com > -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com |
|
From: David M. <Dav...@se...> - 2008-08-05 10:53:58
|
Jivin Kevin Fibich lays it down ... > > > Hi! > > First of all, thanks fort he fast answer ;-) > Is it possible that you just added the ssl aes192 patch to your answer? > I took a look into it and found just aes192 and arc four support patched into openssl cryptodev engine ... I'm having a bad day, AES was always in there, just recently RC4 and AES192 were added. Have a look at the mail list archives, several before you have got this working on the geode, it's just a matter of getting it all together correctly. If you can't find anything then send in: * output of lsmod (if you are running as modules) * output of "cryptotest -a aes" with cryptodev loaded and without cryptodev loaded. * output of "openssl speed -evp aes -elapsed" with cryptodev loaded and without. Note that openssl uses cryptodev by default if it detects it. Cheers, Davidm > -----Ursprüngliche Nachricht----- > Von: David McCullough [mailto:Dav...@se...] > Gesendet: Dienstag, 5. August 2008 01:46 > An: Kevin Fibich > Cc: ocf...@li... > Betreff: Re: [Ocf-linux-users] Geode AES Engine and ocf - not working? > > Jivin Kevin Fibich lays it down ... > > Hi there! > > > > I am trying to use ocf-linux to get my geode aes engine up and running > > for vpn encryption. After days of patching an recompiling on and on i > > finally got everything working ... i thought. > > > > My kernel has ocf linux compiled in and geode_aes, cryptodev + > > cryptosoft (for testing) compiled as modules. > > My Openssl has the cryptodev patch and lists the cryptodev engine, but > > if i encrypt something with and without cryptodev the performance is the > > same. > > > > Maybe someone has an idea or already expirience something like this? > > Did i forget something? > > Yes, some patches were posted to the list IIRC, or maybe not. > > Anyway, here are the bits ot get user-space acceleration for AES. > You probably only need the ssl patch unless you are using cryptotest to > test the speed, > > Cheers, > Davidm > > -- > David McCullough, dav...@se..., Ph:+61 734352815 > Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com > -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com |
|
From: Kevin F. <ke...@wh...> - 2008-08-05 08:40:34
|
Hi! First of all, thanks fort he fast answer ;-) Is it possible that you just added the ssl aes192 patch to your answer? I took a look into it and found just aes192 and arc four support patched into openssl cryptodev engine ... Best regards Kevin -----Ursprüngliche Nachricht----- Von: David McCullough [mailto:Dav...@se...] Gesendet: Dienstag, 5. August 2008 01:46 An: Kevin Fibich Cc: ocf...@li... Betreff: Re: [Ocf-linux-users] Geode AES Engine and ocf - not working? Jivin Kevin Fibich lays it down ... > Hi there! > > I am trying to use ocf-linux to get my geode aes engine up and running > for vpn encryption. After days of patching an recompiling on and on i > finally got everything working ... i thought. > > My kernel has ocf linux compiled in and geode_aes, cryptodev + > cryptosoft (for testing) compiled as modules. > My Openssl has the cryptodev patch and lists the cryptodev engine, but > if i encrypt something with and without cryptodev the performance is the > same. > > Maybe someone has an idea or already expirience something like this? > Did i forget something? Yes, some patches were posted to the list IIRC, or maybe not. Anyway, here are the bits ot get user-space acceleration for AES. You probably only need the ssl patch unless you are using cryptotest to test the speed, Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com |
|
From: David M. <Dav...@se...> - 2008-08-04 23:46:16
|
Jivin Kevin Fibich lays it down ... > Hi there! > > I am trying to use ocf-linux to get my geode aes engine up and running > for vpn encryption. After days of patching an recompiling on and on i > finally got everything working ... i thought. > > My kernel has ocf linux compiled in and geode_aes, cryptodev + > cryptosoft (for testing) compiled as modules. > My Openssl has the cryptodev patch and lists the cryptodev engine, but > if i encrypt something with and without cryptodev the performance is the > same. > > Maybe someone has an idea or already expirience something like this? > Did i forget something? Yes, some patches were posted to the list IIRC, or maybe not. Anyway, here are the bits ot get user-space acceleration for AES. You probably only need the ssl patch unless you are using cryptotest to test the speed, Cheers, Davidm -- David McCullough, dav...@se..., Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com |
4 messages has been excluded from this view by a project administrator.
