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

Re: [Ocf-linux-users] Load balancing in OCF

[Vrabete, B. <bra...@in...>]

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

Re: [Ocf-linux-users] Load balancing in OCF

[David M. <Dav...@se...>]

Jivin Vrabete, Brad lays it down ...
> Hi Dave,
>  
> Is load balancing supported in the Linux version of OCF? The FreeBSD
> documentation states that it is supported there.

For how long ?

I checked just recently,  the FreeBSD code looked like it hadn't changed from
the last OCF release.

There is a form of "too busy try the next device" thing.  Not exactly load
balancing IMO.

Do you have a pointer to the doc ?  If it looks different I will double
check te hOCF code base is up to date,

Cheers,
Davidm

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

[Ocf-linux-users] Load balancing in OCF

[Vrabete, B. <bra...@in...>]

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

Re: [Ocf-linux-users] AES hardware accelerator in OpenSSL with OCF

[David M. <Dav...@se...>]

Jivin Palacios, Hector lays it down ...
> > -----Original Message-----
> > From: Hector Palacios [mailto:hec...@di...]
> > Sent: Friday, January 30, 2009 12:16 PM
> > To: David McCullough
> > Cc: ocf...@li...
> > Subject: Re: [Ocf-linux-users] AES hardware accelerator in OpenSSL with
> > OCF
> > 
> > I don't see many differences between the way aes_generic loads the
> > algorithm and the way my driver does it. The main difference is that
> > aes_generic cra_flags is CRYPTO_ALG_TYPE_CIPHER while my driver is
> > CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC.
> > In other words, my driver uses .cra_u.ablkcipher to define the crypto
> > functions while the aes_generic uses .cra_u.cipher. Do you know if this
> > makes any difference to OCF layer?
> 
> Hello,
> 
> I have solved the problem to make OCF work with my hw acceleration driver.
> My driver is developed as an async block cipher (ablkcipher) and OCF did not have support but for blockciphers (sync).
> I have done some really "quick & dirty" hacks to include support for ablkciphers in cryptosoft.c module.
> They are really "dirty" because I don't know the internals of OCF, but they do the magic of linking my driver to OpenSSL which is what I wanted.
> I attach here the patch I did to cryptosoft.c just in case anybody finds it interesting.

Great,  thanks for that.  I'll see if I can merge that in when I get
some cycles,

Cheers,
Davidm

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

Re: [Ocf-linux-users] AES hardware accelerator in OpenSSL with OCF

[Palacios, H. <Hec...@di...>]

> -----Original Message-----
> From: Hector Palacios [mailto:hec...@di...]
> Sent: Friday, January 30, 2009 12:16 PM
> To: David McCullough
> Cc: ocf...@li...
> Subject: Re: [Ocf-linux-users] AES hardware accelerator in OpenSSL with
> OCF
> 
> I don't see many differences between the way aes_generic loads the
> algorithm and the way my driver does it. The main difference is that
> aes_generic cra_flags is CRYPTO_ALG_TYPE_CIPHER while my driver is
> CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC.
> In other words, my driver uses .cra_u.ablkcipher to define the crypto
> functions while the aes_generic uses .cra_u.cipher. Do you know if this
> makes any difference to OCF layer?

Hello,

I have solved the problem to make OCF work with my hw acceleration driver.
My driver is developed as an async block cipher (ablkcipher) and OCF did not have support but for blockciphers (sync).
I have done some really "quick & dirty" hacks to include support for ablkciphers in cryptosoft.c module.
They are really "dirty" because I don't know the internals of OCF, but they do the magic of linking my driver to OpenSSL which is what I wanted.
I attach here the patch I did to cryptosoft.c just in case anybody finds it interesting.

Regards,
--
Héctor Palacios

Re: [Ocf-linux-users] crypto_newsession / crypto_freesession

[David M. <Dav...@se...>]

Jivin Pirasenna Thiyagarajan lays it down ...
> Hi David:
> I got an email saying the patch may not have been posted.   But, the website
> shows the patch has been posted to the list.
> Did you see my earlier email with the patch?

Yes,  I got the patch

> Any comments?

Sorry,  just haven't had a chance yet to look at it.  Will try and get
there today,

Cheers,
Davidm


> On Fri, Jan 30, 2009 at 12:01 AM, Pirasenna Thiyagarajan <
> pir...@gm...> wrote:
> 
> > The crypto hardware can access the entire host memory subsystem.  The
> > session and outstanding operations are maintained by the driver.  Due to
> > many families of crypto engines that the driver supports, the notification
> > of completion operation is abstracted by the driver and translated to
> > operation instance that is complete.  The driver also provides a queue
> > mechanism very similar to the OCF to enqueue operations, which the driver
> > submits to the crypto hardware asynchronously.
> > I've answered your specific questions below.  I've also attached a patch on
> > top of September 17th, 2008 sources.  It has the changes that enables driver
> > its own 64-bit sid and uses the next 64-bit to put all the driver related
> > parameters.  I tested the cryptosoft with this driver and it worked without
> > any issues.  More importantly, the patch will give you a general idea of my
> > suggestions.
> >
> >
> > Thanks,
> > Piras
> >
> >
> > On Thu, Jan 29, 2009 at 8:00 PM, David McCullough <
> > Dav...@se...> wrote:
> >
> >>
> >> Jivin Pirasenna Thiyagarajan lays it down ...
> >> > David:
> >> > Here is what I'm trying achieve.  In my driver I'm adding an abstract
> >> layer
> >> > to interface with OCF.  There is an opaque structure that hosts the
> >> crypto
> >> > fields, which in OCF-speak is the session.  So, in the kernel space,
> >> instead
> >> > of creating a table to maintain the mapping between session id and the
> >> > appropriate crypto operation, I'm trying to return the address.
> >> >
> >> > I explored your idea of using offset address as session id.  That would
> >> work
> >> > in Linux 32-bit mode since the addressable space in kernel is less than
> >> a
> >> > gigabyte.  Whereas, in 64-bit mode, I cannot make an assumption of
> >> having
> >> > memory obtained from the OS to be within a 32-bit offset.
> >>
> >> Ok,  then it is not "on crypto chip" memory but host system memory
> >> obtained through one of the kernel allocator functions.
> >>
> >> It sounds like the HW doesn't have a classic "divided up" ring buffer but
> >> just chains arbitary descriptors together  ?
> >>
> >> > I'm expecting to use the session id as an opaque handler to the OCF
> >> > interface and the driver may use it to dereference the operation however
> >> it
> >> > may see fit.
> >> >
> >> > In a multi-processor scenario, it would eliminate lock to access the
> >> session
> >> > table structure safely.
> >>
> >> Are you doing this to make finding the "session" info easy,  and
> >> everything you need to know about a session is contained within the memory
> >> pointed to by that address ?
> >>
> > Yes.  The session id is a sort of crypto handle I'll de-reference and use
> > it to extract keys and other details.
> >
> >
> >>
> >>
> >> That I can understand.  Especially if you want unlimited sessions.
> >> That way when I ask to do something on session N,  you just dereference N
> >> inside your driver to find out context for that session.
> >>
> >> Do you have infomation that is not stored in the memory at the "address" ?
> >> How does the HW find out about a new session ?  Do you just link it into
> >> a list of sessions ?  Does the HW have a session limit ?
> >
> > The driver supports different engines of the same family and the limits
> > vary.  The driver will determine if the engine cannot take any more requests
> > and respond with EAGAIN.  From looking at the OCF code, I might have to
> > return ERESTART, which is fine.
> >
> >>
> >>
> >> If the address is only used by the driver,  it sounds reasonable, if you
> >> want
> >> to use the address outside of your driver for anything else then it sounds
> >> quite risky :-)
> >
> > No.  The id is kept opaque in all other contexts.
> >
> >
> > Thanks,
> > Piras
> >
> >
> >
> >>
> >> > Any comments is definitely welcome.
> >>
> >> Looking at an OCF driver (forget cryptodev, thats different),  newsession
> >> returns a 32 bit session id,  but freesession takes a 64 bit id,  that
> >> doesn't make much sense in any way :-)
> >>
> >> I just checked the current FreeBSD source and the API hasn't changed in
> >> that respect.  I wouldn't like to deviate from that too much, but
> >> I can't say I am completely tied to it either.
> >>
> >> Having to recompile doesn't bother me much either as this is a source
> >> only thing anyway.
> >>
> >> Cheers,
> >> Davidm
> >>
> >> > On Thu, Jan 29, 2009 at 4:39 PM, David McCullough <
> >> > Dav...@se...> wrote:
> >> >
> >> > >
> >> > > Jivin Pirasenna Thiyagarajan lays it down ...
> >> > > > Here is one option, that does not require interface change and
> >> requires
> >> > > no
> >> > > > modification in ocf-compat.h.  It would require recompiling existing
> >> > > drivers
> >> > > > though.
> >> > > >
> >> > > > Since sid is always passed as u_int64_t * for create_newsession,
> >> > > internally
> >> > > > in cryptop structure crp_sid may be setup as a 2 entry 64 byte
> >> array. The
> >> > > > nid defintion in crypto.c:1017 may be defined the same way.  The
> >> first
> >> > > > 64-bytes are left for driver to put whatever value they want.  The
> >> second
> >> > > > 64-byte is left for OCF to store flags and anything else that is
> >> required
> >> > > > for administration.
> >> > >
> >> > > Ok,  I think I am missing something here.  Are you trying to pass the
> >> > > address back to userspace by any chance ?
> >> >
> >> >
> >> > >
> >> > > > crypto_newsession in crytpodev.c would be modified to store the
> >> flags in
> >> > > the
> >> > > > second 64-byte field.
> >> > > > The macros CRYPTO_SESID2HID, CRYPTO_SESID2CAPS and CRYPTO_SESID2LID
> >> will
> >> > > be
> >> > > > modified to harvest the information from correct index.
> >> > > > crypto_freesession sends only the first 64-byte data as the argument
> >> > > value
> >> > > > to the function.  So, driver can use it as it is.
> >> > > >
> >> > > > Let me know if you think there are any loose ends or
> >> incompatibilities.
> >> > >  I
> >> > > > can send you a patch with these changes after testing it out with
> >> > > software
> >> > > > driver using cryptotest.
> >> > >
> >> > > IMO it is sounding a little messy at this point,  but that may be
> >> > > because I don't quite understand what you are trying to do and how it
> >> > > will be used.
> >> > >
> >> > > Did you consider returning an offset rather than a full pointer  as I
> >> > > suggested below ?  Is it even possible in your context ?
> >> > >
> >> > > If you think the patch is simple enough to do perhaps it will help me
> >> > > understand what you need better ;-)
> >> > >
> >> > > Cheers,
> >> > > Davidm
> >> > >
> >> > >
> >> > > > On Wed, Jan 28, 2009 at 10:03 PM, David McCullough <
> >> > > > Dav...@se...> wrote:
> >> > > >
> >> > > > >
> >> > > > > Jivin Pirasenna Thiyagarajan lays it down ...
> >> > > > > > I'm writing a driver and attempting it to make it OCF
> >> compatible.  I
> >> > > was
> >> > > > > > intending on passing the virtual memory address I allocate for
> >> driver
> >> > > > > data
> >> > > > > > structures for a given operation as the session id.  To avoid
> >> > > 32/64bit
> >> > > > > > issues, having the crypto_newsession pass in u_int64_t * would
> >> make
> >> > > it
> >> > > > > > convenient.  Otherwise, I'll have to keep a mapping table and
> >> look up
> >> > > > > > routines appropriately (unnecessary computation cycles).
> >> > > > >
> >> > > > > Hmm,  sounds fair,  only I think that crypto.c messes with the 64
> >> bit
> >> > > > > version a fair bit before handing it to the driver.
> >> > > > >
> >> > > > > Check crypto.c:crypto_newsession to see this in action.
> >> > > > >
> >> > > > > The 64bit version has the driver id + the drivers session id and
> >> the
> >> > > > > drivers capability flags all merged into it.
> >> > > > >
> >> > > > > It's probably unlikely your card with have more than 4GB of
> >> memory, or
> >> > > > > maybe it does.  You could just return the "offset" into it's
> >> memory for
> >> > > > > that session.  Saves a lookup table (baseaddr + offset = address).
> >> > > > >
> >> > > > > > From the looks of it, it seems just like an interface definition
> >> > > issue,
> >> > > > > > since as I pointed out, from within the ioctl, it does use
> >> u_int64_t
> >> > > > > > internally.
> >> > > > >
> >> > > > > Unfortunately I think it's not that simple, happy to consider
> >> something
> >> > > > > though if you have ideas.
> >> > > > >
> >> > > > > Are you planning to do a FreeBSD driver as well ?  If so it
> >> wouldn't
> >> > > hurt
> >> > > > > to
> >> > > > > check if it's still the same.  Otherwise I'll get around to
> >> checking in
> >> > > > > time ;-)
> >> > > > >
> >> > > > > Cheers,
> >> > > > > Davidm
> >> > > > >
> >> > > > >
> >> > > > > > On Wed, Jan 28, 2009 at 3:58 PM, David McCullough <
> >> > > > > > Dav...@se...> wrote:
> >> > > > > >
> >> > > > > > >
> >> > > > > > > Jivin Pirasenna Thiyagarajan lays it down ...
> >> > > > > > > > I've used OCF patch and attempting to use the cryptodev
> >> > > interface.
> >> > > > >  In
> >> > > > > > > > ocf-compat.h, I see crypto_newsession's session ID is passed
> >> in
> >> > > as a
> >> > > > > > > > u_int32_t *, whereas, the crypto_freesession takes the
> >> session id
> >> > > as
> >> > > > > > > > u_int64_t.  It seems like this is in error.  Looks like sid
> >> data
> >> > > type
> >> > > > > > > should
> >> > > > > > > > be u_int64_t *sidp.  In cryptodev.c where it is used, the
> >> sid is
> >> > > > > defined
> >> > > > > > > as
> >> > > > > > > > u_int64_t in cryptodev_ioctl.
> >> > > > > > >
> >> > > > > > > I had to look twice at that too now that you point it out.
> >> > > > > > >
> >> > > > > > > The trick is that device_method_t structure and resulting
> >> > > > > > > CRYPTODEV_NEWSESSION and cryptodev_newsession used for it are
> >> > > > > > > part of the interface for OCF drivers.  This is how OCF
> >> > > communicates
> >> > > > > > > with it's crypto drivers (ie., safe, hifn7751, cryptosoft
> >> etc).
> >> > > > > > >
> >> > > > > > > cryptodev,  the user interface driver,  doesn't talk to the
> >> crypto
> >> > > > > > > drivers,  it uses the OCF API's:
> >> > > > > > >
> >> > > > > > >        crypto_newsession
> >> > > > > > >        crypto_freesession
> >> > > > > > >
> >> > > > > > > and they are both u_int64_t.
> >> > > > > > >
> >> > > > > > > Are you having a problem with cryptodev or did you just notice
> >> this
> >> > > > > oddity
> >> > > > > > > in the code ?
> >> > > > > > >
> >> > > > > > > I admit the naming is confusing,  but we inherited that with
> >> that
> >> > > last
> >> > > > > > > round of BSD updates.  Unless you are writing a driver,
> >>  ignore the
> >> > > > > section
> >> > > > > > > at the top of ocf-compat.h,  in fact,  ignore as much of
> >> > > ocf-compat.h
> >> > > > > > > as you can every chance you get :-)  It's where we hide the
> >> older
> >> > > OS
> >> > > > > > > support and some BSD compat things to try and keep the driver
> >> > > source as
> >> > > > > > > close to the original as practical.
> >> > > > > > >
> >> > > > > > > Cheers,
> >> > > > > > > Davidm
> >> > > > > > >
> >> > > > > > > --
> >> > > > > > > David McCullough,  dav...@se...,
> >> Ph:+61
> >> > > > > > > 734352815
> >> > > > > > > Secure Computing - SnapGear  http://www.uCdot.org
> >> > > > > > > http://www.snapgear.com
> >> > > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > --
> >> > > > > > Online Gallery: http://www.deptons.com
> >> > > > > > You comments and ratings are very welcome!!
> >> > > > >
> >> > > > > --
> >> > > > > David McCullough,  dav...@se...,   Ph:+61
> >> > > > > 734352815
> >> > > > > Secure Computing - SnapGear  http://www.uCdot.org
> >> > > > > http://www.snapgear.com
> >> > > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Online Gallery: http://www.deptons.com
> >> > > > You comments and ratings are very welcome!!
> >> > >
> >> > > --
> >> > > David McCullough,  dav...@se...,   Ph:+61
> >> > > 734352815
> >> > > Secure Computing - SnapGear  http://www.uCdot.org
> >> > > http://www.snapgear.com
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Online Gallery: http://www.deptons.com
> >> > You comments and ratings are very welcome!!
> >>
> >> --
> >> David McCullough,  dav...@se...,   Ph:+61
> >> 734352815
> >> Secure Computing - SnapGear  http://www.uCdot.org
> >> http://www.snapgear.com
> >>
> >
> >
> >
> > --
> > Online Gallery: http://www.deptons.com
> > You comments and ratings are very welcome!!
> >
> 
> 
> 
> -- 
> Online Gallery: http://www.deptons.com
> You comments and ratings are very welcome!!

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

Re: [Ocf-linux-users] crypto_newsession / crypto_freesession

[Pirasenna T. <pir...@gm...>]

Hi David:
I got an email saying the patch may not have been posted.   But, the website
shows the patch has been posted to the list.
Did you see my earlier email with the patch?
Any comments?

Thanks,
Piras

On Fri, Jan 30, 2009 at 12:01 AM, Pirasenna Thiyagarajan <
pir...@gm...> wrote:

> The crypto hardware can access the entire host memory subsystem.  The
> session and outstanding operations are maintained by the driver.  Due to
> many families of crypto engines that the driver supports, the notification
> of completion operation is abstracted by the driver and translated to
> operation instance that is complete.  The driver also provides a queue
> mechanism very similar to the OCF to enqueue operations, which the driver
> submits to the crypto hardware asynchronously.
> I've answered your specific questions below.  I've also attached a patch on
> top of September 17th, 2008 sources.  It has the changes that enables driver
> its own 64-bit sid and uses the next 64-bit to put all the driver related
> parameters.  I tested the cryptosoft with this driver and it worked without
> any issues.  More importantly, the patch will give you a general idea of my
> suggestions.
>
>
> Thanks,
> Piras
>
>
> On Thu, Jan 29, 2009 at 8:00 PM, David McCullough <
> Dav...@se...> wrote:
>
>>
>> Jivin Pirasenna Thiyagarajan lays it down ...
>> > David:
>> > Here is what I'm trying achieve.  In my driver I'm adding an abstract
>> layer
>> > to interface with OCF.  There is an opaque structure that hosts the
>> crypto
>> > fields, which in OCF-speak is the session.  So, in the kernel space,
>> instead
>> > of creating a table to maintain the mapping between session id and the
>> > appropriate crypto operation, I'm trying to return the address.
>> >
>> > I explored your idea of using offset address as session id.  That would
>> work
>> > in Linux 32-bit mode since the addressable space in kernel is less than
>> a
>> > gigabyte.  Whereas, in 64-bit mode, I cannot make an assumption of
>> having
>> > memory obtained from the OS to be within a 32-bit offset.
>>
>> Ok,  then it is not "on crypto chip" memory but host system memory
>> obtained through one of the kernel allocator functions.
>>
>> It sounds like the HW doesn't have a classic "divided up" ring buffer but
>> just chains arbitary descriptors together  ?
>>
>> > I'm expecting to use the session id as an opaque handler to the OCF
>> > interface and the driver may use it to dereference the operation however
>> it
>> > may see fit.
>> >
>> > In a multi-processor scenario, it would eliminate lock to access the
>> session
>> > table structure safely.
>>
>> Are you doing this to make finding the "session" info easy,  and
>> everything you need to know about a session is contained within the memory
>> pointed to by that address ?
>>
> Yes.  The session id is a sort of crypto handle I'll de-reference and use
> it to extract keys and other details.
>
>
>>
>>
>> That I can understand.  Especially if you want unlimited sessions.
>> That way when I ask to do something on session N,  you just dereference N
>> inside your driver to find out context for that session.
>>
>> Do you have infomation that is not stored in the memory at the "address" ?
>> How does the HW find out about a new session ?  Do you just link it into
>> a list of sessions ?  Does the HW have a session limit ?
>
> The driver supports different engines of the same family and the limits
> vary.  The driver will determine if the engine cannot take any more requests
> and respond with EAGAIN.  From looking at the OCF code, I might have to
> return ERESTART, which is fine.
>
>>
>>
>> If the address is only used by the driver,  it sounds reasonable, if you
>> want
>> to use the address outside of your driver for anything else then it sounds
>> quite risky :-)
>
> No.  The id is kept opaque in all other contexts.
>
>
> Thanks,
> Piras
>
>
>
>>
>> > Any comments is definitely welcome.
>>
>> Looking at an OCF driver (forget cryptodev, thats different),  newsession
>> returns a 32 bit session id,  but freesession takes a 64 bit id,  that
>> doesn't make much sense in any way :-)
>>
>> I just checked the current FreeBSD source and the API hasn't changed in
>> that respect.  I wouldn't like to deviate from that too much, but
>> I can't say I am completely tied to it either.
>>
>> Having to recompile doesn't bother me much either as this is a source
>> only thing anyway.
>>
>> Cheers,
>> Davidm
>>
>> > On Thu, Jan 29, 2009 at 4:39 PM, David McCullough <
>> > Dav...@se...> wrote:
>> >
>> > >
>> > > Jivin Pirasenna Thiyagarajan lays it down ...
>> > > > Here is one option, that does not require interface change and
>> requires
>> > > no
>> > > > modification in ocf-compat.h.  It would require recompiling existing
>> > > drivers
>> > > > though.
>> > > >
>> > > > Since sid is always passed as u_int64_t * for create_newsession,
>> > > internally
>> > > > in cryptop structure crp_sid may be setup as a 2 entry 64 byte
>> array. The
>> > > > nid defintion in crypto.c:1017 may be defined the same way.  The
>> first
>> > > > 64-bytes are left for driver to put whatever value they want.  The
>> second
>> > > > 64-byte is left for OCF to store flags and anything else that is
>> required
>> > > > for administration.
>> > >
>> > > Ok,  I think I am missing something here.  Are you trying to pass the
>> > > address back to userspace by any chance ?
>> >
>> >
>> > >
>> > > > crypto_newsession in crytpodev.c would be modified to store the
>> flags in
>> > > the
>> > > > second 64-byte field.
>> > > > The macros CRYPTO_SESID2HID, CRYPTO_SESID2CAPS and CRYPTO_SESID2LID
>> will
>> > > be
>> > > > modified to harvest the information from correct index.
>> > > > crypto_freesession sends only the first 64-byte data as the argument
>> > > value
>> > > > to the function.  So, driver can use it as it is.
>> > > >
>> > > > Let me know if you think there are any loose ends or
>> incompatibilities.
>> > >  I
>> > > > can send you a patch with these changes after testing it out with
>> > > software
>> > > > driver using cryptotest.
>> > >
>> > > IMO it is sounding a little messy at this point,  but that may be
>> > > because I don't quite understand what you are trying to do and how it
>> > > will be used.
>> > >
>> > > Did you consider returning an offset rather than a full pointer  as I
>> > > suggested below ?  Is it even possible in your context ?
>> > >
>> > > If you think the patch is simple enough to do perhaps it will help me
>> > > understand what you need better ;-)
>> > >
>> > > Cheers,
>> > > Davidm
>> > >
>> > >
>> > > > On Wed, Jan 28, 2009 at 10:03 PM, David McCullough <
>> > > > Dav...@se...> wrote:
>> > > >
>> > > > >
>> > > > > Jivin Pirasenna Thiyagarajan lays it down ...
>> > > > > > I'm writing a driver and attempting it to make it OCF
>> compatible.  I
>> > > was
>> > > > > > intending on passing the virtual memory address I allocate for
>> driver
>> > > > > data
>> > > > > > structures for a given operation as the session id.  To avoid
>> > > 32/64bit
>> > > > > > issues, having the crypto_newsession pass in u_int64_t * would
>> make
>> > > it
>> > > > > > convenient.  Otherwise, I'll have to keep a mapping table and
>> look up
>> > > > > > routines appropriately (unnecessary computation cycles).
>> > > > >
>> > > > > Hmm,  sounds fair,  only I think that crypto.c messes with the 64
>> bit
>> > > > > version a fair bit before handing it to the driver.
>> > > > >
>> > > > > Check crypto.c:crypto_newsession to see this in action.
>> > > > >
>> > > > > The 64bit version has the driver id + the drivers session id and
>> the
>> > > > > drivers capability flags all merged into it.
>> > > > >
>> > > > > It's probably unlikely your card with have more than 4GB of
>> memory, or
>> > > > > maybe it does.  You could just return the "offset" into it's
>> memory for
>> > > > > that session.  Saves a lookup table (baseaddr + offset = address).
>> > > > >
>> > > > > > From the looks of it, it seems just like an interface definition
>> > > issue,
>> > > > > > since as I pointed out, from within the ioctl, it does use
>> u_int64_t
>> > > > > > internally.
>> > > > >
>> > > > > Unfortunately I think it's not that simple, happy to consider
>> something
>> > > > > though if you have ideas.
>> > > > >
>> > > > > Are you planning to do a FreeBSD driver as well ?  If so it
>> wouldn't
>> > > hurt
>> > > > > to
>> > > > > check if it's still the same.  Otherwise I'll get around to
>> checking in
>> > > > > time ;-)
>> > > > >
>> > > > > Cheers,
>> > > > > Davidm
>> > > > >
>> > > > >
>> > > > > > On Wed, Jan 28, 2009 at 3:58 PM, David McCullough <
>> > > > > > Dav...@se...> wrote:
>> > > > > >
>> > > > > > >
>> > > > > > > Jivin Pirasenna Thiyagarajan lays it down ...
>> > > > > > > > I've used OCF patch and attempting to use the cryptodev
>> > > interface.
>> > > > >  In
>> > > > > > > > ocf-compat.h, I see crypto_newsession's session ID is passed
>> in
>> > > as a
>> > > > > > > > u_int32_t *, whereas, the crypto_freesession takes the
>> session id
>> > > as
>> > > > > > > > u_int64_t.  It seems like this is in error.  Looks like sid
>> data
>> > > type
>> > > > > > > should
>> > > > > > > > be u_int64_t *sidp.  In cryptodev.c where it is used, the
>> sid is
>> > > > > defined
>> > > > > > > as
>> > > > > > > > u_int64_t in cryptodev_ioctl.
>> > > > > > >
>> > > > > > > I had to look twice at that too now that you point it out.
>> > > > > > >
>> > > > > > > The trick is that device_method_t structure and resulting
>> > > > > > > CRYPTODEV_NEWSESSION and cryptodev_newsession used for it are
>> > > > > > > part of the interface for OCF drivers.  This is how OCF
>> > > communicates
>> > > > > > > with it's crypto drivers (ie., safe, hifn7751, cryptosoft
>> etc).
>> > > > > > >
>> > > > > > > cryptodev,  the user interface driver,  doesn't talk to the
>> crypto
>> > > > > > > drivers,  it uses the OCF API's:
>> > > > > > >
>> > > > > > >        crypto_newsession
>> > > > > > >        crypto_freesession
>> > > > > > >
>> > > > > > > and they are both u_int64_t.
>> > > > > > >
>> > > > > > > Are you having a problem with cryptodev or did you just notice
>> this
>> > > > > oddity
>> > > > > > > in the code ?
>> > > > > > >
>> > > > > > > I admit the naming is confusing,  but we inherited that with
>> that
>> > > last
>> > > > > > > round of BSD updates.  Unless you are writing a driver,
>>  ignore the
>> > > > > section
>> > > > > > > at the top of ocf-compat.h,  in fact,  ignore as much of
>> > > ocf-compat.h
>> > > > > > > as you can every chance you get :-)  It's where we hide the
>> older
>> > > OS
>> > > > > > > support and some BSD compat things to try and keep the driver
>> > > source as
>> > > > > > > close to the original as practical.
>> > > > > > >
>> > > > > > > Cheers,
>> > > > > > > Davidm
>> > > > > > >
>> > > > > > > --
>> > > > > > > David McCullough,  dav...@se...,
>> Ph:+61
>> > > > > > > 734352815
>> > > > > > > Secure Computing - SnapGear  http://www.uCdot.org
>> > > > > > > http://www.snapgear.com
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > Online Gallery: http://www.deptons.com
>> > > > > > You comments and ratings are very welcome!!
>> > > > >
>> > > > > --
>> > > > > David McCullough,  dav...@se...,   Ph:+61
>> > > > > 734352815
>> > > > > Secure Computing - SnapGear  http://www.uCdot.org
>> > > > > http://www.snapgear.com
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Online Gallery: http://www.deptons.com
>> > > > You comments and ratings are very welcome!!
>> > >
>> > > --
>> > > David McCullough,  dav...@se...,   Ph:+61
>> > > 734352815
>> > > Secure Computing - SnapGear  http://www.uCdot.org
>> > > http://www.snapgear.com
>> > >
>> >
>> >
>> >
>> > --
>> > Online Gallery: http://www.deptons.com
>> > You comments and ratings are very welcome!!
>>
>> --
>> David McCullough,  dav...@se...,   Ph:+61
>> 734352815
>> Secure Computing - SnapGear  http://www.uCdot.org
>> http://www.snapgear.com
>>
>
>
>
> --
> Online Gallery: http://www.deptons.com
> You comments and ratings are very welcome!!
>



-- 
Online Gallery: http://www.deptons.com
You comments and ratings are very welcome!!

Re: [Ocf-linux-users] AES hardware accelerator in OpenSSL with OCF

[Hector P. <hec...@di...>]

David McCullough wrote:
> 	insert aes module
> 	modprobe ocf
> 	modprobe cryptosoft swcr_debug=1
> 	modprobe cryptodev
> 	openssl speed -elapsed -evp aes
> 
> 	check kernel log/console output for crytosoft debug output.
> 
> If that works then there must be some way for you driver to take over
> cbc(aes) that you are missing.  Perhaps the normal crypto API SW driver
> is getting priority ?

Hi David,

I have seen that, if I load the kernel's aes_generic.ko and cbc.ko, then 
cryptosoft module reports that cbc(aes) algorithm is supported:
...
crypto_register(id=0x3, alg=11, maxoplen=0, flags=0x0)
...

and it eventually calls the kernel's aes_generic.c crypto functions 
(this seem to work, as you said). On the other hand, if I simply load my 
driver, cryptosoft reports that the cbc(aes) algorithm is not supported:

...
cryptosoft_init:BLKCIPHER algorithm 11:'cbc(aes)' not supported
...

I don't see many differences between the way aes_generic loads the 
algorithm and the way my driver does it. The main difference is that 
aes_generic cra_flags is CRYPTO_ALG_TYPE_CIPHER while my driver is 
CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC.
In other words, my driver uses .cra_u.ablkcipher to define the crypto 
functions while the aes_generic uses .cra_u.cipher. Do you know if this 
makes any difference to OCF layer?
--
Hector Palacios

Re: [Ocf-linux-users] AES hardware accelerator in OpenSSL with OCF

[Hector P. <hec...@di...>]

David McCullough wrote:
> Try putting the kernel AES module in,  turning on debug in the
> cryptosoft driver and see if that is getting used:
> 
> 	insert aes module
> 	modprobe ocf
> 	modprobe cryptosoft swcr_debug=1
> 	modprobe cryptodev
> 	openssl speed -elapsed -evp aes
> 
> 	check kernel log/console output for crytosoft debug output.

The output doesn't look very good...

/ # openssl speed -elapsed -evp aes -engine cryptodev
No requested driver; select based on crid flags.
No requested driver; select based on crid flags.
No requested driver; select based on crid flags.
No requested driver; select based on crid flags.
aes is an unknown cipher or digest

/ # cat /proc/crypto
name         : cbc(aes)
driver       : cbc(aes-generic)
module       : cbc
priority     : 100
refcnt       : 1
type         : blkcipher
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 16
geniv        : <default>

name         : aes
driver       : aes-generic
module       : aes_generic
priority     : 100
refcnt       : 1
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32


I must pass -evp aes128|aes192|aes256 instead (or use 'aes' alone, 
without the '-evp' parameter), but i think it is using internal OpenSSL 
algorithms rather than OCF, as I still get the errors:

/ # openssl speed -elapsed -evp aes128 -engine cryptodev
No requested driver; select based on crid flags.
No requested driver; select based on crid flags.
No requested driver; select based on crid flags.
No requested driver; select based on crid flags.
No requested driver; select based on crid flags.
No requested driver; select based on crid flags.
No requested driver; select based on crid flags.
No requested driver; select based on crid flags.
engine "cryptodev" set.
You have chosen to measure elapsed time instead of user CPU time.
To get the most accurate results, try to run this
program when this computer is idle.
Doing aes-128-cbc for 3s on 16 size blocks: 81672 aes-128-cbc's in 0.00s
Doing aes-128-cbc for 3s on 64 size blocks: 20311 aes-128-cbc's in 0.00s
Doing aes-128-cbc for 3s on 256 size blocks: 5546 aes-128-cbc's in 0.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 1432 aes-128-cbc's in 0.00s
...

Regards,
--
Hector Palacios

Re: [Ocf-linux-users] crypto_newsession / crypto_freesession

[Pirasenna T. <pir...@gm...>]

diff -ruw /export/tmp/linux-2.6.17.10/crypto/ocf/crypto.c ./crypto.c
--- /export/tmp/linux-2.6.17.10/crypto/ocf/crypto.c	2009-01-29 10:10:36.000000000 -0800
+++ ./crypto.c	2009-01-29 18:54:59.000000000 -0800
@@ -389,17 +389,14 @@
 		/* Call the driver initialization routine. */
 		hid = cap - crypto_drivers;
 		lid = hid;		/* Pass the driver ID. */
-		cap->cc_sessions++;
 		CRYPTO_DRIVER_UNLOCK();
-		err = CRYPTODEV_NEWSESSION(cap->cc_dev, &lid, cri);
+		err = CRYPTODEV_NEWSESSION(cap->cc_dev, &sid[0], cri);
 		CRYPTO_DRIVER_LOCK();
 		if (err == 0) {
-			(*sid) = (cap->cc_flags & 0xff000000)
-			       | (hid & 0x00ffffff);
-			(*sid) <<= 32;
-			(*sid) |= (lid & 0xffffffff);
-		} else
-			cap->cc_sessions--;
+			cap->cc_sessions++;
+			(sid[1]) = ((cap->cc_flags & 0xff000000)
+			       | (hid & 0x00ffffff)) & 0xffffffff;
+		}
 	} else
 		err = EINVAL;
 	CRYPTO_DRIVER_UNLOCK();
@@ -419,7 +416,7 @@
  * driver).
  */
 int
-crypto_freesession(u_int64_t sid)
+crypto_freesession(u_int64_t *sid)
 {
 	struct cryptocap *cap;
 	u_int32_t hid;
@@ -447,7 +444,7 @@
 	if (cap->cc_dev) {
 		CRYPTO_DRIVER_UNLOCK();
 		/* Call the driver cleanup routine, if available, unlocked. */
-		err = CRYPTODEV_FREESESSION(cap->cc_dev, sid);
+		err = CRYPTODEV_FREESESSION(cap->cc_dev, CRYPTO_SESID2LID(sid));
 		CRYPTO_DRIVER_LOCK();
 	}
 
@@ -1014,7 +1011,7 @@
 #endif
 	if (cap->cc_flags & CRYPTOCAP_F_CLEANUP) {
 		struct cryptodesc *crd;
-		u_int64_t nid;
+		u_int64_t nid[2];
 
 		/*
 		 * Driver has unregistered; migrate the session and return
@@ -1030,8 +1027,10 @@
 
 		/* XXX propagate flags from initial session? */
 		if (crypto_newsession(&nid, &(crp->crp_desc->CRD_INI),
-		    CRYPTOCAP_F_HARDWARE | CRYPTOCAP_F_SOFTWARE) == 0)
-			crp->crp_sid = nid;
+				      CRYPTOCAP_F_HARDWARE | CRYPTOCAP_F_SOFTWARE) == 0) {
+			crp->crp_sid[0] = nid[0];
+			crp->crp_sid[1] = nid[1];
+		}
 
 		crp->crp_etype = EAGAIN;
 		crypto_done(crp);
diff -ruw /export/tmp/linux-2.6.17.10/crypto/ocf/cryptodev.c ./cryptodev.c
--- /export/tmp/linux-2.6.17.10/crypto/ocf/cryptodev.c	2009-01-29 10:10:36.000000000 -0800
+++ ./cryptodev.c	2009-01-29 23:39:00.000000000 -0800
@@ -82,7 +82,7 @@
 
 struct csession {
 	struct list_head	list;
-	u_int64_t	sid;
+	u_int64_t	sid[2];
 	u_int32_t	ses;
 
 	wait_queue_head_t waitq;
@@ -113,7 +113,7 @@
 static struct csession *csefind(struct fcrypt *, u_int);
 static int csedelete(struct fcrypt *, struct csession *);
 static struct csession *cseadd(struct fcrypt *, struct csession *);
-static struct csession *csecreate(struct fcrypt *, u_int64_t,
+static struct csession *csecreate(struct fcrypt *, u_int64_t *,
 		struct cryptoini *crie, struct cryptoini *cria, struct csession_info *);
 static int csefree(struct csession *);
 
@@ -256,7 +256,8 @@
 		       | (cop->flags & COP_F_BATCH);
 	crp->crp_buf = (caddr_t)&cse->uio;
 	crp->crp_callback = (int (*) (struct cryptop *)) cryptodev_cb;
-	crp->crp_sid = cse->sid;
+	crp->crp_sid[0] = cse->sid[0];
+	crp->crp_sid[1] = cse->sid[1];
 	crp->crp_opaque = (void *)cse;
 
 	if (cop->iv) {
@@ -325,7 +326,7 @@
 
 	if (crp->crp_etype != 0) {
 		error = crp->crp_etype;
-		dprintk("%s error in crp processing\n", __FUNCTION__);
+		dprintk("%s error in crp processing: error=%d\n", __FUNCTION__, error);
 		goto bail;
 	}
 
@@ -568,7 +569,7 @@
 }
 
 static struct csession *
-csecreate(struct fcrypt *fcr, u_int64_t sid, struct cryptoini *crie,
+csecreate(struct fcrypt *fcr, u_int64_t *sid, struct cryptoini *crie,
 	struct cryptoini *cria, struct csession_info *info)
 {
 	struct csession *cse;
@@ -586,7 +587,8 @@
 	cse->keylen = crie->cri_klen/8;
 	cse->mackey = cria->cri_key;
 	cse->mackeylen = cria->cri_klen/8;
-	cse->sid = sid;
+	cse->sid[0] = sid[0];
+	cse->sid[1] = sid[1];
 	cse->cipher = crie->cri_alg;
 	cse->mac = cria->cri_alg;
 	cse->info = *info;
@@ -600,7 +602,7 @@
 	int error;
 
 	dprintk("%s()\n", __FUNCTION__);
-	error = crypto_freesession(cse->sid);
+	error = crypto_freesession(&cse->sid[0]);
 	if (cse->key)
 		kfree(cse->key);
 	if (cse->mackey)
@@ -624,7 +626,7 @@
 	struct crypt_op cop;
 	struct crypt_kop kop;
 	struct crypt_find_op fop;
-	u_int64_t sid;
+	u_int64_t sid[2];
 	u_int32_t ses;
 	int feat, fd, error = 0, crid;
 	mm_segment_t fs;
@@ -822,15 +824,15 @@
 			/* allow either HW or SW to be used */
 			crid = CRYPTOCAP_F_HARDWARE | CRYPTOCAP_F_SOFTWARE;
 		}
-		error = crypto_newsession(&sid, (info.blocksize ? &crie : &cria), crid);
+		error = crypto_newsession(&sid[0], (info.blocksize ? &crie : &cria), crid);
 		if (error) {
 			dprintk("%s(%s) - newsession %d\n",__FUNCTION__,CIOCGSESSSTR,error);
 			goto bail;
 		}
 
-		cse = csecreate(fcr, sid, &crie, &cria, &info);
+		cse = csecreate(fcr, &sid[0], &crie, &cria, &info);
 		if (cse == NULL) {
-			crypto_freesession(sid);
+			crypto_freesession(&sid[0]);
 			error = EINVAL;
 			dprintk("%s(%s) - csecreate failed\n", __FUNCTION__, CIOCGSESSSTR);
 			goto bail;
diff -ruw /export/tmp/linux-2.6.17.10/crypto/ocf/cryptodev.h ./cryptodev.h
--- /export/tmp/linux-2.6.17.10/crypto/ocf/cryptodev.h	2009-01-29 10:10:36.000000000 -0800
+++ ./cryptodev.h	2009-01-29 23:42:33.000000000 -0800
@@ -345,7 +345,7 @@
 	struct list_head crp_next;
 	wait_queue_head_t crp_waitq;
 
-	u_int64_t	crp_sid;	/* Session ID */
+	u_int64_t	crp_sid[2];	/* Session ID */
 	int		crp_ilen;	/* Input data total length */
 	int		crp_olen;	/* Result total length */
 
@@ -415,12 +415,12 @@
  * a copy of the driver's capabilities that can be used by client code to
  * optimize operation.
  */
-#define CRYPTO_SESID2HID(_sid)	(((_sid) >> 32) & 0x00ffffff)
-#define CRYPTO_SESID2CAPS(_sid)	(((_sid) >> 32) & 0xff000000)
-#define CRYPTO_SESID2LID(_sid)	(((u_int32_t) (_sid)) & 0xffffffff)
+#define CRYPTO_SESID2HID(_sid)	((_sid[1]) & 0x00ffffffULL)
+#define CRYPTO_SESID2CAPS(_sid)	(((_sid[1]) >> 32) & 0xff000000ULL)
+#define CRYPTO_SESID2LID(_sid)	(_sid[0])
 
 extern	int crypto_newsession(u_int64_t *sid, struct cryptoini *cri, int hard);
-extern	int crypto_freesession(u_int64_t sid);
+extern	int crypto_freesession(u_int64_t *sid);
 #define CRYPTOCAP_F_HARDWARE	CRYPTO_FLAG_HARDWARE
 #define CRYPTOCAP_F_SOFTWARE	CRYPTO_FLAG_SOFTWARE
 #define CRYPTOCAP_F_SYNC	0x04000000	/* operates synchronously */
diff -ruw /export/tmp/linux-2.6.17.10/crypto/ocf/cryptosoft.c ./cryptosoft.c
--- /export/tmp/linux-2.6.17.10/crypto/ocf/cryptosoft.c	2009-01-29 10:10:36.000000000 -0800
+++ ./cryptosoft.c	2009-01-29 23:25:47.000000000 -0800
@@ -201,7 +201,7 @@
 static u_int32_t swcr_sesnum = 0;
 
 static	int swcr_process(device_t, struct cryptop *, int);
-static	int swcr_newsession(device_t, u_int32_t *, struct cryptoini *);
+static	int swcr_newsession(device_t, u_int64_t *, struct cryptoini *);
 static	int swcr_freesession(device_t, u_int64_t);
 
 static device_method_t swcr_methods = {
@@ -220,7 +220,7 @@
  * Generate a new software session.
  */
 static int
-swcr_newsession(device_t dev, u_int32_t *sid, struct cryptoini *cri)
+swcr_newsession(device_t dev, u_int64_t *sid, struct cryptoini *cri)
 {
 	struct swcr_data **swd;
 	u_int32_t i;
@@ -407,7 +407,7 @@
 swcr_freesession(device_t dev, u_int64_t tid)
 {
 	struct swcr_data *swd;
-	u_int32_t sid = CRYPTO_SESID2LID(tid);
+	u_int32_t sid = tid;
 
 	dprintk("%s()\n", __FUNCTION__);
 	if (sid > swcr_sesnum || swcr_sessions == NULL ||
@@ -466,7 +466,7 @@
 		goto done;
 	}
 
-	lid = crp->crp_sid & 0xffffffff;
+	lid = CRYPTO_SESID2LID(crp->crp_sid);
 	if (lid >= swcr_sesnum || lid == 0 || swcr_sessions == NULL ||
 			swcr_sessions[lid] == NULL) {
 		crp->crp_etype = ENOENT;
diff -ruw /export/tmp/linux-2.6.17.10/crypto/ocf/ocf-bench.c ./ocf-bench.c
--- /export/tmp/linux-2.6.17.10/crypto/ocf/ocf-bench.c	2009-01-29 10:10:36.000000000 -0800
+++ ./ocf-bench.c	2009-01-29 19:01:12.000000000 -0800
@@ -104,7 +104,7 @@
  * OCF benchmark routines
  */
 
-static uint64_t ocf_cryptoid;
+static uint64_t ocf_cryptoid[2];
 static int ocf_init(void);
 static int ocf_cb(struct cryptop *crp);
 static void ocf_request(void *arg);
@@ -134,7 +134,7 @@
 
 	crie.cri_next = &cria;
 
-	error = crypto_newsession(&ocf_cryptoid, &crie, 0);
+	error = crypto_newsession(&ocf_cryptoid[0], &crie, 0);
 	if (error) {
 		printk("crypto_newsession failed %d\n", error);
 		return -1;
@@ -203,7 +203,8 @@
 	crp->crp_flags = CRYPTO_F_CBIMM;
 	crp->crp_buf = (caddr_t) r->buffer;
 	crp->crp_callback = ocf_cb;
-	crp->crp_sid = ocf_cryptoid;
+	crp->crp_sid[0] = ocf_cryptoid[0];
+	crp->crp_sid[1] = ocf_cryptoid[1];
 	crp->crp_opaque = (caddr_t) r;
 	crypto_dispatch(crp);
 }
diff -ruw /export/tmp/linux-2.6.17.10/crypto/ocf/ocf-compat.h ./ocf-compat.h
--- /export/tmp/linux-2.6.17.10/crypto/ocf/ocf-compat.h	2009-01-29 10:10:36.000000000 -0800
+++ ./ocf-compat.h	2009-01-29 23:44:33.000000000 -0800
@@ -41,7 +41,7 @@
 typedef struct ocf_device *device_t;
 
 typedef struct {
-	int (*cryptodev_newsession)(device_t dev, u_int32_t *sidp, struct cryptoini *cri);
+	int (*cryptodev_newsession)(device_t dev, u_int64_t *sidp, struct cryptoini *cri);
 	int (*cryptodev_freesession)(device_t dev, u_int64_t tid);
 	int (*cryptodev_process)(device_t dev, struct cryptop *crp, int hint);
 	int (*cryptodev_kprocess)(device_t dev, struct cryptkop *krp, int hint);
diff -ruw /export/tmp/linux-2.6.17.10/crypto/ocf/ocfnull/ocfnull.c ./ocfnull/ocfnull.c
--- /export/tmp/linux-2.6.17.10/crypto/ocf/ocfnull/ocfnull.c	2009-01-29 10:10:36.000000000 -0800
+++ ./ocfnull/ocfnull.c	2009-01-29 19:17:59.000000000 -0800
@@ -52,7 +52,7 @@
 static u_int32_t		 null_sesnum = 0;
 
 static int null_process(device_t, struct cryptop *, int);
-static int null_newsession(device_t, u_int32_t *, struct cryptoini *);
+static int null_newsession(device_t, u_int64_t *, struct cryptoini *);
 static int null_freesession(device_t, u_int64_t);
 
 #define debug ocfnull_debug
@@ -79,7 +79,7 @@
  * Generate a new software session.
  */
 static int
-null_newsession(device_t arg, u_int32_t *sid, struct cryptoini *cri)
+null_newsession(device_t arg, u_int64_t *sid, struct cryptoini *cri)
 {
 	dprintk("%s()\n", __FUNCTION__);
 	if (sid == NULL || cri == NULL) {
@@ -100,7 +100,7 @@
 static int
 null_freesession(device_t arg, u_int64_t tid)
 {
-	u_int32_t sid = CRYPTO_SESID2LID(tid);
+	u_int32_t sid = tid;
 
 	dprintk("%s()\n", __FUNCTION__);
 	if (sid > null_sesnum) {
@@ -143,7 +143,7 @@
 	 * find the session we are using
 	 */
 
-	lid = crp->crp_sid & 0xffffffff;
+	lid = CRYPTO_SESID2LID(crp->crp_sid);
 	if (lid >= null_sesnum || lid == 0) {
 		crp->crp_etype = ENOENT;
 		dprintk("%s,%d: ENOENT\n", __FILE__, __LINE__);

Re: [Ocf-linux-users] crypto_newsession / crypto_freesession

[David M. <Dav...@se...>]

Jivin Pirasenna Thiyagarajan lays it down ...
> David:
> Here is what I'm trying achieve.  In my driver I'm adding an abstract layer
> to interface with OCF.  There is an opaque structure that hosts the crypto
> fields, which in OCF-speak is the session.  So, in the kernel space, instead
> of creating a table to maintain the mapping between session id and the
> appropriate crypto operation, I'm trying to return the address.
> 
> I explored your idea of using offset address as session id.  That would work
> in Linux 32-bit mode since the addressable space in kernel is less than a
> gigabyte.  Whereas, in 64-bit mode, I cannot make an assumption of having
> memory obtained from the OS to be within a 32-bit offset.

Ok,  then it is not "on crypto chip" memory but host system memory
obtained through one of the kernel allocator functions.

It sounds like the HW doesn't have a classic "divided up" ring buffer but
just chains arbitary descriptors together  ?

> I'm expecting to use the session id as an opaque handler to the OCF
> interface and the driver may use it to dereference the operation however it
> may see fit.
>
> In a multi-processor scenario, it would eliminate lock to access the session
> table structure safely.

Are you doing this to make finding the "session" info easy,  and
everything you need to know about a session is contained within the memory
pointed to by that address ?

That I can understand.  Especially if you want unlimited sessions.
That way when I ask to do something on session N,  you just dereference N
inside your driver to find out context for that session.

Do you have infomation that is not stored in the memory at the "address" ?
How does the HW find out about a new session ?  Do you just link it into
a list of sessions ?  Does the HW have a session limit ?

If the address is only used by the driver,  it sounds reasonable, if you want
to use the address outside of your driver for anything else then it sounds
quite risky :-)

> Any comments is definitely welcome.

Looking at an OCF driver (forget cryptodev, thats different),  newsession
returns a 32 bit session id,  but freesession takes a 64 bit id,  that
doesn't make much sense in any way :-)

I just checked the current FreeBSD source and the API hasn't changed in
that respect.  I wouldn't like to deviate from that too much, but
I can't say I am completely tied to it either.

Having to recompile doesn't bother me much either as this is a source
only thing anyway.

Cheers,
Davidm

> On Thu, Jan 29, 2009 at 4:39 PM, David McCullough <
> Dav...@se...> wrote:
> 
> >
> > Jivin Pirasenna Thiyagarajan lays it down ...
> > > Here is one option, that does not require interface change and requires
> > no
> > > modification in ocf-compat.h.  It would require recompiling existing
> > drivers
> > > though.
> > >
> > > Since sid is always passed as u_int64_t * for create_newsession,
> > internally
> > > in cryptop structure crp_sid may be setup as a 2 entry 64 byte array. The
> > > nid defintion in crypto.c:1017 may be defined the same way.  The first
> > > 64-bytes are left for driver to put whatever value they want.  The second
> > > 64-byte is left for OCF to store flags and anything else that is required
> > > for administration.
> >
> > Ok,  I think I am missing something here.  Are you trying to pass the
> > address back to userspace by any chance ?
> 
> 
> >
> > > crypto_newsession in crytpodev.c would be modified to store the flags in
> > the
> > > second 64-byte field.
> > > The macros CRYPTO_SESID2HID, CRYPTO_SESID2CAPS and CRYPTO_SESID2LID will
> > be
> > > modified to harvest the information from correct index.
> > > crypto_freesession sends only the first 64-byte data as the argument
> > value
> > > to the function.  So, driver can use it as it is.
> > >
> > > Let me know if you think there are any loose ends or incompatibilities.
> >  I
> > > can send you a patch with these changes after testing it out with
> > software
> > > driver using cryptotest.
> >
> > IMO it is sounding a little messy at this point,  but that may be
> > because I don't quite understand what you are trying to do and how it
> > will be used.
> >
> > Did you consider returning an offset rather than a full pointer  as I
> > suggested below ?  Is it even possible in your context ?
> >
> > If you think the patch is simple enough to do perhaps it will help me
> > understand what you need better ;-)
> >
> > Cheers,
> > Davidm
> >
> >
> > > On Wed, Jan 28, 2009 at 10:03 PM, David McCullough <
> > > Dav...@se...> wrote:
> > >
> > > >
> > > > Jivin Pirasenna Thiyagarajan lays it down ...
> > > > > I'm writing a driver and attempting it to make it OCF compatible.  I
> > was
> > > > > intending on passing the virtual memory address I allocate for driver
> > > > data
> > > > > structures for a given operation as the session id.  To avoid
> > 32/64bit
> > > > > issues, having the crypto_newsession pass in u_int64_t * would make
> > it
> > > > > convenient.  Otherwise, I'll have to keep a mapping table and look up
> > > > > routines appropriately (unnecessary computation cycles).
> > > >
> > > > Hmm,  sounds fair,  only I think that crypto.c messes with the 64 bit
> > > > version a fair bit before handing it to the driver.
> > > >
> > > > Check crypto.c:crypto_newsession to see this in action.
> > > >
> > > > The 64bit version has the driver id + the drivers session id and the
> > > > drivers capability flags all merged into it.
> > > >
> > > > It's probably unlikely your card with have more than 4GB of memory, or
> > > > maybe it does.  You could just return the "offset" into it's memory for
> > > > that session.  Saves a lookup table (baseaddr + offset = address).
> > > >
> > > > > From the looks of it, it seems just like an interface definition
> > issue,
> > > > > since as I pointed out, from within the ioctl, it does use u_int64_t
> > > > > internally.
> > > >
> > > > Unfortunately I think it's not that simple, happy to consider something
> > > > though if you have ideas.
> > > >
> > > > Are you planning to do a FreeBSD driver as well ?  If so it wouldn't
> > hurt
> > > > to
> > > > check if it's still the same.  Otherwise I'll get around to checking in
> > > > time ;-)
> > > >
> > > > Cheers,
> > > > Davidm
> > > >
> > > >
> > > > > On Wed, Jan 28, 2009 at 3:58 PM, David McCullough <
> > > > > Dav...@se...> wrote:
> > > > >
> > > > > >
> > > > > > Jivin Pirasenna Thiyagarajan lays it down ...
> > > > > > > I've used OCF patch and attempting to use the cryptodev
> > interface.
> > > >  In
> > > > > > > ocf-compat.h, I see crypto_newsession's session ID is passed in
> > as a
> > > > > > > u_int32_t *, whereas, the crypto_freesession takes the session id
> > as
> > > > > > > u_int64_t.  It seems like this is in error.  Looks like sid data
> > type
> > > > > > should
> > > > > > > be u_int64_t *sidp.  In cryptodev.c where it is used, the sid is
> > > > defined
> > > > > > as
> > > > > > > u_int64_t in cryptodev_ioctl.
> > > > > >
> > > > > > I had to look twice at that too now that you point it out.
> > > > > >
> > > > > > The trick is that device_method_t structure and resulting
> > > > > > CRYPTODEV_NEWSESSION and cryptodev_newsession used for it are
> > > > > > part of the interface for OCF drivers.  This is how OCF
> > communicates
> > > > > > with it's crypto drivers (ie., safe, hifn7751, cryptosoft etc).
> > > > > >
> > > > > > cryptodev,  the user interface driver,  doesn't talk to the crypto
> > > > > > drivers,  it uses the OCF API's:
> > > > > >
> > > > > >        crypto_newsession
> > > > > >        crypto_freesession
> > > > > >
> > > > > > and they are both u_int64_t.
> > > > > >
> > > > > > Are you having a problem with cryptodev or did you just notice this
> > > > oddity
> > > > > > in the code ?
> > > > > >
> > > > > > I admit the naming is confusing,  but we inherited that with that
> > last
> > > > > > round of BSD updates.  Unless you are writing a driver,  ignore the
> > > > section
> > > > > > at the top of ocf-compat.h,  in fact,  ignore as much of
> > ocf-compat.h
> > > > > > as you can every chance you get :-)  It's where we hide the older
> > OS
> > > > > > support and some BSD compat things to try and keep the driver
> > source as
> > > > > > close to the original as practical.
> > > > > >
> > > > > > Cheers,
> > > > > > Davidm
> > > > > >
> > > > > > --
> > > > > > David McCullough,  dav...@se...,   Ph:+61
> > > > > > 734352815
> > > > > > Secure Computing - SnapGear  http://www.uCdot.org
> > > > > > http://www.snapgear.com
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Online Gallery: http://www.deptons.com
> > > > > You comments and ratings are very welcome!!
> > > >
> > > > --
> > > > David McCullough,  dav...@se...,   Ph:+61
> > > > 734352815
> > > > Secure Computing - SnapGear  http://www.uCdot.org
> > > > http://www.snapgear.com
> > > >
> > >
> > >
> > >
> > > --
> > > Online Gallery: http://www.deptons.com
> > > You comments and ratings are very welcome!!
> >
> > --
> > David McCullough,  dav...@se...,   Ph:+61
> > 734352815
> > Secure Computing - SnapGear  http://www.uCdot.org
> > http://www.snapgear.com
> >
> 
> 
> 
> -- 
> Online Gallery: http://www.deptons.com
> You comments and ratings are very welcome!!

-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com

Re: [Ocf-linux-users] crypto_newsession / crypto_freesession

[Pirasenna T. <pir...@gm...>]

David:
Here is what I'm trying achieve.  In my driver I'm adding an abstract layer
to interface with OCF.  There is an opaque structure that hosts the crypto
fields, which in OCF-speak is the session.  So, in the kernel space, instead
of creating a table to maintain the mapping between session id and the
appropriate crypto operation, I'm trying to return the address.

I explored your idea of using offset address as session id.  That would work
in Linux 32-bit mode since the addressable space in kernel is less than a
gigabyte.  Whereas, in 64-bit mode, I cannot make an assumption of having
memory obtained from the OS to be within a 32-bit offset.

I'm expecting to use the session id as an opaque handler to the OCF
interface and the driver may use it to dereference the operation however it
may see fit.
In a multi-processor scenario, it would eliminate lock to access the session
table structure safely.

Any comments is definitely welcome.

Thanks,
Piras

On Thu, Jan 29, 2009 at 4:39 PM, David McCullough <
Dav...@se...> wrote:

>
> Jivin Pirasenna Thiyagarajan lays it down ...
> > Here is one option, that does not require interface change and requires
> no
> > modification in ocf-compat.h.  It would require recompiling existing
> drivers
> > though.
> >
> > Since sid is always passed as u_int64_t * for create_newsession,
> internally
> > in cryptop structure crp_sid may be setup as a 2 entry 64 byte array. The
> > nid defintion in crypto.c:1017 may be defined the same way.  The first
> > 64-bytes are left for driver to put whatever value they want.  The second
> > 64-byte is left for OCF to store flags and anything else that is required
> > for administration.
>
> Ok,  I think I am missing something here.  Are you trying to pass the
> address back to userspace by any chance ?


>
> > crypto_newsession in crytpodev.c would be modified to store the flags in
> the
> > second 64-byte field.
> > The macros CRYPTO_SESID2HID, CRYPTO_SESID2CAPS and CRYPTO_SESID2LID will
> be
> > modified to harvest the information from correct index.
> > crypto_freesession sends only the first 64-byte data as the argument
> value
> > to the function.  So, driver can use it as it is.
> >
> > Let me know if you think there are any loose ends or incompatibilities.
>  I
> > can send you a patch with these changes after testing it out with
> software
> > driver using cryptotest.
>
> IMO it is sounding a little messy at this point,  but that may be
> because I don't quite understand what you are trying to do and how it
> will be used.
>
> Did you consider returning an offset rather than a full pointer  as I
> suggested below ?  Is it even possible in your context ?
>
> If you think the patch is simple enough to do perhaps it will help me
> understand what you need better ;-)
>
> Cheers,
> Davidm
>
>
> > On Wed, Jan 28, 2009 at 10:03 PM, David McCullough <
> > Dav...@se...> wrote:
> >
> > >
> > > Jivin Pirasenna Thiyagarajan lays it down ...
> > > > I'm writing a driver and attempting it to make it OCF compatible.  I
> was
> > > > intending on passing the virtual memory address I allocate for driver
> > > data
> > > > structures for a given operation as the session id.  To avoid
> 32/64bit
> > > > issues, having the crypto_newsession pass in u_int64_t * would make
> it
> > > > convenient.  Otherwise, I'll have to keep a mapping table and look up
> > > > routines appropriately (unnecessary computation cycles).
> > >
> > > Hmm,  sounds fair,  only I think that crypto.c messes with the 64 bit
> > > version a fair bit before handing it to the driver.
> > >
> > > Check crypto.c:crypto_newsession to see this in action.
> > >
> > > The 64bit version has the driver id + the drivers session id and the
> > > drivers capability flags all merged into it.
> > >
> > > It's probably unlikely your card with have more than 4GB of memory, or
> > > maybe it does.  You could just return the "offset" into it's memory for
> > > that session.  Saves a lookup table (baseaddr + offset = address).
> > >
> > > > From the looks of it, it seems just like an interface definition
> issue,
> > > > since as I pointed out, from within the ioctl, it does use u_int64_t
> > > > internally.
> > >
> > > Unfortunately I think it's not that simple, happy to consider something
> > > though if you have ideas.
> > >
> > > Are you planning to do a FreeBSD driver as well ?  If so it wouldn't
> hurt
> > > to
> > > check if it's still the same.  Otherwise I'll get around to checking in
> > > time ;-)
> > >
> > > Cheers,
> > > Davidm
> > >
> > >
> > > > On Wed, Jan 28, 2009 at 3:58 PM, David McCullough <
> > > > Dav...@se...> wrote:
> > > >
> > > > >
> > > > > Jivin Pirasenna Thiyagarajan lays it down ...
> > > > > > I've used OCF patch and attempting to use the cryptodev
> interface.
> > >  In
> > > > > > ocf-compat.h, I see crypto_newsession's session ID is passed in
> as a
> > > > > > u_int32_t *, whereas, the crypto_freesession takes the session id
> as
> > > > > > u_int64_t.  It seems like this is in error.  Looks like sid data
> type
> > > > > should
> > > > > > be u_int64_t *sidp.  In cryptodev.c where it is used, the sid is
> > > defined
> > > > > as
> > > > > > u_int64_t in cryptodev_ioctl.
> > > > >
> > > > > I had to look twice at that too now that you point it out.
> > > > >
> > > > > The trick is that device_method_t structure and resulting
> > > > > CRYPTODEV_NEWSESSION and cryptodev_newsession used for it are
> > > > > part of the interface for OCF drivers.  This is how OCF
> communicates
> > > > > with it's crypto drivers (ie., safe, hifn7751, cryptosoft etc).
> > > > >
> > > > > cryptodev,  the user interface driver,  doesn't talk to the crypto
> > > > > drivers,  it uses the OCF API's:
> > > > >
> > > > >        crypto_newsession
> > > > >        crypto_freesession
> > > > >
> > > > > and they are both u_int64_t.
> > > > >
> > > > > Are you having a problem with cryptodev or did you just notice this
> > > oddity
> > > > > in the code ?
> > > > >
> > > > > I admit the naming is confusing,  but we inherited that with that
> last
> > > > > round of BSD updates.  Unless you are writing a driver,  ignore the
> > > section
> > > > > at the top of ocf-compat.h,  in fact,  ignore as much of
> ocf-compat.h
> > > > > as you can every chance you get :-)  It's where we hide the older
> OS
> > > > > support and some BSD compat things to try and keep the driver
> source as
> > > > > close to the original as practical.
> > > > >
> > > > > Cheers,
> > > > > Davidm
> > > > >
> > > > > --
> > > > > David McCullough,  dav...@se...,   Ph:+61
> > > > > 734352815
> > > > > Secure Computing - SnapGear  http://www.uCdot.org
> > > > > http://www.snapgear.com
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Online Gallery: http://www.deptons.com
> > > > You comments and ratings are very welcome!!
> > >
> > > --
> > > David McCullough,  dav...@se...,   Ph:+61
> > > 734352815
> > > Secure Computing - SnapGear  http://www.uCdot.org
> > > http://www.snapgear.com
> > >
> >
> >
> >
> > --
> > Online Gallery: http://www.deptons.com
> > You comments and ratings are very welcome!!
>
> --
> David McCullough,  dav...@se...,   Ph:+61
> 734352815
> Secure Computing - SnapGear  http://www.uCdot.org
> http://www.snapgear.com
>



-- 
Online Gallery: http://www.deptons.com
You comments and ratings are very welcome!!

Re: [Ocf-linux-users] crypto_newsession / crypto_freesession

[David M. <Dav...@se...>]

Jivin Pirasenna Thiyagarajan lays it down ...
> Here is one option, that does not require interface change and requires no
> modification in ocf-compat.h.  It would require recompiling existing drivers
> though.
> 
> Since sid is always passed as u_int64_t * for create_newsession, internally
> in cryptop structure crp_sid may be setup as a 2 entry 64 byte array. The
> nid defintion in crypto.c:1017 may be defined the same way.  The first
> 64-bytes are left for driver to put whatever value they want.  The second
> 64-byte is left for OCF to store flags and anything else that is required
> for administration.

Ok,  I think I am missing something here.  Are you trying to pass the
address back to userspace by any chance ?

> crypto_newsession in crytpodev.c would be modified to store the flags in the
> second 64-byte field.
> The macros CRYPTO_SESID2HID, CRYPTO_SESID2CAPS and CRYPTO_SESID2LID will be
> modified to harvest the information from correct index.
> crypto_freesession sends only the first 64-byte data as the argument value
> to the function.  So, driver can use it as it is.
> 
> Let me know if you think there are any loose ends or incompatibilities.  I
> can send you a patch with these changes after testing it out with software
> driver using cryptotest.

IMO it is sounding a little messy at this point,  but that may be
because I don't quite understand what you are trying to do and how it
will be used.

Did you consider returning an offset rather than a full pointer  as I
suggested below ?  Is it even possible in your context ?

If you think the patch is simple enough to do perhaps it will help me
understand what you need better ;-)

Cheers,
Davidm


> On Wed, Jan 28, 2009 at 10:03 PM, David McCullough <
> Dav...@se...> wrote:
> 
> >
> > Jivin Pirasenna Thiyagarajan lays it down ...
> > > I'm writing a driver and attempting it to make it OCF compatible.  I was
> > > intending on passing the virtual memory address I allocate for driver
> > data
> > > structures for a given operation as the session id.  To avoid 32/64bit
> > > issues, having the crypto_newsession pass in u_int64_t * would make it
> > > convenient.  Otherwise, I'll have to keep a mapping table and look up
> > > routines appropriately (unnecessary computation cycles).
> >
> > Hmm,  sounds fair,  only I think that crypto.c messes with the 64 bit
> > version a fair bit before handing it to the driver.
> >
> > Check crypto.c:crypto_newsession to see this in action.
> >
> > The 64bit version has the driver id + the drivers session id and the
> > drivers capability flags all merged into it.
> >
> > It's probably unlikely your card with have more than 4GB of memory, or
> > maybe it does.  You could just return the "offset" into it's memory for
> > that session.  Saves a lookup table (baseaddr + offset = address).
> >
> > > From the looks of it, it seems just like an interface definition issue,
> > > since as I pointed out, from within the ioctl, it does use u_int64_t
> > > internally.
> >
> > Unfortunately I think it's not that simple, happy to consider something
> > though if you have ideas.
> >
> > Are you planning to do a FreeBSD driver as well ?  If so it wouldn't hurt
> > to
> > check if it's still the same.  Otherwise I'll get around to checking in
> > time ;-)
> >
> > Cheers,
> > Davidm
> >
> >
> > > On Wed, Jan 28, 2009 at 3:58 PM, David McCullough <
> > > Dav...@se...> wrote:
> > >
> > > >
> > > > Jivin Pirasenna Thiyagarajan lays it down ...
> > > > > I've used OCF patch and attempting to use the cryptodev interface.
> >  In
> > > > > ocf-compat.h, I see crypto_newsession's session ID is passed in as a
> > > > > u_int32_t *, whereas, the crypto_freesession takes the session id as
> > > > > u_int64_t.  It seems like this is in error.  Looks like sid data type
> > > > should
> > > > > be u_int64_t *sidp.  In cryptodev.c where it is used, the sid is
> > defined
> > > > as
> > > > > u_int64_t in cryptodev_ioctl.
> > > >
> > > > I had to look twice at that too now that you point it out.
> > > >
> > > > The trick is that device_method_t structure and resulting
> > > > CRYPTODEV_NEWSESSION and cryptodev_newsession used for it are
> > > > part of the interface for OCF drivers.  This is how OCF communicates
> > > > with it's crypto drivers (ie., safe, hifn7751, cryptosoft etc).
> > > >
> > > > cryptodev,  the user interface driver,  doesn't talk to the crypto
> > > > drivers,  it uses the OCF API's:
> > > >
> > > >        crypto_newsession
> > > >        crypto_freesession
> > > >
> > > > and they are both u_int64_t.
> > > >
> > > > Are you having a problem with cryptodev or did you just notice this
> > oddity
> > > > in the code ?
> > > >
> > > > I admit the naming is confusing,  but we inherited that with that last
> > > > round of BSD updates.  Unless you are writing a driver,  ignore the
> > section
> > > > at the top of ocf-compat.h,  in fact,  ignore as much of ocf-compat.h
> > > > as you can every chance you get :-)  It's where we hide the older OS
> > > > support and some BSD compat things to try and keep the driver source as
> > > > close to the original as practical.
> > > >
> > > > Cheers,
> > > > Davidm
> > > >
> > > > --
> > > > David McCullough,  dav...@se...,   Ph:+61
> > > > 734352815
> > > > Secure Computing - SnapGear  http://www.uCdot.org
> > > > http://www.snapgear.com
> > > >
> > >
> > >
> > >
> > > --
> > > Online Gallery: http://www.deptons.com
> > > You comments and ratings are very welcome!!
> >
> > --
> > David McCullough,  dav...@se...,   Ph:+61
> > 734352815
> > Secure Computing - SnapGear  http://www.uCdot.org
> > http://www.snapgear.com
> >
> 
> 
> 
> -- 
> Online Gallery: http://www.deptons.com
> You comments and ratings are very welcome!!

-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com

Re: [Ocf-linux-users] AES hardware accelerator in OpenSSL with OCF

[David M. <Dav...@se...>]

Jivin Hector Palacios lays it down ...
> David McCullough wrote:
> >What functions does you driver provide ?  You can see the list that
> >cryptosoft in the crypto_details table in cryptosoft.c  
> 
> My driver provides cbc(aes) and ecb(aes) encryption algorithms for 128, 
> 192, and 256 key lengths.
> The crypto_details table in cryptosoft lists cbc(aes) among others, but 
> not ecb(aes).
> Does this table list the software algorithms provided by OCF?

No,  just the ones supported by the cryptosoft driver,  which is basically
an OCF to cryptoAPI wrapper.

> Must I include somehow my algorithms to this list? Or at least ecb(aes)?

Most of the OCF supported algs are already in there,  so probably not.

OCF doesn't current support ECB algs (at least I don't see it).

> > I am not an
> > expert on how the kernel crypto API matches up cbc(aes) to a driver
> > so I can't help you there.
> 
> Thanks anyway.

Try putting the kernel AES module in,  turning on debug in the
cryptosoft driver and see if that is getting used:

	insert aes module
	modprobe ocf
	modprobe cryptosoft swcr_debug=1
	modprobe cryptodev
	openssl speed -elapsed -evp aes

	check kernel log/console output for crytosoft debug output.

If that works then there must be some way for you driver to take over
cbc(aes) that you are missing.  Perhaps the normal crypto API SW driver
is getting priority ?

Cheers,
Davidm

-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com

Re: [Ocf-linux-users] crypto_newsession / crypto_freesession

[Pirasenna T. <pir...@gm...>]

Here is one option, that does not require interface change and requires no
modification in ocf-compat.h.  It would require recompiling existing drivers
though.

Since sid is always passed as u_int64_t * for create_newsession, internally
in cryptop structure crp_sid may be setup as a 2 entry 64 byte array. The
nid defintion in crypto.c:1017 may be defined the same way.  The first
64-bytes are left for driver to put whatever value they want.  The second
64-byte is left for OCF to store flags and anything else that is required
for administration.

crypto_newsession in crytpodev.c would be modified to store the flags in the
second 64-byte field.
The macros CRYPTO_SESID2HID, CRYPTO_SESID2CAPS and CRYPTO_SESID2LID will be
modified to harvest the information from correct index.
crypto_freesession sends only the first 64-byte data as the argument value
to the function.  So, driver can use it as it is.

Let me know if you think there are any loose ends or incompatibilities.  I
can send you a patch with these changes after testing it out with software
driver using cryptotest.

Thanks,
Piras

On Wed, Jan 28, 2009 at 10:03 PM, David McCullough <
Dav...@se...> wrote:

>
> Jivin Pirasenna Thiyagarajan lays it down ...
> > I'm writing a driver and attempting it to make it OCF compatible.  I was
> > intending on passing the virtual memory address I allocate for driver
> data
> > structures for a given operation as the session id.  To avoid 32/64bit
> > issues, having the crypto_newsession pass in u_int64_t * would make it
> > convenient.  Otherwise, I'll have to keep a mapping table and look up
> > routines appropriately (unnecessary computation cycles).
>
> Hmm,  sounds fair,  only I think that crypto.c messes with the 64 bit
> version a fair bit before handing it to the driver.
>
> Check crypto.c:crypto_newsession to see this in action.
>
> The 64bit version has the driver id + the drivers session id and the
> drivers capability flags all merged into it.
>
> It's probably unlikely your card with have more than 4GB of memory, or
> maybe it does.  You could just return the "offset" into it's memory for
> that session.  Saves a lookup table (baseaddr + offset = address).
>
> > From the looks of it, it seems just like an interface definition issue,
> > since as I pointed out, from within the ioctl, it does use u_int64_t
> > internally.
>
> Unfortunately I think it's not that simple, happy to consider something
> though if you have ideas.
>
> Are you planning to do a FreeBSD driver as well ?  If so it wouldn't hurt
> to
> check if it's still the same.  Otherwise I'll get around to checking in
> time ;-)
>
> Cheers,
> Davidm
>
>
> > On Wed, Jan 28, 2009 at 3:58 PM, David McCullough <
> > Dav...@se...> wrote:
> >
> > >
> > > Jivin Pirasenna Thiyagarajan lays it down ...
> > > > I've used OCF patch and attempting to use the cryptodev interface.
>  In
> > > > ocf-compat.h, I see crypto_newsession's session ID is passed in as a
> > > > u_int32_t *, whereas, the crypto_freesession takes the session id as
> > > > u_int64_t.  It seems like this is in error.  Looks like sid data type
> > > should
> > > > be u_int64_t *sidp.  In cryptodev.c where it is used, the sid is
> defined
> > > as
> > > > u_int64_t in cryptodev_ioctl.
> > >
> > > I had to look twice at that too now that you point it out.
> > >
> > > The trick is that device_method_t structure and resulting
> > > CRYPTODEV_NEWSESSION and cryptodev_newsession used for it are
> > > part of the interface for OCF drivers.  This is how OCF communicates
> > > with it's crypto drivers (ie., safe, hifn7751, cryptosoft etc).
> > >
> > > cryptodev,  the user interface driver,  doesn't talk to the crypto
> > > drivers,  it uses the OCF API's:
> > >
> > >        crypto_newsession
> > >        crypto_freesession
> > >
> > > and they are both u_int64_t.
> > >
> > > Are you having a problem with cryptodev or did you just notice this
> oddity
> > > in the code ?
> > >
> > > I admit the naming is confusing,  but we inherited that with that last
> > > round of BSD updates.  Unless you are writing a driver,  ignore the
> section
> > > at the top of ocf-compat.h,  in fact,  ignore as much of ocf-compat.h
> > > as you can every chance you get :-)  It's where we hide the older OS
> > > support and some BSD compat things to try and keep the driver source as
> > > close to the original as practical.
> > >
> > > Cheers,
> > > Davidm
> > >
> > > --
> > > David McCullough,  dav...@se...,   Ph:+61
> > > 734352815
> > > Secure Computing - SnapGear  http://www.uCdot.org
> > > http://www.snapgear.com
> > >
> >
> >
> >
> > --
> > Online Gallery: http://www.deptons.com
> > You comments and ratings are very welcome!!
>
> --
> David McCullough,  dav...@se...,   Ph:+61
> 734352815
> Secure Computing - SnapGear  http://www.uCdot.org
> http://www.snapgear.com
>



-- 
Online Gallery: http://www.deptons.com
You comments and ratings are very welcome!!

Re: [Ocf-linux-users] AES hardware accelerator in OpenSSL with OCF

[Hector P. <hec...@di...>]

David McCullough wrote:
> What functions does you driver provide ?  You can see the list that
> cryptosoft in the crypto_details table in cryptosoft.c  

My driver provides cbc(aes) and ecb(aes) encryption algorithms for 128, 
192, and 256 key lengths.
The crypto_details table in cryptosoft lists cbc(aes) among others, but 
not ecb(aes).
Does this table list the software algorithms provided by OCF?
Must I include somehow my algorithms to this list? Or at least ecb(aes)?

 > I am not an
 > expert on how the kernel crypto API matches up cbc(aes) to a driver
 > so I can't help you there.

Thanks anyway.

Re: [Ocf-linux-users] AES hardware accelerator in OpenSSL with OCF

[David M. <Dav...@se...>]

Jivin Palacios, Hector lays it down ...
> Hi David,
> 
> > -----Original Message-----
> > From: David McCullough [mailto:Dav...@se...]
> > Sent: Wednesday, January 28, 2009 11:35 PM
> > To: Palacios, Hector
> > Cc: ocf...@li...
> > Subject: Re: [Ocf-linux-users] AES hardware accelerator in OpenSSL with
> > OCF
> > Have you loaded the cryptosoft driver ?   It is needed to talk to the
> > cryptoAPI in the kernel.
> > 
> > 	modprobe ocf
> > 	modprobe cryptosoft
> > 	modprobe cryptodev
> > 
> > You can check that cryptosoft is being used by loading it with the
> > debug
> > parameter, or enabling debug later with:
> > 
> > 	echo 1 > /sys/module/cryptosoft/parameters/swcr_debug
> > 
> > Check your syslog (or console output) for driver messages from
> > cryptosoft
> > which will confirm it is being used when you run openssl.
> 
> Yes, I load the cryptosoft module which eventually resolves and loads my hw driver:
> / # modprobe cryptosoft
> ns921x-aes ns921x-aes.1: NS921x AES encryption/decryption module at 0xc187c000 (irq: 2)
> / # lsmod
> Module                  Size  Used by    Tainted: P  
> ecb                     1920  0 
> aes_generic            33160  0 
> ns921x_aes              5716  0 
> cbc                     2464  0 
> crypto_blkcipher       12580  3 ecb,ns921x_aes,cbc
> cryptomgr               2048  0 
> crypto_algapi          10752  6 ecb,aes_generic,ns921x_aes,cbc,crypto_blkcipher,cryptomgr
> cryptosoft              9192  0 
> cryptodev              10916  0 
> ocf                    18496  2 cryptosoft,cryptodev
> / #
> 
> Do I have somehow to link the cbc(aes) and ecb(aes) to my driver functions?

No,  but you should probably make sure you have your driver loaded
before loading cryptosoft.  Something like:

	modprobe your-driver
	modprobe ocf
	modprobe cryptosoft
	modprobe cryptodev

Just to be sure the algs are there when cryptosoft checks for them.

What functions does you driver provide ?  You can see the list that
cryptosoft in the crypto_details table in cryptosoft.c  I am not an
expert on how the kernel crypto API matches up cbc(aes) to a driver
so I can't help you there.

> > Also remember to add the "-elapsed" option to openssl speed tests or
> > the
> > results will look a little unusual to the causual observer.
> 
> I'll take note, thanks.

Cheers,
Davidm

-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com

Re: [Ocf-linux-users] AES hardware accelerator in OpenSSL with OCF

[Palacios, H. <Hec...@di...>]

Hi David,

> -----Original Message-----
> From: David McCullough [mailto:Dav...@se...]
> Sent: Wednesday, January 28, 2009 11:35 PM
> To: Palacios, Hector
> Cc: ocf...@li...
> Subject: Re: [Ocf-linux-users] AES hardware accelerator in OpenSSL with
> OCF
> Have you loaded the cryptosoft driver ?   It is needed to talk to the
> cryptoAPI in the kernel.
> 
> 	modprobe ocf
> 	modprobe cryptosoft
> 	modprobe cryptodev
> 
> You can check that cryptosoft is being used by loading it with the
> debug
> parameter, or enabling debug later with:
> 
> 	echo 1 > /sys/module/cryptosoft/parameters/swcr_debug
> 
> Check your syslog (or console output) for driver messages from
> cryptosoft
> which will confirm it is being used when you run openssl.

Yes, I load the cryptosoft module which eventually resolves and loads my hw driver:
/ # modprobe cryptosoft
ns921x-aes ns921x-aes.1: NS921x AES encryption/decryption module at 0xc187c000 (irq: 2)
/ # lsmod
Module                  Size  Used by    Tainted: P  
ecb                     1920  0 
aes_generic            33160  0 
ns921x_aes              5716  0 
cbc                     2464  0 
crypto_blkcipher       12580  3 ecb,ns921x_aes,cbc
cryptomgr               2048  0 
crypto_algapi          10752  6 ecb,aes_generic,ns921x_aes,cbc,crypto_blkcipher,cryptomgr
cryptosoft              9192  0 
cryptodev              10916  0 
ocf                    18496  2 cryptosoft,cryptodev
/ #

Do I have somehow to link the cbc(aes) and ecb(aes) to my driver functions?

> Also remember to add the "-elapsed" option to openssl speed tests or
> the
> results will look a little unusual to the causual observer.

I'll take note, thanks.

--
Héctor Palacios
 

Re: [Ocf-linux-users] crypto_newsession / crypto_freesession

[David M. <Dav...@se...>]

Jivin Pirasenna Thiyagarajan lays it down ...
> I'm writing a driver and attempting it to make it OCF compatible.  I was
> intending on passing the virtual memory address I allocate for driver data
> structures for a given operation as the session id.  To avoid 32/64bit
> issues, having the crypto_newsession pass in u_int64_t * would make it
> convenient.  Otherwise, I'll have to keep a mapping table and look up
> routines appropriately (unnecessary computation cycles).

Hmm,  sounds fair,  only I think that crypto.c messes with the 64 bit
version a fair bit before handing it to the driver.

Check crypto.c:crypto_newsession to see this in action.

The 64bit version has the driver id + the drivers session id and the
drivers capability flags all merged into it.

It's probably unlikely your card with have more than 4GB of memory, or
maybe it does.  You could just return the "offset" into it's memory for
that session.  Saves a lookup table (baseaddr + offset = address).

> From the looks of it, it seems just like an interface definition issue,
> since as I pointed out, from within the ioctl, it does use u_int64_t
> internally.

Unfortunately I think it's not that simple, happy to consider something
though if you have ideas.

Are you planning to do a FreeBSD driver as well ?  If so it wouldn't hurt to
check if it's still the same.  Otherwise I'll get around to checking in
time ;-)

Cheers,
Davidm


> On Wed, Jan 28, 2009 at 3:58 PM, David McCullough <
> Dav...@se...> wrote:
> 
> >
> > Jivin Pirasenna Thiyagarajan lays it down ...
> > > I've used OCF patch and attempting to use the cryptodev interface.  In
> > > ocf-compat.h, I see crypto_newsession's session ID is passed in as a
> > > u_int32_t *, whereas, the crypto_freesession takes the session id as
> > > u_int64_t.  It seems like this is in error.  Looks like sid data type
> > should
> > > be u_int64_t *sidp.  In cryptodev.c where it is used, the sid is defined
> > as
> > > u_int64_t in cryptodev_ioctl.
> >
> > I had to look twice at that too now that you point it out.
> >
> > The trick is that device_method_t structure and resulting
> > CRYPTODEV_NEWSESSION and cryptodev_newsession used for it are
> > part of the interface for OCF drivers.  This is how OCF communicates
> > with it's crypto drivers (ie., safe, hifn7751, cryptosoft etc).
> >
> > cryptodev,  the user interface driver,  doesn't talk to the crypto
> > drivers,  it uses the OCF API's:
> >
> >        crypto_newsession
> >        crypto_freesession
> >
> > and they are both u_int64_t.
> >
> > Are you having a problem with cryptodev or did you just notice this oddity
> > in the code ?
> >
> > I admit the naming is confusing,  but we inherited that with that last
> > round of BSD updates.  Unless you are writing a driver,  ignore the section
> > at the top of ocf-compat.h,  in fact,  ignore as much of ocf-compat.h
> > as you can every chance you get :-)  It's where we hide the older OS
> > support and some BSD compat things to try and keep the driver source as
> > close to the original as practical.
> >
> > Cheers,
> > Davidm
> >
> > --
> > David McCullough,  dav...@se...,   Ph:+61
> > 734352815
> > Secure Computing - SnapGear  http://www.uCdot.org
> > http://www.snapgear.com
> >
> 
> 
> 
> -- 
> Online Gallery: http://www.deptons.com
> You comments and ratings are very welcome!!

-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com

Re: [Ocf-linux-users] crypto_newsession / crypto_freesession

[Pirasenna T. <pir...@gm...>]

I'm writing a driver and attempting it to make it OCF compatible.  I was
intending on passing the virtual memory address I allocate for driver data
structures for a given operation as the session id.  To avoid 32/64bit
issues, having the crypto_newsession pass in u_int64_t * would make it
convenient.  Otherwise, I'll have to keep a mapping table and look up
routines appropriately (unnecessary computation cycles).

>From the looks of it, it seems just like an interface definition issue,
since as I pointed out, from within the ioctl, it does use u_int64_t
internally.

Piras

On Wed, Jan 28, 2009 at 3:58 PM, David McCullough <
Dav...@se...> wrote:

>
> Jivin Pirasenna Thiyagarajan lays it down ...
> > I've used OCF patch and attempting to use the cryptodev interface.  In
> > ocf-compat.h, I see crypto_newsession's session ID is passed in as a
> > u_int32_t *, whereas, the crypto_freesession takes the session id as
> > u_int64_t.  It seems like this is in error.  Looks like sid data type
> should
> > be u_int64_t *sidp.  In cryptodev.c where it is used, the sid is defined
> as
> > u_int64_t in cryptodev_ioctl.
>
> I had to look twice at that too now that you point it out.
>
> The trick is that device_method_t structure and resulting
> CRYPTODEV_NEWSESSION and cryptodev_newsession used for it are
> part of the interface for OCF drivers.  This is how OCF communicates
> with it's crypto drivers (ie., safe, hifn7751, cryptosoft etc).
>
> cryptodev,  the user interface driver,  doesn't talk to the crypto
> drivers,  it uses the OCF API's:
>
>        crypto_newsession
>        crypto_freesession
>
> and they are both u_int64_t.
>
> Are you having a problem with cryptodev or did you just notice this oddity
> in the code ?
>
> I admit the naming is confusing,  but we inherited that with that last
> round of BSD updates.  Unless you are writing a driver,  ignore the section
> at the top of ocf-compat.h,  in fact,  ignore as much of ocf-compat.h
> as you can every chance you get :-)  It's where we hide the older OS
> support and some BSD compat things to try and keep the driver source as
> close to the original as practical.
>
> Cheers,
> Davidm
>
> --
> David McCullough,  dav...@se...,   Ph:+61
> 734352815
> Secure Computing - SnapGear  http://www.uCdot.org
> http://www.snapgear.com
>



-- 
Online Gallery: http://www.deptons.com
You comments and ratings are very welcome!!

Re: [Ocf-linux-users] crypto_newsession / crypto_freesession

[David M. <Dav...@se...>]

Jivin Pirasenna Thiyagarajan lays it down ...
> I've used OCF patch and attempting to use the cryptodev interface.  In
> ocf-compat.h, I see crypto_newsession's session ID is passed in as a
> u_int32_t *, whereas, the crypto_freesession takes the session id as
> u_int64_t.  It seems like this is in error.  Looks like sid data type should
> be u_int64_t *sidp.  In cryptodev.c where it is used, the sid is defined as
> u_int64_t in cryptodev_ioctl.

I had to look twice at that too now that you point it out.

The trick is that device_method_t structure and resulting
CRYPTODEV_NEWSESSION and cryptodev_newsession used for it are
part of the interface for OCF drivers.  This is how OCF communicates
with it's crypto drivers (ie., safe, hifn7751, cryptosoft etc).

cryptodev,  the user interface driver,  doesn't talk to the crypto
drivers,  it uses the OCF API's:

	crypto_newsession
	crypto_freesession

and they are both u_int64_t.

Are you having a problem with cryptodev or did you just notice this oddity
in the code ?

I admit the naming is confusing,  but we inherited that with that last
round of BSD updates.  Unless you are writing a driver,  ignore the section
at the top of ocf-compat.h,  in fact,  ignore as much of ocf-compat.h
as you can every chance you get :-)  It's where we hide the older OS
support and some BSD compat things to try and keep the driver source as
close to the original as practical.

Cheers,
Davidm

-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com

[Ocf-linux-users] crypto_newsession / crypto_freesession

[Pirasenna T. <pir...@gm...>]

I've used OCF patch and attempting to use the cryptodev interface.  In
ocf-compat.h, I see crypto_newsession's session ID is passed in as a
u_int32_t *, whereas, the crypto_freesession takes the session id as
u_int64_t.  It seems like this is in error.  Looks like sid data type should
be u_int64_t *sidp.  In cryptodev.c where it is used, the sid is defined as
u_int64_t in cryptodev_ioctl.

Piras

[Ocf-linux-users] crypto_newsession vs. crypto_freesession

[Pirasenna T. <pir...@gm...>]

I've used OCF patch and attempting to use the cryptodev interface.  I see
crypto_newsession's session ID is passed in as a u_int32_t *, whereas, the
crypto_freesession takes the session id as u_int64_t.  It seems like the
crypto_newsession definition has an error.  It should be u_int64_t *.  I see
the sid being defined as u_int64_t in cryptodev_ioctl, where it is being
called.

Thanks,
Piras

Re: [Ocf-linux-users] AES hardware accelerator in OpenSSL with OCF

[David M. <Dav...@se...>]

Jivin Palacios, Hector lays it down ...
> Greetings,
> 
> I have a Netsilicon CPU (NS9215) which contains an AES accelerator which I want to use with OpenSSL. I have a Linux driver for this hardware AES module which uses the kernel 2.6.26 CryptoAPI.
> This driver basically registers the cbc(aes) and ecb(aes) ciphers.
> 
> / # cat /proc/crypto 
> name         : cbc(aes)
> driver       : ns921x-aes
> module       : kernel
> priority     : 0
> refcnt       : 1
> type         : ablkcipher
> async        : yes
> blocksize    : 16
> min keysize  : 16
> max keysize  : 32
> ivsize       : 0
> geniv        : <default>
> 
> name         : ecb(aes)
> driver       : ns921x-aes
> module       : kernel
> priority     : 400
> refcnt       : 1
> type         : ablkcipher
> async        : yes
> blocksize    : 16
> min keysize  : 16
> max keysize  : 32
> ivsize       : 0
> geniv        : <default>
> 
> 
> I would like to have OpenSSL use this driver to accelerate encryption when using these ciphers.
> Looking in the Internet I found the OCF project (http://ocf-linux.sourceforge.net/) which is supposed to do the link between the kernel CryptoAPI and OpenSSL by means of an engine called 'cryptodev' which makes use of device node /dev/crypto. 
> I'm using openssl-0.9.8g and have integrated the OCF patches for the 2.6.26 version and for OpenSSL 0.9.8g (similarly as done in http://www.docunext.com/wiki/My_Notes_on_Patching_2.6.22_with_OCF). It builds ok and I obtain several modules: ocf.ko, cryptodev.ko cryptosoft.ko.
> 
> By executing the OpenSSL commands with option '-engine cryptodev', OpenSSL seems to be using this engine. However, just with that my specific driver functions are not being called. For example I have tried with:
> # openssl speed -engine cryptodev -evp aes128
> and with 
> # time openssl enc aes128 -engine cryptodev -in testfile -out /dev/null -k test
> I would appreciate any hint of how to tell OpenSSL or OCF to use my driver functions.

Have you loaded the cryptosoft driver ?   It is needed to talk to the
cryptoAPI in the kernel.

	modprobe ocf
	modprobe cryptosoft
	modprobe cryptodev

You can check that cryptosoft is being used by loading it with the debug
parameter, or enabling debug later with:

	echo 1 > /sys/module/cryptosoft/parameters/swcr_debug

Check your syslog (or console output) for driver messages from cryptosoft
which will confirm it is being used when you run openssl.

Also remember to add the "-elapsed" option to openssl speed tests or the
results will look a little unusual to the causual observer.

Cheers,
Davidm

-- 
David McCullough,  dav...@se...,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com

[Ocf-linux-users] AES hardware accelerator in OpenSSL with OCF

[Palacios, H. <Hec...@di...>]

Greetings,

I have a Netsilicon CPU (NS9215) which contains an AES accelerator which I want to use with OpenSSL. I have a Linux driver for this hardware AES module which uses the kernel 2.6.26 CryptoAPI.
This driver basically registers the cbc(aes) and ecb(aes) ciphers.

/ # cat /proc/crypto 
name         : cbc(aes)
driver       : ns921x-aes
module       : kernel
priority     : 0
refcnt       : 1
type         : ablkcipher
async        : yes
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 0
geniv        : <default>

name         : ecb(aes)
driver       : ns921x-aes
module       : kernel
priority     : 400
refcnt       : 1
type         : ablkcipher
async        : yes
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 0
geniv        : <default>


I would like to have OpenSSL use this driver to accelerate encryption when using these ciphers. I'm using openssl-0.9.8g and have integrated the OCF patches for the 2.6.26 version and for OpenSSL 0.9.8g (similarly as done in http://www.docunext.com/wiki/My_Notes_on_Patching_2.6.22_with_OCF). It builds ok and I obtain several modules: ocf.ko, cryptodev.ko cryptosoft.ko.
I load these three modules. The cryptosoft.ko loads my hardware AES driver.

By executing the OpenSSL commands with option '-engine cryptodev', OpenSSL seems to be using this engine. However, just with that my specific driver functions are not being called. For example I have tried with:
# openssl speed -engine cryptodev -evp aes128
and with 
# time openssl enc aes128 -engine cryptodev -in testfile -out /dev/null -k test

I would appreciate any hint of how to tell OCF to call my driver functions.
Many thanks
--
Héctor Palacios